On Sat, Dec 08, 2012 at 11:02:00PM -0500, Alan Stern wrote: > On Fri, 7 Dec 2012, Sarah Sharp wrote: > > > On Fri, Dec 07, 2012 at 05:51:55PM -0500, Alan Stern wrote: > > > Sarah: > > > > > > I just tracked down a tricky problem, which appears to be caused by a > > > genuine hardware bug. It's hard to believe this has escaped everyone's > > > notice for so many years -- maybe my results are wrong. But as far as > > > I can tell, they aren't. > > > > > > Anyway, I don't know what to do about it. Can you forward this message > > > to an appropriate person at Intel? > > > > 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. > 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. 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
