On Tue, 18 Jan 2005, Philipp Schmid wrote: > usb-storage: usb_stor_bulk_transfer_sglist: xfer 1024 bytes, 1 entries > usb-storage: Status code 0; transferred 832/1024 <= single PTD > usb-storage: -- short transfer > usb-storage: Bulk data transfer result 0x1
I haven't seen these messages. All my 3 storage devices work smoothly. Also, usbtests #1-8 (bulk transfer tests) seem to work reliably. > This case did not seem to happen before importing your latest changes > (likely because this case wasn't hit). The main changes being PTD length > handling in start_atl_transfers() and changes in postproc_atl_queue(). > Changing MAX_TRANSFER_SIZE_FULLSPEED doesn't seem to help. I also changed endianness handling. Though, if there was something wrong with that, it probably wouldn't work at all for you. Did you have to correct endianness? > PTDs: > > start_atl_transfers > pack_fifo @ f6d6/2e8c fmrem > CC=f EP=2 DIR=2 CNT=0 LEN=13 MPS=64 TGL=1 ACT=1 FA=2 SPD=0 LST=1 B5=0 > fc00 2840 080d 0002 > unpack_fifo @ f6d8/7b fmrem <= Note the late unpack Late unpacking *shouldn't* be a problem. > read_ptddata_from_fifo 2 13 > CC=f EP=2 DIR=2 CNT=0 LEN=13 MPS=64 TGL=1 ACT=1 FA=2 SPD=0 LST=1 B5=0 > fc00 2840 080d 0002 > ----- > start_atl_transfers > pack_fifo @ f6db/2e98 fmrem > CC=f EP=2 DIR=2 CNT=0 LEN=13 MPS=64 TGL=1 ACT=1 FA=2 SPD=0 LST=1 B5=0 > fc00 2840 080d 0002 > unpack_fifo @ f6dd/7b fmrem > read_ptddata_from_fifo 2 13 > CC=f EP=2 DIR=2 CNT=0 LEN=13 MPS=64 TGL=1 ACT=1 FA=2 SPD=0 LST=1 B5=0 > fc00 2840 080d 0002 > ..... continues This log shows that the device is NAK-ing the request. One reason may be that the device is not ready to send the last portion of the data. But fig.8-33 in usb 2.0 spec shows also another possible reason: host should do the same command also when it gets otherwise correct data, but just the toggle bit does not match. This would mean that the device already sent the latter portion of the data, which HC ignored, because it expected another toggle value, while the device just has nothing more to send. It may well be that I haven't got the toggle bit handling after errors right in the driver. The isp chip seems to have its own understanding of what to do with the toggle bit in case of errors and this does not fit with the spec; neither have I found it documented anywhere. Perhaps your system triggers some (recoverable) error conditions, which I don't see here and haven't therefore straightened out. I will take another look at the toggle bit handling. It would help if you could post PTD dumps from both older (working) and the latest driver versions so that the Toggle bit history for bulk transfers could be compared. Olav ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
