On Thu, 4 Jan 2007, Uwe Bonnes wrote: > Hallo, > > looking at the disk line of xosview with dd if=/dev/sdX, with x for some > plugeed some USB Stick, I often saw dropouts. Changing cable to the hub in > between mades things better. But even with two sticks connected direct to > the root hub at the PC enclosure, one sequence lead to repeatable dropout: > Start "dd" on a PNY 2GB stick ( 154b:0005).Disk throughput is about 11 > MByte/sec. Start "dd" on a USB Stick with MMC/SDC connector > (058f:6331). Throughput drops to about 4 MByte/s, as observed with that > stick alone. Type "^C" on the controlling terminal of the second dd > process. Displayed throughput drops to Zero and recovers after about 60 > secondsto about 11 MByte/s, as seen on the PNY Stick
There may be electrical or electromagnetic interference problems between the two ports on your computer's USB controller. When both ports are in heavy use this could affect the total throughput. If you only do I/O to one of the sticks at a time, does everything work okay? > With usbmon active (on Suse-10.2, 2.6.18.2-34-default, Epox KRA8+ Athlon > Board with Via chipset), PNY is at endpoint 30 and the other stick at 31. 30 and 31 are device addresses, not endpoint numbers. > Everything goes fine with interleaved setup and callback on 030 and 031 > Here the last Setup stages on 030 before the error: > dd46c740 3105613436 S Bi:030:01 -115 4096 < > cacbe4e0 3105613437 S Bi:030:01 -115 4096 < > dbb6b1e0 3105613439 S Bi:030:01 -115 4096 < > ... > dd46c740 3105623650 C Bi:030:01 0 4096 = 36907096 fbb1fd78 0dda11c9 4a... > cacbe4e0 3105623652 C Bi:030:01 0 4096 = d0af550c a56cb605 f61522ba 7f1... > dbb6b1e0 3105623653 C Bi:030:01 -121 3085 = 14b1b205 fe41cbec 995961bb ... > d8ca3e60 3105623665 S Bi:030:01 -115 13 < > dd416120 3105628831 C Bi:031:02 0 4096 = 3b46fde0 f76b0073 85828edd a... > > endpoint 030 reports EREMOTEIO. The next thing on endpoint 030 is > > d8ca3e60 3165612107 C Bi:030:01 -104 0 > > It takes about 60 seconds until ECONNRESET happens, as I understand > initiated from the stick. No; it is initiated by the SCSI core, which has timed out waiting for previous command to complete. Apparently the stick has crashed -- it is no longer sending any data. > Isn't there anything the USB layer may do about > that error to recover earlier? Shouldn't the USB layer react somehow on the > short read? The USB layer does react to the short read. You can see the reaction in your log, on the line with timestamp 3105623665. usb-storage asks the device for the status of the last command and doesn't get a reply. The length of the timeout is not determined by any of the USB drivers; it is set in the SCSI sd driver. You can see it in drivers/scsi/sd.c: /* * Time out in seconds for disks and Magneto-opticals (which are slower). */ #define SD_TIMEOUT (30 * HZ) #define SD_MOD_TIMEOUT (75 * HZ) Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
