On Wed, Jul 10, 2013 at 5:21 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> Yeah, I tried that a few days ago. I did a memset() on the >> transfer_buffer prior to every resubmit, because at one point I >> thought perhaps I was getting back the buffer without it having been >> filled in. > > And you found that the buffer was getting filled in, although some of > the data values were wrong? Correct. >> > Finally, compare the data received in the packets surrounding a gap >> > with the data you see from the Beagle-480. Look especially for signs >> > indicating whether the gap represents a packet that was skipped over >> > entirely, or whether the packet was delayed by one microframe and then >> > all the following packets in the URB shifted back accordingly. To do >> > this, you'll need the full data stream recorded by wireshark. >> >> From a data perspective, I don't think that the data is being skipped. >> If the URB were being lost entirely then the rest of the video frame >> would be skewed by the amount of the missing data. The raw video >> frame only tells me where the frame starts and ends, so if data is >> missing then the video data ends up being out of alignment from that >> point forward. Throw a URB on the floor and the entire rest of the >> frame will be shifted. I'm receiving the correct number of bytes, but >> the buffer contains the wrong data. >> >> It's probably also worth noting that I added some debug code to the >> URB completion handler to inject a couple of pixels to mark where the >> isoc packets start/end in the resulting video. That allowed me to see >> that the corrupt bytes always start on a packet boundary, and extend >> only partially into that packet. It's not like the entire packet is >> corrupt - only a portion of it. Once you get past the corrupt portion >> of the packet, the correct video picks up right where it left off. > > Could that happen if no packet was transmitted? The only way I can see > would be if the buffer already contained valid-looking data and it > didn't get overwritten, or if the buffer was overwritten with stale > data left over from the preceding packet. Can you rule out both of > these possibilities? > > So far, your analysis of the received data buffer seems to show that > the computer does receive data from the device, but the Beagle-480 > shows that no data was sent. This is inconsistent. I think I did not explain this clearly. Let me try again: It would appear that the data received by the host and announced in the URB completion handler matches the data received by the Beagle. I see the incorrect bytes in the a microframe in both cases. In fact I've got a script that reconstructs the video frames based solely on the Beagle trace, and I see the same video corruption as I'm seeing on the host. Given that, it is my assertion that the problem has nothing to do with the way the HCD receives the buffers and passes them off to the completion handler. 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 all raises a good question - does the usbmon or wireshark trace >> show isoc data arriving every 125us? If it does, then the host >> controller is magically making up packets and announcing them to >> em28xx even though they were never actually sent across the wire. >> I'll have to take a closer look into that. > > usbmon and wireshark show essentially the same things; the only > difference being that usbmon abbreviates the data (on the theory that > excessive detail is rarely useful). They both look only at URB > submissions and completions; neither one can show what happened while > an URB was in progress. > > So for example, your usbmon trace shows that the URBs did complete at > intervals of 8000 us, although the timing wasn't entirely regular -- > some completions were delayed by as much as 120 us or so relative to > their expected time. The delays did not accumulate, however, and with > a pipeline 40-ms long, they should not have mattered. The microframe > numbers in the trace show that the URBs were scheduled at regular > intervals of 64 microframes. Lack of errors indicates the controller > hardware reported that it executed the transfers at the proper times. 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 it the frame that was received 250us earlier? That might help understand whether the host controller believes that the IN transaction occurred. 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. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
