From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Upgraded to kernel-2.6.13-1.1526_FC4, but the kernel crashed during boot. From the screen dump it looked like yenta_socket was the problem so I booted to the previous kernel and add yenta_socket to /etc/hotplug/blacklist and this actually allowed the machine to boot with the new kernel. When doing "modprobe yenta_socket" after boot the machine locked up but produced some debug output in the syslog, see the following attachment. Version-Release number of selected component (if applicable): kernel-2.6.13-1.1526_FC4 How reproducible: Always Steps to Reproduce: 1. Boot 2. The machine hangs during boot 3. Actual Results: The machine does not boot unless yenta_socket is in etc/hotplug/blacklist Expected Results: Boot as with the previous kernel. Additional info: This is on a laptop, Acer 8104WLMi, lspci output will be attached.
Created attachment 119492 [details] From the syslog when doing "modprobe yenta_socket"
Created attachment 119493 [details] Output from lspci
*** Bug 169757 has been marked as a duplicate of this bug. ***
Further information from the person whose (very similar) problems are described in bug 169757 ... He tried rebuilding the 2.6.13-1.1526 kernel from source with a couple of changes he's found necessary to get things working fully on his machine -- changing things so he can update the DSDT so that ACPI works, and rebuilding it for the right processor type. (I can get the details of the exact configuration he uses, if necessary.) Booting that kernel resulted in the same messages as in the second trace from bug 16957 -- the ones starting with "PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0".
I just tried loading yenta_socket under kernel 2.6.13-1.1532_FC4, this does not crash the kernel anymore and the following is logged: ACPI: PCI Interrupt 0000:06:09.0[A] -> Link [LNKE] -> GSI 10 (level, low) -> IRQ 10 Yenta: CardBus bridge found at 0000:06:09.0 [1025:0070] Yenta O2: res at 0x94/0xD4: ea/00 Yenta O2: enabling read prefetch/write burst Yenta: ISA IRQ mask 0x0038, PCI irq 10 Socket status: 30000006 pcmcia: parent PCI bridge I/O window: 0x3000 - 0x4fff cs: IO port probe 0x3000-0x4fff: clean. pcmcia: parent PCI bridge Memory window: 0xc8200000 - 0xc82fffff pcmcia: parent PCI bridge Memory window: 0x80000000 - 0x81ffffff Yenta: no bus associated with 0000:06:09.1! (try 'pci=assign-busses') Yenta: no bus associated with 0000:06:09.3! (try 'pci=assign-busses') If I actually try adding "pci=assign-busses" to the kernel boot options the machine locks up very early in the boot sequence.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Created attachment 120902 [details] Log created when doing "modprobe yenta_socket" yenta_socket still suggest adding "pci=assign-busses", with kernel 2.6.14-1.1637_FC4 this actually works, see attached log.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
The kernel now boots without the "pci=assign-busses" option, so this problem seems to have been resolved.