On Wed, 10 Jul 2013, Devin Heitmueller wrote: > On Wed, Jul 10, 2013 at 11:40 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > >> Nope, that wasn't it. I am now only setting ISO_ASAP in the first > >> packet, and I tried both leaving it as in on resubmit and clearing the > >> flag prior to resubmit. > > > > usbmon is the best debugging tool at this point. > > http://www.devinheitmueller.com/em28xx_usbmon.log > > (only about 290KB). > > I'm just starting to read through it now, but figured it would be > better to send it along while doing such. Probably the biggest issue > at this point is that while I was definitely seeing the corruption on > the screen while creating the trace, I don't yet have a way to > correlate that corruption to a particular spot in the usbmon trace. If you use the bus analyzer at the same time, you could compare microframe numbers. You're using 64 packets/URB, so each URB lasts 8 ms. In addition, you have a pipeline of 5 URBs, for a total of 40 ms. That should be plenty. I don't see any problems in the usbmon trace, but they might not show up there. In particular, the trace includes the status values only for the first 5 packets in each URB. Does the driver encounter any packets with a nonzero status? It could be that you're facing some sort of hardware limitation of the host controller. Can you try running the test on a computer with a different brand of motherboard? 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
