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. > it the frame that was received 250us earlier? That's why I suggested you examine the wireshark data in detail. > That might help > understand whether the host controller believes that the IN > transaction occurred. The host controller undoubtedly _does_ believe this. Or at least, that's what it indicates to the CPU, by setting the iTD's transaction status to 0. Unless for reason the iTD data structure was set up wrongly in the first place... > I'll work on seeing if I can correlate the data between the Beagle > trace and the usbmon trace, so I can see what the host *thinks* > happened immediately prior to the corrupt microframe. Good. 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
