On Mon, 31 Jan 2005, Olav Kongas wrote: > Hi, > > I am running usbtest #14 with the isp1160 chip as a host and > net2280 based pci card as gadget with g_zero driver. About > 2-3 times of 1000 runs, the test fails with the messages > like that: > > usbtest 1-1:3.0: ctrl_out, byte 64 is 138 not 134 > > where in the particular case it transferred 69 bytes. The > failure seems more or less random; though the following > features seem to be always present: > > 1. It is an odd number of bytes to transfer. > 2. The full Maxpacket-size chunks are transferred correctly, > the first wrong byte resides at the beginning of the "short" > packet. > 3. The bytes in the wrong data are reordered, but I haven't > recognized a pattern in reordering. In the particular case > there are just bytes 86 and 8a swapped, but with more data > in the short packet, the reordering is more complex. > > I suspect that the problem occurs in the gadget side. Here > is a summary of how the test failed and below come the logs. > > - the data (69 bytes) is written into the HC fifo > - the data is transferred over the usb bus to gadget > - the data is read back from the HC fifo and it is correct > (exactly the same that was written in) > > - the data (69 bytes) is read by gadget into the > req->buf; the data is incorrect!!! > - the following message is issued to the logs: > zero gadget: zero_setup_complete: setup complete --> -75, 69/69 > > - the data is requested back from the gadget by HC > - 69 bytes are obtained and the data is incorrect, being > the exact copy of the incorrect data seen already in the > g_zero driver > > I don't have a USB analyzer, therefore it wouldn't be > trivial for me to check the data on the wire. > > Has anybody seen something like that earlier? How to debug > this further?
This is very interesting. It's reminiscent of other reports about data corruption in USB mass-storage devices, although the underlying cause is probably different. The -75 (= -EOVERFLOW) error in zero_setup_complete indicates that the gadget believed it received _more_ than 69 bytes, for whatever that's worth. If you can figure out a way to use a different sort of test device (one not based on the Netchip card), that would tell you whether the error was introduced by the device controller or the host controller. You can try running test #14 with the Netchip card plugged into a regular PC's USB host controller and see if the same sorts of errors occur. Also, you can try writing to Netchip's technical support. Ask Alex Sanks if he has any idea if the controller could be causing this error. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
