Bug 14571 - usb uhci driver causes oops during boot
Summary: usb uhci driver causes oops during boot
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Whiteboard: Winston rc1
: 14045 14940 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-25 00:19 UTC by John Cagle
Modified: 2008-05-01 15:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-05 21:04:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
contents of /var/log/messages showing the oops (6.87 KB, text/plain)
2000-07-25 00:20 UTC, John Cagle
no flags Details
dmesg output of working usb-uhci driver. (5.21 KB, text/plain)
2000-07-31 14:53 UTC, John Cagle
no flags Details
uhci boot errorlog with new kernel (9.51 KB, text/plain)
2000-08-02 20:32 UTC, John Cagle
no flags Details
lspci and lspci -n on Compaq Deskpro that is broken (899 bytes, text/plain)
2000-08-04 04:31 UTC, Arenas Belon, Carlo Marcelo
no flags Details
gzipped /var/log/messages with oops on kernel 2.2.16-17.1 (3.88 KB, text/plain)
2000-08-04 04:45 UTC, Arenas Belon, Carlo Marcelo
no flags Details

Description John Cagle 2000-07-25 00:19:22 UTC
This is a fresh installation of beta4 on the following PC.  
  Compaq Deskpro EN/SFF
  350 MHz PII
  Intel 440BX PIIX4 chipset
  100 MHz bus

Comment 1 John Cagle 2000-07-25 00:20:18 UTC
Created attachment 1500 [details]
contents of /var/log/messages showing the oops

Comment 2 Glen Foster 2000-07-30 20:00:27 UTC
This defect is considered MUST-FIX for Winston Release-Candidate #1

Comment 3 John Cagle 2000-07-31 14:52:12 UTC
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.

Comment 4 John Cagle 2000-07-31 14:53:06 UTC
Created attachment 1697 [details]
dmesg output of working usb-uhci driver.

Comment 5 John Cagle 2000-07-31 15:18:52 UTC
I forgot to change the version to pinstripe...

Comment 6 Michael K. Johnson 2000-08-01 19:42:31 UTC
*** Bug 14940 has been marked as a duplicate of this bug. ***

Comment 7 Michael K. Johnson 2000-08-01 19:45:38 UTC
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...

Comment 8 Brent Nordquist 2000-08-01 19:48:39 UTC
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.

Comment 9 Arenas Belon, Carlo Marcelo 2000-08-02 10:01:36 UTC
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?

Comment 10 Brent Nordquist 2000-08-02 13:43:48 UTC
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!

Comment 11 Michael K. Johnson 2000-08-02 15:26:01 UTC
Thanks, Brent!

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
as closed.

Comment 12 John Cagle 2000-08-02 20:27:30 UTC
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
host controllers.

I'm going to attach the new error messages momentarily.

Comment 13 John Cagle 2000-08-02 20:32:31 UTC
Created attachment 1857 [details]
uhci boot errorlog with new kernel

Comment 14 John Cagle 2000-08-02 20:34:49 UTC
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.)

Comment 15 Brent Nordquist 2000-08-02 21:33:33 UTC
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.


Comment 16 John Cagle 2000-08-02 22:07:44 UTC
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?

Comment 17 Michael K. Johnson 2000-08-03 16:10:04 UTC
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...

Comment 18 Michael K. Johnson 2000-08-03 16:11:31 UTC
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.

Comment 19 John Cagle 2000-08-03 16:16:38 UTC
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.

Comment 20 Glen Foster 2000-08-03 19:54:40 UTC
*** Bug 14045 has been marked as a duplicate of this bug. ***

Comment 21 Arenas Belon, Carlo Marcelo 2000-08-04 04:30:00 UTC
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

Comment 22 Arenas Belon, Carlo Marcelo 2000-08-04 04:31:20 UTC
Created attachment 1974 [details]
lspci and lspci -n on Compaq Deskpro that is broken

Comment 23 Arenas Belon, Carlo Marcelo 2000-08-04 04:45:41 UTC
Created attachment 1975 [details]
gzipped /var/log/messages with oops on kernel 2.2.16-17.1

Comment 24 Michael K. Johnson 2000-08-04 18:52:03 UTC
carenas@chasqui.lared.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?

Comment 25 Arenas Belon, Carlo Marcelo 2000-08-05 03:37:06 UTC
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, (not tested)


Comment 26 Arenas Belon, Carlo Marcelo 2000-08-05 03:43:09 UTC
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 :(

Comment 27 Bill Nottingham 2000-08-05 03:53:49 UTC
OK, so that still looks like usb-uhci is the safer

Comment 28 Jeremy Katz 2000-08-05 21:04:17 UTC
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

Comment 29 Michael K. Johnson 2000-08-07 19:00:36 UTC
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.

Comment 30 John Cagle 2000-08-10 00:21:33 UTC
FYI - the 2.2.16-21 kernel update resolved this problem as well (no 'uhci' ooops).

Note You need to log in before you can comment on or make changes to this bug.