This is a fresh installation of beta4 on the following PC. Compaq Deskpro EN/SFF 350 MHz PII Intel 440BX PIIX4 chipset 64 MB ECC SDRAM 100 MHz bus ATI RAGE PRO TURBO AGP 2X
Created attachment 1500 [details] contents of /var/log/messages showing the oops
This defect is considered MUST-FIX for Winston Release-Candidate #1
This also happens on a Compaq Armada M700 laptop. As a workaround, I changed the alias in /etc/modules.conf to: alias usb-controller usb-uhci After rebooting, the oops no longer appears. I've attached the dmesg output.
Created attachment 1697 [details] dmesg output of working usb-uhci driver.
I forgot to change the version to pinstripe...
*** Bug 14940 has been marked as a duplicate of this bug. ***
Brent, can you check and see if I am correct that your bug is a duplicate of this one by checking John's workaround? Do you have a uhci controller? Your oops messages look similar at first glance, at least...
Will do; I'll try this tonight when I get home. Sorry, I did see this one before I filed mine, but I wasn't sure it was the same... I should have asked.
the same problem on my Armada M700, workaround is working (at least detects an USB cd writer i am plugging when modprobe usb-storage) cd-writer doesn't work but wasn't supposed to work AFAIK BTW is uhci and usb-uhci the same?, why two different modules then?
I'm happy to report that the 2.2.16-17.1 kernel that Michael Johnson built for me last night fixed my problem (bug 14940)... no more usb errors or oopses during boot. Thanks!
Thanks, Brent! Anyone else here who wants to test them can do sofor now at ftp://people.redhat.com/johnsonm/testkernels/ Those kernels will disappear fairly soon, so get them while they are hot! :-) Since I combined bug reports before realizing that I was not 100% sure that they were the same bug, I'll wait for a while or until I have heard from John Cagle to mark it as closed.
Unfortunately, the new kernel RPM did not fix this problem. After doing "rpm -Uvh" on the new non-SMP kernel, I had to edit /etc/lilo.conf and re-run "lilo" to activate the new kernel. I then rebooted and got another oops during the "uhci" driver load. (Once again, if I use "usb-uhci", the problem goes away.) FYI - the two different drivers (uhci and usb-uhci) are from two different authors, and the Linux USB working group has never picked which one they really want to use. You can only use one at a time, as they are both for the UHCI style host controllers. I'm going to attach the new error messages momentarily.
Created attachment 1857 [details] uhci boot errorlog with new kernel
I suspect that perhaps Brent did not edit /etc/lilo.conf and re-run lilo. Without this step, the problem will indeed go away, but it also won't have any modules loaded (because the new kernel RPM puts the modules in /lib/modules/2.2.16-17.1, and they won't be found by the older kernel.)
Nope. I always follow the RedHat instructions for kernel updating; in short: "rpm -ivh kernel-<newversion>" so that both old and new kernels are co-installed, "mkinitrd" to create a new initial ramdisk, adding a new separate entry to lilo.conf (so that the old one can still be used, in case the new kernel fails), and "lilo -v" to update lilo. After you're sure the new one works, you can "rpm -e" the old one and re-lilo. http://www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html
Michael -- should I retest this using the proper kernel installation instructions? All I did was an "rpm -Uvh" and then manually edited lilo.conf and ran lilo. I did not create a new initrd. Could that be my problem? THANKS!
If there was no initrd line in your /etc/lilo.conf to start with, then you don't need to make a new initrd. If there was one, you need to change the copy of the initrd section to point to the new initrd that you build with mkinitrd. We're now seeing oopses in autofs but not usb on our Compaq test machines, FWIW. That's next in the list...
It probably wouldn't hurt for us to use usb-uhci by default, so I have added the people responsible for that to the CC list.
My system doesn't use an initrd, so the last oops report is still valid. I agree that using usb-uhci by default is probably a safe choice. Thanks!
*** Bug 14045 has been marked as a duplicate of this bug. ***
the new kernel fixes the oops on my Laptop Compaq Armada M700, but it is still breaking on my Compaq Deskpro ( i think series P1000 ) workstation alias usb-controller uhci worked on both systems (at least didn't oops) i also think uhci should be a better default choice
Created attachment 1974 [details] lspci and lspci -n on Compaq Deskpro that is broken
Created attachment 1975 [details] gzipped /var/log/messages with oops on kernel 2.2.16-17.1
carenas.net.pe writes: >alias usb-controller uhci worked on both systems (at least didn't oops) We normally have done "alias usb-controller uhci" and that is what is breaking for other people. On the Compaq test machine I tried, "alias usb-controller usb-uhci" fixes it, and so we changed everything to use usb-uhci instead of uhci. Is there any chance that you wrote that backwards; that usb-uhci is the one that works for you?
sorry, i just need more sleep usb-uhci works (2.2.16-17, 2.2.16-17.1 and 2.4.0-0.16 (not tested on Armada M700) worked on both systems uhci oops on both systems with 2.2.16-17, Armada M700 is fixed with 2.2.16-17.1, 2.2.4.0-0.16 (not tested) HTH
i mean: Armada M700 Deskpro 2.2.16-17 2.2.16-17.1 2.4.0-0.16 2.2.16-17 2.2.16-17.1 2.4.0-0.16 uhci oops ok untested oops oops ok usb-uhci ok ok untested ok ok ok hope i make myself clear now :(
OK, so that still looks like usb-uhci is the safer choice.
I can also give another couple of data points of usb-uhci working better than UHCI on a Dell Dimension and Optiplex and I don't remember ever specifically having problems due to using usb-uhci instead of uhci in my random testing of usb stuff over time
Ok, we are using the usb-uhci module by default now. We may also have fixed this problem in the uhci module (would require some testing to be sure), but usb-uhci currently looks like the best choice anyway for now so we'll leave that change in place.
FYI - the 2.2.16-21 kernel update resolved this problem as well (no 'uhci' ooops).