On Fri, 28 Apr 2006, Marc Singer wrote: > > > 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.
Sorry, my mistake. The first packet (0 above) is a SETUP packet, not a data packet. It is followed by 6 data packets each of length 8 (1-6), plus a short data packet of length 3 (7), and a supposedly 0-length handshake packet (8). The total data length is indeed 51. > Where is the part where the device is sending back more than zero > bytes? Are you talking about line 7? No, line 8. It is the handshake stage of the control-OUT transfer. The host sends an IN packet and the device is supposed to send back a 0-length DATA1 packet. 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
