Re: uhci irq race before term_td is allocated

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.  :-)

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.

> I did not get a chance to test the patch yet.

Let me know what happens.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux