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? -- 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
