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.
We (Red Hat) should really try to fix this before next release.
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.
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.
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.
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.
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.
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?
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?
Tested with 2.4.2-0.1.26smp - Still broken
Try booting with "noapic" on the kernel commandline
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.
This can be fixed by upgrading the bios.