Alan, It was a real hardware error. Turned out it was a bad data bus or memory latch causing bits 16-24 in a word to become corrupted. This _only_ happened when the data was 0xFFFFFFFF and it was very intermittent. This was why I saw a bad offset. The -1 was corrupted to a bad urb_index offset. Don't know why the USB audio code saw that more often than any other code though. Mental note to self: Port a useful memory tester into RedBoot. :) Regards, Christian > On Fri, 4 May 2012, Christian Melki wrote: > > > Turned out I was chasing something likely/partly attributed > to bad hardware. > > Another unit, exactly the same hardware and same software > image, does > > not manifest this problem at all. > > > > I'm however not satisfied with the excuse of hardware problem. > > The consistency and exactness of the error suggests otherwise (even > > the same invalid value in the urb_index every time.). > > I had no other problems with the machine, including USB, > what so ever. > > This _really_ bugs me. > > Too bad. Things like that can be very hard to diagnose. > > > I know to little about USB, but is it possible that bad data is > > slipping in somewhere from hardware that is not sanity > checked (USB crc)? > > Very unlikely. Even if it were, the data you're dealing with > (iTD index array and so on) does not come from the hardware; > it is entirely internal to the host OS. > > > I don't intend to chase this further if it does not rear > it's ugly head again. > > Well, unless someone want's me to test anything specific. > > > > Thanks a lot for your help Alan, > > I really appreciated it. > > You're welcome. Good luck. > > 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
