--- On Thu, 2/10/11, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote:
>
> 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
I don't mind the reset. I didn't find it to be too slow.
As this is what works for me right now, I'll commit my patch to the
free-linux branch. Feel free to submit it as your own, or git-cherry-pick
it from the free-linux branch, or come up with whatever else.
If you come up with something different, CC me and I can merge and test
it as well.
> 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.
Not sure. Haven't paid attention to this.
> > Sometimes I'll have to remove and insert back the xhci
> driver.
>
> Oh, remove the xHCI express card, you mean?
No. The xhci-hcd module.
> 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?
It's a split 30/70 between the ports. Could be electrical.
Luben
--
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
