On Mon, Oct 15, 2012 at 05:31:01PM -0400, Alan Stern wrote:
> >
> > uhci_scan_schedule->
> > uhci_clear_next_interrupt->
> > uhci->term_td->status &= ~cpu_to_hc32(uhci, TD_CTRL_IOC);
> >
> > This panics becase term_td is not allocated yet.
> >
> > Now I could be wrong about the interrupts and the uhci_start routine and
> > perhaps this is prevented somehow. This is why I am asking what is the
> > expectation for the above scenario.
>
> > I was just wondering if you had a quick thought about this or not.
Hi Alan,
Thanks for your respone.
>
> I suspect you're getting a shared interrupt, that is, one generated by
> another device using the same IRQ line and not by the UHCI controller
> itself. Can you check the IRQ assignments to see if that's possible?
A box in our lab (which should have similar hardware) shows
(only first cpu shown, other 159 snipped)
17: 183 IR-IO-APIC-fasteoi uhci_hcd:usb6, ata_piix, hpilo
20: 3 IR-IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
22: 0 IR-IO-APIC-fasteoi uhci_hcd:usb4
23: 53 IR-IO-APIC-fasteoi uhci_hcd:usb3, uhci_hcd:usb5, radeon
So yes, you are probably correct with regards to shared interrupt.
>
> I'm reasonably sure that the controller didn't generate the bad
> interrupt, because it's not allowed to generate any IRQs until the
> USBINTR register is set to a nonzero value. That doesn't happen until
> start_rh() is called near the end of uhci_start().
>
> Since uhci_irq() doesn't check to see whether the uhci->is_initialized
> flag has been set, a shared interrupt arriving too early could cause
> exactly the sort of problem you see here.
>
> 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?
I did not get a chance to test the patch yet.
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
