On Sun, 15 Nov 2009, Rickard Bellini wrote:
>
> Hi,
>
> Here is a new log with a corresponding usbmon trace.
> The issue usually occurs in the interval when the device is being
> suspended and the root hub being suspended. If the device sends
> a remote wakup request here, it might end up in a XactErr which
> triggers a device USB reset.
>
> This has been captured using kernel 2.6.32-rc3 with cdc_ether aggressive autosuspend patch and the
> motorola patch for remote wakup issue.
>
> usbmon trace attached.
The trace shows that during the resume following the remote wakeup
request, the kernel failed to receive a response to a Get-Device-Status
request. In fact, the device's port got disabled at that time --
reason unknown. The root hub had not yet begun to autosuspend, so
there's no question of a race between the root hub and the device.
Maybe the device simply wasn't ready in time; it might need a longer
resume delay than the USB specification allows. You can test this by
increasing the resume delay in ehci-hub.c (near line 759 in my copy):
/* Remote Wakeup received? */
if (!ehci->reset_done[wIndex]) {
/* resume signaling for 20 msec */
ehci->reset_done[wIndex] = jiffies
+ msecs_to_jiffies(20);
Change the 20 to something larger, like 50, and see 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
