On Monday 31 January 2005 6:34 am, Olav Kongas wrote: > > usbtest 1-1:3.0: ctrl_out, byte 64 is 138 not 134
That is, the buffer sent _back_ from the gadget wasn't what was sent _to_ it. > I suspect that the problem occurs in the gadget side. My suspicion would have been that the new driver is at fault, in this case the isp116x driver. Especially since the relevant code on the gadget side (net2280.c, zero.c) haven't changed how they do that stuff for ages and ages. That said: you mentioned chip markings on that net2280 device, and they match what I have on an old rev1 (0100) RDK board. And I've always had problems getting that to work at full speed. Only early developers saw rev1 parts, as I understand it, and most of them updated to rev1a; no products should have shipped with rev1. The net2280 driver should announce rev1a (0110) as it starts up ... what does it say for you? > - the data (69 bytes) is read by gadget into the > req->buf; the data is incorrect!!! This could also indicate a hardware quirk on the host side, sending the wrong data. That's the first byte of the second packet ... can you tweak the host side so that it sends one packet at a time, rather than sending larger transfers? (Just as an experiment, of course; that'd slow things down otherwise.) If that starts working, it could still be a problem on either side. In fact, digging out some old docs on net2280 errata ... I think rev1 erratum 0106 may be just the ticket (fullspeed, rev1, fixed in rev1a, only a partial workaround was possible). You might have a workaround of using a faster PCI host with the net2280. > - the following message is issued to the logs: > zero gadget: zero_setup_complete: setup complete --> -75, 69/69 Which as Alan pointed out, indicates the host sent more bytes than expected. (Or for net2280: any extra OUT packet before the ep0 status stage.) What happens if you turn on the debug messages in the net2280 driver? It should tell you in more detail _why_ it reported that fault. > - 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? Doesn't ring any particular bells. But do make use of the debug messages in the net2280 driver ... that chip is more flexible than most, you can get an IRQ for each packet during a control transfer. So it should be easy to catch the exact instant something goes "wrong". Watching for those failures inside "zero.c" hides the data you'll most want to see, when tracking down such low level issues. However that's the natural place to add extra logic like "if the ep0 OUT buffer isn't in the pattern [byte N+1] = [byte N] + 1, print the buffer" that might help find patterns. - Dave ------------------------------------------------------- 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
