On Thu, May 5, 2011 at 10:52 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 5 May 2011, Manuel Lauss wrote:
>
>> > The only way usb_hc_died() gets called is if hcd->state is
>> > HC_STATE_HALT, and it gets set to that value when ehci_reset() is
>> > called. At the end of ehci_hcd_au1xxx_drv_resume(), hcd->state is set
>> > to HC_STATE_SUSPENDED. Is it possible that an interrupt arrives
>> > between those two assignments? (But I don't see how the commit would
>> > have affected that...)
>>
>> The EHCI and OHCI controller share an interrupt. As a test I disabled
>> the OHCI driver, and voila, resume works. Logs both with and
>> without built-in OHCI below.
>
> Aha -- it does indeed look like a shared interrupt causing problems.
>
> And I see why this didn't show up earlier. Prior to the commit you
> found, if hcd->state was set to HC_STATE_HALT when an interrupt
> occurred, the interrupt would be ignored.
>
> It looks like the only solution is to remove the test for HC_STATE_HALT
> in usb_hcd_irq(), which means each driver has to call usb_hc_died() at
> the appropriate times. This patch should do that. Let's see how it
> works (this is with that as1451 commit in place).
Patch works, suspended/resumed a few times without any problems.
Another issue I noticed up during testing was an oops, usually
in softirq code, right after resume. With this patch applied or
as1451 reverted it's also gone.
Thanks a lot!
Manuel Lauss
--
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
