On Fri, Jun 26, 2009 at 03:16:07PM +0200, Zimmermann Christoph wrote: > hi all > > here is now a first, hopefully usefull, bugreport for the usbtmc driver: What kernel are you using? > executed commands: > root@miniprijv:# echo "*ese?" > /dev/usbtmc0 > root@miniprijv:# cat /dev/usbtmc0 > 0 > cat: /dev/usbtmc0: Die Wartezeit für die Verbindung ist abgelaufen <-- this means a timeout occoured > > usbmon output: > d0c7f080 2338333712 S Bo:1:030:2 -115 20 = 0101fe00 06000000 01000000 2a657365 3f0a0000 > d0c7f080 2338333786 C Bo:1:030:2 0 20 > > f6719b80 2339955647 S Bo:1:030:2 -115 12 = 0202fd00 e2070000 000a0000 > f6719b80 2339955714 C Bo:1:030:2 0 12 > > f6719b80 2339956096 S Bi:1:030:6 -115 2048 < > f6719b80 2339956211 C Bi:1:030:6 0 15 = 0202fd00 02000000 01000000 300a00 > f6719b80 2339956374 S Bo:1:030:2 -115 12 = 0203fc00 e2070000 000a0000 > f6719b80 2339956460 C Bo:1:030:2 0 12 > > f6719b80 2339956572 S Bi:1:030:6 -115 2048 < > f6719b80 2339975592 C Bi:1:030:6 -2 0 > f6719b80 2339975722 S Ci:1:030:0 s a2 03 0004 0086 0002 2 < > f6719b80 2339975838 C Ci:1:030:0 0 2 = 8104 > > > when I execute this command, I get the correct response of the client device AND a time-out > error message. > the problem here is, that the usbtmc driver requests to many data from the device. > as you can see in the usbmon log above in transaction 2339955647 the host sends a > REQUEST DEVICE DEPENDENT IN TRANSFER, this is ACK'd from the client. the host then does a in > transfer (transaction 2339956211) and gets the correct information from the device. > the device reports a correct transfer size in the tmc IN header of 0x02 (ASCII 0 and LF) and > also sets the EOM (end of message bit) according to the tmc specs. > > then, after the tmc message is finished the driver sends another > REQUEST DEVICE DEPENDENT IN TRANSFER (2339956374) and tries to read > data from the device again. the device has no data queued and NAK's > the transfer and stalls the endpoint (according to tmc specs page 12, > paragraph 2). > > the last part in the usbmon log is ok, the host detects an error and > tries to abort the last started action, the tmc in transfer. the > device responds also correctly (0x81) that no such transfer has > started, i've seen other devices responding SUCCESS also when no > transfer has started before. So what should the proper response for the kernel driver be in this situation? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
