Bug 26209

Summary: [noapic] USB problem on SMP with ServerWorks chipset
Product: [Retired] Red Hat Linux Reporter: Mike Vaillancourt <mikev>
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: Florence Gold
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-03-23 18:06:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mike Vaillancourt 2001-02-05 20:38:08 UTC 
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 22:35:30 UTC 
We (Red Hat) should really try to fix this before next release.
Comment 2 Michael K. Johnson 2001-02-08 23:44:55 UTC 
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 16:31:59 UTC 
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 18:39:41 UTC 
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-03-01 03:13:06 UTC 
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 15:51:24 UTC 
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 21:57:01 UTC 
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 19:04:32 UTC 
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 16:19:42 UTC 
Tested with 2.4.2-0.1.26smp - Still broken
Comment 10 Arjan van de Ven 2001-03-21 17:59:44 UTC 
Try booting with "noapic" on the kernel commandline
Comment 11 Mike Vaillancourt 2001-03-23 18:06:05 UTC 
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 20:16:23 UTC 
This can be fixed by upgrading the bios.