In message <6f4beb4f2cd65a4c20b495cac5287d43@dtcc.edu>, Chris Tribo writes:
>My issues surrounding this seem largely to be due to some kind of 
>legacy interrupt routing problem. Using an MPACPI kernel or a kernel 
>with the IOAPIC enabled will probably help. I noticed in normal PIC 
>mode (GENERIC kernel) the only USB controller that was having 
>interrupts fired often was one that shared an IRQ with the onboard SATA 
>controller, where if I use the IOAPIC things seem to fire without a 
>problem.

I'm using GENERIC.MPACPI with a few additions.
>
>My mouse still doesn't attach sometime with SET_ADDRESS_FAILED, but it 
>does that on MacOS X, Linux, and NetBSD, so I hardly expect that it's a 
>USB stack problem; and if I unplug it and plug it back into the same 
>port it is noticed. Without using the IOAPIC, most devices weren't 
>detected at boot and switching ports around didn't usually cause 
>anything to happen.
>
>I already looked at it pretty closely using the debug options, the usb 
>events are going through but no interrupts are being registered by the 
>host controllers unless you use one that's sharing an IRQ, this is 
>probably due to the IRQ for the EHCI controller not firing and handing 
>the device off to UHCI in my case, or from weird interrupt routing 
>because it's a PCI Express board. That's as far as I know how to go.

That's not what I'm seeing.  The mouse attaches, but dies at some 
point.  There is some reason to believe it's correlated with electrical 
noise in the vicinity, though I can't prove that.

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb