Bug 26209 - [noapic] USB problem on SMP with ServerWorks chipset
[noapic] USB problem on SMP with ServerWorks chipset
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
Florence Gold
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-05 15:38 EST by Mike Vaillancourt
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-23 13:06:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Vaillancourt 2001-02-05 15:38:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.17-7.4 i686)


On a HP Visualize XL-Class machine running the smp kernel, plugging in any
USB device (Mouse, keyboard, microscope) cause the following messages:

usb.c: USB new device connect, assigned device number 2
usb_control/bulk_msg: timeout
usb-ohci.c: unlink URB timeout!
usb.c: USB device not accepting new address (error=-110)

Output from /proc/interrupts

  0:    1253381          XT-PIC  timer
  1:        123    IO-APIC-edge  keyboard
  2:          0          XT-PIC  cascade
  8:          1    IO-APIC-edge  rtc
 12:        543    IO-APIC-edge  PS/2 Mouse
 13:          1          XT-PIC  fpu
 15:          6    IO-APIC-edge  ide1
 24:       3869   IO-APIC-level  aic7xxx
 26:      37975   IO-APIC-level  eth0
 27:          0   IO-APIC-level  cs461x
 33:          0            none  usb-ohci
NMI:          0
ERR:          0
Booting with the noapic option seems to work.

I can not reproduce this on other machines running different chipsets. 


Reproducible: Always
Steps to Reproduce:
1. Boot machine with SMP kernel
2. Plug in USB device
3. dmesg or watch screen
	

Actual Results:  usb.c: USB new device connect, assigned device number 2
usb_control/bulk_msg: timeout
usb-ohci.c: unlink URB timeout!
usb.c: USB device not accepting new address (error=-110)


Expected Results:  At the very worst:

usb.c: USB new device connect, assigned device number 2
usb.c: This device is not recognized by any installed USB driver.
Comment 1 Glen Foster 2001-02-05 17:35:30 EST
We (Red Hat) should really try to fix this before next release.
Comment 2 Michael K. Johnson 2001-02-08 18:44:55 EST
Try our 2.4.1-based kernel when we come out with it (in the next few
days) and if that doesn't work, try booting with the noapic option
and report the result.
Comment 3 Mike Vaillancourt 2001-02-09 11:31:59 EST
Booting with the noapic option solves the problem. But, I am concerned about
what this is doing to interrupts sent to the proc.

I have done some more testing and I have found that this may be more specific
than I thought. It looks like it may be HP specific. We have a couple IBM
machines with the same chipset that work. Although these machine still have the
name reliance CNB20HE instead of ServerWorks CNB20HE.
Comment 4 Michael K. Johnson 2001-02-09 13:39:41 EST
Hardware bugs implementing APIC irrespective of chipset have been
seen before and probably will be again.  I have no idea if this is
the case here, but it wouldn't be unheard-of.

But do check out 2.4.1-0.1.1 or later when it is built, as there
are at least two serverworks-related fixes/workarounds in our
current source tree.
Comment 5 Michael K. Johnson 2001-02-28 22:13:06 EST
Please test 2.4.2-0.1.16 from the current tree ASAP.  We have some
APIC-related fixes in there but we don't know if they apply here.
Either way, we need to know quickly.
Comment 6 Mike Vaillancourt 2001-03-06 10:51:24 EST
I have tested this with the 2.4.1-0.1.9 kernel it looks to be fixed. I will get
the latest kernel and make sure but unless something changed, we should be ok.
Comment 7 Mike Vaillancourt 2001-03-07 16:57:01 EST
Just finished testing with 2.4.2-0.1.19smp. The problem has returned. Something
in 2.4.1-0.1.9 that has changed for the new kernel?
Comment 8 Michael K. Johnson 2001-03-12 14:04:32 EST
Not that I have any specific reason to think that it is fixed, but lots
of things have been changed; could you retest with 2.4.2-0.1.25?
Comment 9 Mike Vaillancourt 2001-03-13 11:19:42 EST
Tested with 2.4.2-0.1.26smp - Still broken
Comment 10 Arjan van de Ven 2001-03-21 12:59:44 EST
Try booting with "noapic" on the kernel commandline
Comment 11 Mike Vaillancourt 2001-03-23 13:06:05 EST
As mentioned in the initial report, booting with noapic does work. I am going to
test the newest kernel today to see what it does.
Comment 12 Arjan van de Ven 2001-04-07 16:16:23 EDT
This can be fixed by upgrading the bios.

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