On Fri, Apr 28, 2006 at 09:56:26AM -0400, Alan Stern wrote: > On Thu, 27 Apr 2006, Marc Singer wrote: > > > I may have been a little hasty. This new driver *does* work properly > > on the lh79524. It still fails test 14 on the lh7a404. I am now very > > suspicious that this is a hardware issue and not a software error. > > > > In a nutshell, on receipt of some ep0 OUT messages, I see all of the > > packets from the host including the short packet that completes the > > read. I clear the packet ready and set the DATA_END bits and wait for > > a new message. The host never sends one. It reports on overflow > > which I assume means that it didn't get the response it expected. > > > > This doesn't happen all of the time. I may have as many as 220 > > exchanges in test 14 before one of the transfers fails. > > > > Once I fixed a race, the lh79524 controller works fine with the driver > > as is. > > > > Below is dmesg output from the host. > > > > usbtest 2-2:3.0: TEST 14: 15000 ep0out, 1..256 vary 1 > > uhci_hcd 0000:00:1d.1: uhci_result_control: failed with status 500000 > > [ef0e1180] link (2f0e1142) element (1c145300) > > Element != First TD > > 0: [dc145000] link (1c145030) e3 Length=7 MaxLen=7 DT0 EndPt=0 Dev=2c, > > PID=2d(SETUP) (buf=2e823a00) > > 1: [dc145030] link (1c145060) e3 Length=7 MaxLen=7 DT1 EndPt=0 Dev=2c, > > PID=e1(OUT) (buf=2395d6c0) > > 2: [dc145060] link (1c145090) e3 Length=7 MaxLen=7 DT0 EndPt=0 Dev=2c, > > PID=e1(OUT) (buf=2395d6c8) > > 3: [dc145090] link (1c145180) e3 Length=7 MaxLen=7 DT1 EndPt=0 Dev=2c, > > PID=e1(OUT) (buf=2395d6d0) > > 4: [dc145180] link (1c1451e0) e3 Length=7 MaxLen=7 DT0 EndPt=0 Dev=2c, > > PID=e1(OUT) (buf=2395d6d8) > > 5: [dc1451e0] link (1c145240) e3 Length=7 MaxLen=7 DT1 EndPt=0 Dev=2c, > > PID=e1(OUT) (buf=2395d6e0) > > 6: [dc145240] link (1c1452a0) e3 Length=7 MaxLen=7 DT0 EndPt=0 Dev=2c, > > PID=e1(OUT) (buf=2395d6e8) > > 7: [dc1452a0] link (1c145300) e3 Length=2 MaxLen=2 DT1 EndPt=0 Dev=2c, > > PID=e1(OUT) (buf=2395d6f0) > > 8: [dc145300] link (00000001) e3 IOC Stalled Babble NAK Length=7ff > > MaxLen=7ff DT1 EndPt=0 Dev=2c, PID=69(IN) (buf=00000000) > > > > usbtest 2-2:3.0: ctrl_out, wlen -75 (expected 51) > > > > It is odd to me that this list shows 7 byte packets when the target is > > reading 8 byte packets. In both cases, the byte totals are 51. > > What you don't realize is that the UHCI hardware stores the packet length > - 1, not the length itself. So the first seven packets above actually are > 8 bytes long, the second to last is 3 bytes (total 59), and the last -- > which constitutes the status stage of the control transfer -- is supposed > to have length 0. The fact that the device is sending back more than 0 > bytes is what causes the overflow error.
Are the extra bytes framing? You can see that even usbtest thinks this is a 51 byte message. Where is the part where the device is sending back more than zero bytes? Are you talking about line 7? ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
