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. Alan Stern ------------------------------------------------------- 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
