On Wed, Feb 09, 2011 at 08:44:14PM -0800, Luben Tuikov wrote:
> --- On Wed, 2/9/11, Luben Tuikov <ltuikov@xxxxxxxxx> wrote:
> >
> > I think that seems like the easiest solution for now. I'm
> > testing something
> > like that now.
>
> Sarah,
>
> The following patch works for me:
> ---------------
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 4310cc4..5c28bf9 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2680,11 +2680,13 @@ hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
> delay = HUB_LONG_RESET_TIME;
>
> mutex_lock(&usb_address0_mutex);
> -
> +#if 0
> if (!udev->config && oldspeed == USB_SPEED_SUPER) {
> /* Don't reset USB 3.0 devices during an initial setup */
> usb_set_device_state(udev, USB_STATE_DEFAULT);
> - } else {
> + } else
> +#endif
> + {
> /* Reset the device; full speed may morph to high speed */
> /* FIXME a USB 2.0 device may morph into SuperSpeed on reset. */
> retval = hub_port_reset(hub, port1, udev, delay);
> ---------------
Ok, that's good to know. I'd like to poke around the hub code and see
if we can come up with something better that avoids the reset. In
particular, I wonder if we can add a call into the xHCI driver to
de-allocate the address when usb_disable_device() is called.
> Overall, I've noticed that sometimes (with and without this patch),
> unplug/plug cycle doesn't re-discover the SS device. This seems unrelated
> the the patch above.
Yes, it could be hardware related. Do you see any port status event
printks from the xHCI driver when you unplug and replug it in? If so,
it could be a problem with the xHCI driver or USB core. If you're not
getting any events at all, the hardware is just not detecting the
connection.
> Sometimes I'll have to remove and insert back the xhci driver.
Oh, remove the xHCI express card, you mean? That's interesting. I'm
not quite sure what could be wrong there. Possibly the hardware went
off into la-la land. I have noticed that if the xHCI driver has buggy
ring code (and it has in the past), the hardware will step off the edge
of the ring and start executing random memory. Paul Zimmerman also
posted some TRB math patches that fix some bugs in the ring code, so
it's possible those might cause the hardware to do odd things.
> The patch above, succeeded for one port of the controller and failed for
> another, meaning the device was disconnected:
>
> Feb 9 20:29:00 localhost kernel: hub 9-0:1.0: state 7 ports 4 chg 0000 evt 0004
> Feb 9 20:29:00 localhost kernel: hub 9-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
> Feb 9 20:29:00 localhost kernel: usb 9-2: USB disconnect, address 5
> Feb 9 20:29:00 localhost kernel: usb 9-2: unregistering device
> Feb 9 20:29:00 localhost kernel: usb 9-2: unregistering interface 9-2:1.0
> Feb 9 20:29:00 localhost kernel: usb 9-2: unregistering interface 9-2:1.1
> Feb 9 20:29:00 localhost kernel: usb 9-2: usb_disable_device nuking all URBs
> Feb 9 20:29:00 localhost kernel: hub 9-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
>
> On another try, a different controller port, the above was NOT seen and
> the device successfully persisted after changing it's descriptors.
I wonder if one of your ports has some electrical noise? Is it always
the same port that doesn't work?
Sarah Sharp
--
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
