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.

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.

On Apr 12, 2005, at 2:49 PM, Steven M. Bellovin wrote:

> We've had some discussions in the past about USB devices going away.  I
> have a Dell desktop; as noted, those seem to be more -- I guess
> "sensitive" is the word...
>
> I lost my mouse twice today; each time, I had to reboot.  The system
> notices when I disconnect the mouse; it does not notice if I reconnect
> it under those circumstances.  Is there some way to force a reset of
> the USB adapter so that it will notice the reconnects?
>
> 		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>
>
> !DSPAM:425c183e163338535352622!