On Tue, 16 Oct 2012, Don Zickus wrote: > > 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? It's hard to say. In theory the kexec'ed (new) kernel should have reset the controller, so all pre-existing interrupt conditions should have been cleared. > 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. You're welcome. Alan Stern -- 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
