On Thu, Mar 03, 2011 at 01:10:10PM -0500, Mark Lord wrote: > What is most likely happening here, is that the USB interrupt handler > is returning IRQ_HANDLED under some condition where IRQ_NONE is required. > > In other words, USB thought it got an interrupt, but didn't really, > but since it returns IRQ_HANDLED regardless, then other > device drivers sharing that IRQ don't necessarily get called. > If this happens repeatedly, then it could disrupt the other devices. I doubt this is the issue, as we would have seen it long before now. > Now, that's not overly likely, but then again it's probably not > well tested with everyone using APICs nowadays. > > Or, perhaps the PL2303 driver leaves an interrupt active/pending > without clearing it in hardware, so the interrupt keeps recurring > over and over. This (unlikely) is easy to check for, by watching > the /proc/interrupts count for the USB on your APIC-enabled kernel. A usb driver has no interrupt handling at all, so it just flat out can not do this. It's up to the usb host controller driver, that is what handles interrupts. > If the numbers increase at a phenomenal rate, then there might > be an issue. With an active GPS, one would expect the numbers to > be incrementing steadily, say a few dozen or a hundred or so per second. It all depends on the traffic to the USB device and how well behaved it is, as to how many interrupts it generates. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
