On Mon, 10 Dec 2012, Sarah Sharp wrote: > > > Sure, I'll try to track the right hardware person down. I'm afraid they > > > might not be able to help, because they may not remember hardware that is > > > that old. :-/ > > > > For all I know, newer hardware might behave the same way. It's easy > > enough to test if there's a g-zero gadget at hand, or the equivalent (a > > high-speed device with a bulk-out endpoint that acts as a sink, > > accepting all packets). > > Ok. The hardware devs are asking if this problem is hit on newer > hardware. They think that most of the kinks in the EHCI host should > have been worked out by the Nehalem generation. Do you have access to a > newer EHCI system? If not, I will attempt to find the ez-usb device I > have and learn how to program it. I do have hardware that's newer than ICH5 -- as best I recall, it's ICH9. How does that compare with Nehalem? I never figured out the relation between Intel's code names and part names. There seem to be at least three different ways of describing each piece of hardware. You shouldn't go to much trouble over this. If messing around with ez-usb stuff would take too long, either buy a device controller or forget about it. (PLX Technology even carries USB-3.0 peripheral controllers, but there aren't any Linux drivers for them yet.) > > After some thought, I now have an idea for a workaround: add a 1-ms > > delay whenever a QH is unlinked because of a halt or a dequeue. > > (Presumably 1 ms is enough time.) Since those are exceptional events, > > the extra overhead would be acceptable. > > > > Still, I would like to check with somebody in a position to confirm or > > refute this bug. > > Ok, I'll keep poking at them. I've found someone who did work on the > ICH5 EHCI controller, but he doesn't remember that particular bug. Thanks. 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
