Re: Reboot/shutdown failure due to "USB: EHCI: work around silicon bug in Intel's EHCI"

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 03/19/2013 04:48 PM, Stephen Warren wrote:
> On 03/19/2013 02:07 PM, Alan Stern wrote:
...
>> A dmesg log with CONFIG_USB_DEBUG enabled would be helpful.  We ought
>> to be able to tell where khubd is getting stuck.
> 
> Hmmm. Enabling CONFIG_USB_DEBUG appears to mask the problem. I assume
> this is some kind of timing/race condition, unless there's some code
> with required side-effects hiding under ifdef CONFIG_USB_DEBUG somehow?

Some further information: I added some printks, which are hopefully
obvious from the text below, and in the failing case, I see:

> [    1.291277] single_unlink_async: qh ee31bc40 qh_state set to UNLINK_WAIT
> [    1.297960] start_iaa_cycle: qh ee31bc40 qh_state changing UNLINK_WAIT -> UNLINK
...
> [    6.452331] ehci_urb_dequeue: qh ee31bc40 attempting dequeue (qh_stated 2)

This is with CONFIG_USB_DEBUG disabled. That seems to happen to the very
first (and only) URB(?) ever issued.

If I enable CONFIG_USB_DEBUG, then I see the more expected:

> [    1.540410] single_unlink_async: qh ee0c0300 qh_state set to UNLINK_WAIT
> [    1.547094] start_iaa_cycle: qh ee0c0300 qh_state changing UNLINK_WAIT -> UNLINK
> [    1.554487] start_iaa_cycle: qh ee0c0300 qh_state was UNLINK; processing

followed by a whole slew of subsequent URBs being submitted and processed.

Perhaps the issue is that start_iaa_cycle() (or whatever triggers it)
only happens when there's an URB in state UNLINK, but not when there's
only one in state UNLINK_WAIT, so that it only happens once rather than
the required twice? I'm not sure why a timing difference would affect
this though, unless there's some loop in the IAA processing that happens
to do both the UNLINK_WAIT->UNLINK change, and the processing of the URB
in the UNLINK state in one invocation sometimes, but not others?