On 11-03-03 02:06 PM, Alan Stern wrote: > On Thu, 3 Mar 2011, Mark Lord wrote: > >> Mmm.. I missed that part. Very curious, that. >> I wonder if it could be some issue with how the interrupt controller is set up. >> >> Oh the other hand, this USB-GPS is probably a "full-speed" (slow) device, >> using the UHCI interface rather than EHCI. >> >> The uhci_irq() handler (in uhci-hcd.c) appears to always return IRQ_HANDLED, >> even when it didn't actually handle an IRQ. If I'm reading the code correctly, >> then that's a bug, and could cause this issue given the "right" peripheral >> (eg. your USB-GPS). >> >> I wonder if uhci_irq() can be a bit more clever and only set IRQ_HANDLED >> for interrupts that it actually had to handle? Or am I reading it wrong? > > Evidently you didn't see these lines near the start of the routine: > > status = inw(uhci->io_addr + USBSTS); > if (!(status & ~USBSTS_HCH)) /* shared interrupt, not mine */ > return IRQ_NONE; No, I saw those. But I don't blindly trust comments. :) To me, those lines say, "if nothing is active on our bus, then return IRQ_NONE". With the USB-GPS, the bus probably always as "something active", even if no URBs have been received at that instant in time. But I don't have the UHCI spec handy to check right now. Remember.. there IS a bug here somewhere, so old assumptions do need to be reexamined to find the darned thing. Cheers -- 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
