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. 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)? 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. Regards, Christian > -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: den 3 maj 2012 17:21 > To: Christian Melki > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: RE: Easily reproducible Linux 3.3.2 Oops in ehci_work(). > > On Thu, 3 May 2012, Christian Melki wrote: > > > Alan, > > > > I get a broken urb_index, pointing the lookup somewhere > really obscure. > > What are the values stored in the itd->index array? What is > the value of uframe? > > itd->index gets initialized to -1 in itd_init() and then set to the > correct value in itd_patch(). Can you check the values > stored in itd_patch()? And compare them with > itd->urb->number_of_packets? > > 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
