Alan Here are the results again.
The few transactions for the time period before the "command_abort called" are typically like below 1. Host sends 512 bytes OUT packet which is ACKED. 2. Host sends 13 bytes IN packet which is ACKED. 3. Host sends 31 bytes OUT packet which is NYETD. 4. Host sends PING packet which is ACKED. 5. Repeat of sequence 1-4 I am producing the usb-storage log for transaction that happened right before transaction that produced 30 seconds delay. usb-storage: usb_stor_bulk_transfer_sglist: xfer 512 bytes, 1 entries usb-storage: Status code 0; transferred 512/512 usb-storage: -- transfer complete usb-storage: Bulk data transfer result 0x0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0x115 R 0 Stat 0x0 usb-storage: scsi cmd done, result=0x0 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command WRITE_10 (10 bytes) usb-storage: 2a 00 00 01 8c ed 00 00 01 00 usb-storage: Bulk Command S 0x43425355 T 0x116 L 512 F 0 Trg 0 LUN 0 CL 10 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 As you see,the above log follows the sequence that i described in the begining. The catalyst log for the same period shows 1. Host sends 512 bytes OUT packet which is ACKED. 2. Host sends 13 bytes IN packet which is ACKED. 3. Host sends 31 bytes OUT packet which is NYETD. 4. After 1ms,Host sends PING packet which is ACKED. Per usb-storage log,the above transcation is followed transaction that is aborted. usb-storage: usb_stor_bulk_transfer_sglist: xfer 512 bytes, 1 entries usb-storage: command_abort called usb-storage: usb_stor_stop_transport called usb-storage: -- cancelling sg request usb-storage: Status code -131; transferred 0/512 usb-storage: -- transfer cancelled usb-storage: Bulk data transfer result 0x4 usb-storage: -- command was aborted usb-storage: usb_stor_Bulk_reset called usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0 usb-storage: Soft reset: clearing bulk-in endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=82 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset: clearing bulk-out endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=01 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset done The catalyst log for the same period shows 1. Host sends 512 bytes OUT packet which is ACKED. 2. Host sends 13 bytes IN packet which is ACKED. 3. Host sends 31 bytes OUT packet which is NYETD. 4. After 30 seconds,Host initiate control transfer to reset the device,clear bulk-in ep halt abd clear bulk-out halt which matches usb-storage log. Even though "usb-storage: Status code -131; transferred 0/512" gives impression that no bytes were transferred, the catalyst log in fact shows that 512 bytes were tranmitted followd by IN-13 and OUT-31 successfully. Note that usb-storage log did not have any entry for IN-13 and OUT-31 transactions. It was hard for me to co-relate the usbmon with records from usb-storage and catalyst.Perhaps,you can co-relate them. Below are the usbmon entries for time periods before the 30 seconds transaction. The right most column is difference between time-stamps in seconds. 810c93e0 1296380816 S Bo:002:01 -150 31 D 0.006 810c93e0 1296386816 S Bo:002:01 -150 31 D 0.006 810c93e0 1296392816 S Bo:002:01 -150 31 D 0.006 810c93e0 1296398816 S Bo:002:01 -150 31 D 0.009 810c93e0 1296407816 S Bo:002:01 -150 31 D 0.006 810c93e0 1296413816 S Bo:002:01 -150 31 D 0.006 810c93e0 1296419816 S Bo:002:01 -150 31 D 0.006 810c93e0 1296425816 C Bi:002:02 0 13 D 0.008 814817a0 1296433816 C Bo:002:01 0 512 D 0.007 814817a0 1296440816 C Bo:002:01 0 32768 D 0.009 81481740 1296449816 C Bo:002:01 0 40960 D 0.01 810c93e0 1296459816 C Bi:002:02 0 13 D 0.008 81481740 1296467816 C Bo:002:01 0 40960 D 0.007 814817a0 1296474816 C Bo:002:01 0 20480 D 0.007 810c93e0 1296481816 C Bi:002:02 0 13 D 0.008 814817a0 1296489816 C Bo:002:01 0 512 D 0.009 814817a0 1296498816 C Bo:002:01 0 512 D 0.008 810c93e0 1296506816 C Bo:002:01 0 31 D 0.01 810c93e0 1296516816 C Bi:002:02 0 13 D 30.002 I hope that i have provided the correct information. Let me know if you need more info. Thanks. Regards Vivek -----Original Message----- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 8:08 AM To: Vivek Dharmadhikari Cc: David Brownell; USB development list Subject: RE: [linux-usb-devel] Usb hangs during small and large file transfer On Tue, 6 Jun 2006, Vivek Dharmadhikari wrote: > >I can't. In any case, you don't need to pull the device out of NYET > >state; you need to push the host controller to send another PING. > > I wonder if the act of pushing host controller to send another PING is > done in the software or in the hardware automatically. In other word, do > the driver signal host controller to send a PING packet ? or is it that > the host controller sends the PING packet as part of flow control ? My > opinion is that the hardware controller sends the PING packet. I may be > wrong here. Obviously you are wrong, because the PING packet isn't getting sent! More specifically, the hardware is _supposed_ to send the PING packet automatically as part of flow control. The fact that it doesn't means that something is wrong with the hardware. The driver may be able to compensate for this hardware bug, but someone (probably you!) will have to write special code to do it. Alan Stern _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
