Description of problem:
new kernel hangs on boot after detecting usb2-1 (printer)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual results: new kernel fails to boot, 2.6.25-0.35.rc1.fc9 is fine.
Same for me, file system doesn't mount, boot hangs after USB devices detection.
Based on dmesg from the working kernel, git2 is hanging at these lines:
Initializing USB Mass Storage driver...
scsi4 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x03F0 pid 0x2304
usbcore: registered new interface driver usblp
What would the working kernel do next? It's unthinkable to imagine
usblp giving such kind of trouble, so it must be something that comes
Created attachment 295067 [details]
Comment on attachment 295067 [details]
Here's the whole dmesg; still hangs exactly at the same point.
First boot after upgrading to 2.6.25-0.40.rc2.git2.fc9 detected my wacom tablet,
then my usb-modem(huawei e220) stops.
Second attempt detected the modem first but not the tablet.
Plugging/unplugging devices fires events which get printed.
I also have a usb-mouse plugged which didn't show at all.
This is on a Toshiba Qosmio G30.
I took a look at the initrd file and compared it to the previous working kernel.
I first created a new initrd using:
mkinitrd /boot/initrd-.6.25-0.40.rc1.git2.fc9-2.img 2.6.25-0.40.rc1.git2.fc9
which also failed to boot. Then manually specified these modules:
mkinitrd --with scsi_mod --with sd_mod --with libata --with ahci -f
Which boots the system with no problems.
I guess the kernel needs libata to see any disks so it can continue the boot
sequence, but why doesn't it die with the using AII! PANIC message about not
being able to find the root filesystem is just weird.
The usb messages didn't show up when I unplugged all of them for testing.
Booting stopped just where the PANIC messages usually shows up with some of the
usual suspects being present but not the PANIC itself.
A userfriendly way to send dmesg output over the wire would be nice ;)
Today's update to 2.6.25-0.54.rc2.fc9 fixes the problem - booting normally now.
*** Bug 433438 has been marked as a duplicate of this bug. ***
2.6.25-0.54.rc2.fc9 working fine here too.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here: