On Tue, Oct 16, 2012 at 12:01:29PM -0400, Alan Stern wrote: > On Tue, 16 Oct 2012, Don Zickus wrote: > > > > I dislike adding an extra test to a hot path, but there doesn't seem to > > > be any way around it. Some of the other HCDs may need a similar > > > change. > > > > I understand your concern. I was curious in uhci_irq, I see the following > > fragment: > > > > status = uhci_readw(uhci, USBSTS); > > if (!(status & ~USBSTS_HCH)) /* shared interrupt, not mine */ > > return IRQ_NONE; > > uhci_writew(uhci, status, USBSTS); /* Clear it */ > > > > Should that be helping in filtering out shared interrupts or not in this > > case? > > If it did help, your system wouldn't have crashed. :-) Hehe. True. > > What must have happened is that one of the bits in the USBSTS register > was set. It didn't cause an IRQ because the USBINTR register was > clear, but an IRQ arrived anyway from some other device sharing the IRQ > line. > > Since USBSTS had bits set, the test above did not filter out the > interrupt. In other words, even though it really was a shared > interrupt it didn't look that way, because the UHCI controller would > have generated an interrupt request if it had been allowed to. So this could have been a leftover interrupt from the boot kernel? > > > I did not get a chance to test the patch yet. > > Let me know what happens. It might take a while as our customer's customers have trouble reproducing this which means it is difficult to tell if the problem is fixed or just harder to reproduce. :-/ Hopefully after a couple of weeks I will have some indication of which. Thanks for the help. Cheers, Don -- 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
