On 11-03-03 02:39 PM, Mark Lord wrote: > 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. Okay, dug out a UHCI 1.1 spec, and the indication from there is that uhci_irq() can return IRQ_HANDLED in some cases where IRQ_NONE is more appropriate. Also, it is not masking the "Reserved" bits from the status register. Presumably most implementations "read zero" for those bits, but perhaps not all do. Dunno if this is the cause the XT-PIC errors from earlier in this thread though. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
