On Wed, 10 Jul 2013, Devin Heitmueller wrote: > > 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. I'd prefer to think of them as very unlikely possibilities. :-) > > 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. And you found that the buffer was getting filled in, although some of the data values were wrong? > > 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. > 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. 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
