- Added David Miller's networking tree to the -mm lineup as bk-net.patch.
- Added Herbert Xu's crypto development tree to the -mm lineup as bk-cryptodev.patch.
-mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel.
Usually it is possible to determine the latest cset from each tree by looking at the first couple of lines of the relevant patch in the broken-out/ directory. Although sometimes it isn't there if I had to massage the diff.
- There may be an x86_64 problem here, although it works for me. If it fails early in boot, try reverting x86_64-separate-amd-cmp-detection-from-hyper-threading.patch
- There's some work here on the recent USB PM resume bugs. If you had problems there, please test and be sure to cc linux-usb-de...@lists.sourceforge.net in any reports.
+selinux-make-code-static-and-remove-unused-code.patch +selinux-allow-mounting-of-filesystems-with-invalid-root-inode-context.patc h +selinux-audit-unrecognized-netlink-messages.patch +selinux-add-name_connect-permission-check.patch
I get a similar Oops at boot; I noticed this warning during compilation:
drivers/char/drm/drm_agpsupport.c: In function `drm_agp_init': drivers/char/drm/drm_agpsupport.c:391: warning: implicit declaration of function `agp_find_bridge' drivers/char/drm/drm_agpsupport.c:391: warning: assignment makes pointer from integer without a cast
I dont know what header to include/modify to make it go away. DRM and AGP are compiled into the kernel (no modules).
I'm getting the following build error with 2.6.12-rc1-mm2:
CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.init.text+0x4323): In function `zft_init': : undefined reference to `class_device_creat' make: *** [.tmp_vmlinux1] Error 1
2.6.12-rc1-mm1 built and is running just fine. I used the -rc1-mm1 .config, did make oldconfig, make bzImage. Here is the .config:
> While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and > Xorg fails to enable DRI (attached, lspci and .config):
Same problem on my Radeon M6 LY here. This seems to be due to agp_find_bridge not being exported anymore in agp_backend.h. Dave might have forgotten it when reworking my patch. Patch attached.
On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > they are pulled 3-4 hours before the release of the -mm kernel.
Andrew,
Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK?
I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.
There were contradictory patches in flight and I stuck the latest drm tree into rc1-mm2 at the last minute, alas. You should revert agp-make-some-code-static.patch.
But I assume that fixing the compile warnings does not fix the oopses which Stefano and Brice are seeing?
> There were contradictory patches in flight and I stuck the latest drm tree > into rc1-mm2 at the last minute, alas. You should revert > agp-make-some-code-static.patch.
> But I assume that fixing the compile warnings does not fix the oopses which > Stefano and Brice are seeing?
My patch does fix both the compile warnings and my oops on my Radeon laptop.
> On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > > -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > > they are pulled 3-4 hours before the release of the -mm kernel.
> Andrew,
> Do you notify the subsystem maintainers ahead of time so that critical > fixes can be pushed to BK?
Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when.
> I am thinking of the recent ALSA example, where the emu10k1 driver was > b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.
We've been discussing how to get ALSA CVS into ALSA bk more promptly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thursday, 24 of March 2005 23:31, Rafael J. Wysocki wrote: > Hi,
> On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: > > Lee Revell <rlrev...@joe-job.com> wrote:
> > > On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > > > > -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > > > > they are pulled 3-4 hours before the release of the -mm kernel.
> > > Andrew,
> > > Do you notify the subsystem maintainers ahead of time so that critical > > > fixes can be pushed to BK?
> > Occasionally I'll go out and ping people, but almost always the subsystem > > guys know what the development cycle is, and they appropriately decide > > which code should go in, and when.
> > > I am thinking of the recent ALSA example, where the emu10k1 driver was > > > b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.
> > We've been discussing how to get ALSA CVS into ALSA bk more promptly.
> BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process > goes into the D state immediately), which did not happen before. This is 100% > reproducible, on two different AMD64-based boxes, with different sound chips.
Er, sorry for the noise on alsa-devel. Actually, rmmod doesn't work for me at all on x86-64 (on two different boxes).
Greets, Rafael
-- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: > Lee Revell <rlrev...@joe-job.com> wrote:
> > On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > > > -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > > > they are pulled 3-4 hours before the release of the -mm kernel.
> > Andrew,
> > Do you notify the subsystem maintainers ahead of time so that critical > > fixes can be pushed to BK?
> Occasionally I'll go out and ping people, but almost always the subsystem > guys know what the development cycle is, and they appropriately decide > which code should go in, and when.
> > I am thinking of the recent ALSA example, where the emu10k1 driver was > > b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.
> We've been discussing how to get ALSA CVS into ALSA bk more promptly.
BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips.
Greets, Rafael
-- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
>>>On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote:
>>>> -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually >>>> they are pulled 3-4 hours before the release of the -mm kernel.
>>>Andrew,
>>>Do you notify the subsystem maintainers ahead of time so that critical >>>fixes can be pushed to BK?
>>Occasionally I'll go out and ping people, but almost always the subsystem >>guys know what the development cycle is, and they appropriately decide >>which code should go in, and when.
>>>I am thinking of the recent ALSA example, where the emu10k1 driver was >>>b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.
>>We've been discussing how to get ALSA CVS into ALSA bk more promptly.
> BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process > goes into the D state immediately), which did not happen before. This is 100% > reproducible, on two different AMD64-based boxes, with different sound chips.
> Greets, > Rafael
hello,
Same kinds of problem here. It depends on the removed module. I mean: "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod ohci1394" hangs.
# # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0
# # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y
# # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y # CONFIG_SMP is not set # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set
# # Firmware Drivers # CONFIG_EDD=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_REGPARM=y CONFIG_SECCOMP=y
# # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x100000 CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set
# # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="/dev/hdb6"
# # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_HOTKEY=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set
# # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set
# # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set
# # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set
# # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set
# # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set
# # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set
# # Connector - unified userspace <-> kernelspace linker # # CONFIG_CONNECTOR is not set
# # Memory Technology Devices (MTD) # # CONFIG_MTD is not set
# # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_GSC is not set CONFIG_PARPORT_1284=y
# # Plug and Play support # # CONFIG_PNP is not set
# # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set CONFIG_BLK_DEV_UB=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_LBD is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set
# # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_ATA_OVER_ETH is not set CONFIG_AOE_PARTITIONS=16
# # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y
# # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set
# # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set
# # SCSI device support # CONFIG_SCSI=m CONFIG_SCSI_PROC_FS=y
# # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # CONFIG_CHR_DEV_SCH is not set
# # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # CONFIG_ISCSI_IF is not set
# # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=m # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set
# # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=m # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300
...
> Same kinds of problem here. It depends on the removed module. I mean: > "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod > ohci1394" hangs.
> - Added David Miller's networking tree to the -mm lineup as bk-net.patch.
> - Added Herbert Xu's crypto development tree to the -mm lineup as > bk-cryptodev.patch.
> -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > they are pulled 3-4 hours before the release of the -mm kernel.
> Usually it is possible to determine the latest cset from each tree by > looking at the first couple of lines of the relevant patch in the > broken-out/ directory. Although sometimes it isn't there if I had to > massage the diff.
> - There may be an x86_64 problem here, although it works for me. If it > fails early in boot, try reverting > x86_64-separate-amd-cmp-detection-from-hyper-threading.patch
> - There's some work here on the recent USB PM resume bugs. If you had > problems there, please test and be sure to cc > linux-usb-de...@lists.sourceforge.net in any reports.
> - Some fixes for the recent DRM problems.
> - Big DVB update
> - md updates
> - nfs4 server updates
> - Lots more fixes
> - Lots more bugs.
Fails to compile for me:
CC [M] fs/nfs/dir.o CC [M] fs/nfs/inode.o CC [M] fs/nfs/nfs4proc.o fs/nfs/nfs4proc.c:2976: error: static declaration of 'nfs4_file_inode_operations' follows non-static declaration fs/nfs/nfs4_fs.h:179: error: previous declaration of 'nfs4_file_inode_operations' was here make[2]: *** [fs/nfs/nfs4proc.o] Error 1 make[1]: *** [fs/nfs] Error 2 make: *** [fs] Error 2
On Thu, 24 Mar 2005, Andrew Morton wrote: > Laurent Riffard <laurent.riff...@free.fr> wrote:
> > hello,
> > Same kinds of problem here. It depends on the removed module. I mean: > > "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod > > ohci1394" hangs.
> > Sysrq-T when rmmoding snd_ens1371 :
<snip>
> It looks like we're getting stuck in the wait_for_completion() in the new > klist_remove().
D'oh! It's getting hung while waiting to remove the current node from the list (which it can't remove because it's being used). The patch below should fix it.
down(&dev->sem); device_detach_shutdown(dev); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> Andrew Morton a écrit : > > Stefano Rivoir <s.riv...@gts.it> wrote: > >>>--- linux-mm/include/linux/agp_backend.h.old > >>>+++ linux-mm/include/linux/agp_backend.h > >>>+extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); > >>Right, that fixed it for me.
> > There were contradictory patches in flight and I stuck the latest drm > > tree into rc1-mm2 at the last minute, alas. You should revert > > agp-make-some-code-static.patch.
> > But I assume that fixing the compile warnings does not fix the oopses > > which Stefano and Brice are seeing?
> My patch does fix both the compile warnings and my oops on my Radeon > laptop.
It also allows my machine to boot.
Alexey
... drm_agp_init+0x30/0x8e drm_fill_in_dev+0xe7/0x195 drm_get_dev+0x4a/0xba kobject_get+0xf/0x13 do_initcalls+0x54/0xb0 init+0x0/0x100 init+0x0/0x100 kernel_thread_helper+0x0/0x0b kernel_thread_helper+0x5/0x0b ... <0>Kernel panic - not syncing: Attempted to kill init! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, Mar 24, 2005 at 04:41:14AM -0800, Andrew Morton wrote: >... > Chages since 2.6.12-rc1-mm1: >... > -revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.p atch
> Drop this - the modules are now in the kernel. >...
As already discussed, there's still no module using this in the kernel.
The part of this patch that still applies is below.
> > > Same kinds of problem here. It depends on the removed module. I mean: > > > "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod > > > ohci1394" hangs.
> > > Sysrq-T when rmmoding snd_ens1371 :
> <snip>
> > It looks like we're getting stuck in the wait_for_completion() in the new > > klist_remove().
> D'oh! It's getting hung while waiting to remove the current node from the > list (which it can't remove because it's being used). The patch below > should fix it.
> On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: > > Miles Lane <miles.l...@gmail.com> wrote: > > > Unable to handle kernel paging request at virtual address 24fc1024 > > > c0198448 > > > *pde = 00000000 > > > Oops: 0000 [#1] > > > CPU: 0 > > > EIP: 0060:[<c0198448>] Not tainted VLI
> > I wonder why the EIP sometimes doesn't get decoded.
> > > Using defaults from ksymoops -t elf32-i386 -a i386 > > > EFLAGS: 00210206 (2.6.12-rc1-mm2)
> ksymoops seems to remove lines from the kernel output that it doesn't > like.
but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you saying that ksymoops rubbed that out and stuck a hex number in there?
> I've seen this many times on ARM, and each time I see an oops > from a 2.6 kernel which has been ksymoopsed, I always ask the submitter > to send the original non-ksymoopsed version.
> Users need to be re-educated _not_ to use ksymoops.
I wonder if there's something clever we could do to the kallsymsised oops output so that ksymoops would simply cease to recognise it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
