On Wed, Jul 10, 2013 at 3:37 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > 20-30 times each second? Okay... I didn't realize the errors were > that frequent.
Yeah, now you see why I'm freaking out. If this were one corrupt line every 20 seconds, I wouldn't care less. But there are lines every few frames of video (and we're doing 30 frames/second). This isn't the sort of problem that is only apparent to a video engineer who knows what to look for - It's highly visible even to non-technical viewers. > It's rather disturbing that they don't show up at all in the usbmon > trace. This suggests two possibilities: > > The ehci-hcd driver is so messed up that not only did it fail > to tell the hardware to send those missing packets; it also > thought they had been sent and gotten replies! > > The controller hardware is so messed up that it failed to send > the missing packets but then stored a status value indicating > that they had been sent and replies had been received! Either of these are possibilities. > Both possibilities are rather unsettling. Fortunately, they aren't > exhaustive -- something else might be going on. > >> > If you want to investigate further, you can capture the entire data >> > stream using Wireshark. (Of course, that means capturing 22 MB/s of >> > data.) >> >> Will that get me any new data/context I'm not already getting with the >> bus analyzer? I'm not against doing a Wireshark capture if it gets me >> access to some internal state of the USB stack that wouldn't be >> available to the Beagle, but at this point I've got scripts written to >> parse the Beagle data so it's not clear what the benefit would be. > > Here's an approach that might prove informative. Clear the transfer > buffer to all zeros before resubmitting each URB (or store some other > recognizable pattern in the buffer). When checking the completed URB, > verify that each packet not only has a 0 status value but also has the > right actual_length value and has new data in the transfer buffer. 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. > 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. 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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
