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!
Anyone else here who wants to test them can do sofor now at
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
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
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
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.
Michael -- should I retest this using the proper kernel installation
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?
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.
*** 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
>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,
22.214.171.124-0.16 (not tested)
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
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).