On Wed, Jul 10, 2013 at 09:13:09PM -0400, Alan Stern wrote: > On Wed, 10 Jul 2013, Devin Heitmueller wrote: > > > So one might ask: why is the em28xx device sending a microframe with > > corrupt bytes? One thing I've noticed is immediately prior to any > > microframe containing corruption, there was a missing microframe - the > > time between the microframe containing corruption and the previously > > received microframe was 250us, and not 125us as expected. My > > speculation is that the failure of the host controller to ask for that > > missing microframe causes some confusion in the em28xx, which results > > in it sending the wrong bytes in the next microframe. Alternatively > > the em28xx has some sort of circular buffer, and failing to ask for > > the microframe causes the circular buffer to wrap around (so the next > > microframe sent contains bad data). > > This is what I've been trying to get at. The usbmon timing data shows > that the host controller thinks a packet was sent and received during > the "missing" microframe. The data you saw in the buffer proves that > the controller did write _something_ to memory during the "missing" > microframe -- where did that something come from? > > > Wireshark appears to be showing the URB timing, but really what we're > > interested in is the microframe timing. That said, it would be good > > to know what is in the microframe that is immediately prior to the > > microframe containing corruption. Is it a zero length microframe? Is > > That's why I suggested you zero the buffer before resubmission and have > the driver check the packet descriptor's actual_length value. I took a peek at the usbmon log, and there is one thing I don't get. $ grep "C Zi:1:005:2" em28xx_usbmon.log | less -S There are several cases where the isoc descriptor actual length is short (< 2892, e.g. 0, 552 or 1928), yet the actual_length for the whole URB at the end of the line is still 64*2892 -- is that like it should be? Also, is it expected that the em28xx doesn't have data to send for some microframes (for analog video capture e.g. during horizontal or vertical blank interval)? I guess in the analyzer that should show as an IN token with no reply instead of DATA[012] replies. Can you confirm that in the error case there is no IN token at all? And another dumb question: Is there another USB video grabber with different hardware which also uses isoc and works? E.g. the cx231xx? Or do you think it might have the same missing microframe issue but copes better with it due to larger buffer space on the device? Johannes -- 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
