On Wed, 10 Jul 2013, Devin Heitmueller wrote: > Hi Alan, > > On Wed, Jul 10, 2013 at 2:27 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > You inspired me to take a closer look at the usbmon log you made > > available. There _is_ an error indication after all; the line with > > timestamp 397263317 got an error in one of its 64 packets (but this > > was the only error in the entire trace). The trace doesn't say what > > the error was or which packet it occurred in. This error should have > > shown up in your driver as a nonzero value for the packet status. > > I probably should have better qualified my previous statement. Every > once in a while there is an actual -EOVERFLOW condition, which will > result in that one frame being a bit corrupted. Those cases do show > up in the URB handler via the status field. That said though, the > problem I'm debugging happens 20-30 times a second, so I'm looking for > something much more prevalent than one error in a five second capture. 20-30 times each second? Okay... I didn't realize the errors were that frequent. 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! 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. 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. 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
