On Fri, 2 Sep 2005, [Big5] ·¨®pªQ wrote:

> Hi,
> 
> Recently I am writing a program to test the flash card through card
> readers with Linux 2.6.12.5. Module usb-storage is used so that I can
> open the device "/dev/sdX" to do raw read/write tests. The flash cards
> are all of the same capacity. And all the card readers are the same
> (VID, PID, serial numbers, etc.). At least two pairs of card/carders are
> tested at the same time.
> 
> If they are connected to the root hub ports, the tests seem mostly okay.
> If a hub is used, they become much easier to fail and /dev/sdX will
> become inaccessible ("No such device or address", etc...) although still
> present after some long delays. The probability of failure depends on
> which hub is used (I think it's a signal quality issue -- PHY issue).
> After inspecting the USB bus, I find that the device failed to respond
> correctly when this condition happens. For example, it always NAK'ed
> when something is wrong. However, the host should be able to do error
> recovery. That is, do port reset to recover it.
> 
> Kernel 2.6.13 will do better. However, sometimes the I/O operation will
> still fail.

Can you provide more details?  Does the operation fail because the device 
doesn't respond to the port reset?  What shows up in the system debugging 
log if you turn on CONFIG_USB_STORAGE_DEBUG?

>  Then I have to close the file descriptor and reopen the
> /dev/sdX to continue testing. Nevertheless, occassionally the I/O
> operation will hang there even after all the readers are unplugged.

Will hang where?  Can you provide Alt-SysRq-T stack traces and a debugging
system log with CONFIG_USB_DEBUG (as well as CONFIG_USB_STORAGE_DEBUG)
turned on?

> lsusb will hang also. All accesses to my USB devices hang. A power cycle
> of Linux is required to solve this problem so that I can't used Kernel
> 2.6.13. (The USB system of Kernel 2.6.12 is still possible to hang like
> 2.6.13. However, the probability seems lower)
> 
> I am curious if I can do my user-space error handling. That is, reset
> the storage device when /dev/sdX becomes inaccessable with the presence
> of usb-storage since some testings of other devices may be still
> running? I do a ioctl(fd, IOCTL_USB_RESET, NULL) to
> /proc/bus/usb/00X/00X and it succeeds.

Are you talking about 2.6.12 or 2.6.13?  If you mean 2.6.13, would solving
those I/O hangups remove the need for user-space error handling?  It
sounds like you already have a way to reset the storage device, so what is
your real question here?

>  Howerver, the block device is
> still inaccessible. Something when I write the string "running" to
> /sys/block/sdX/device/state, the block device will be accessible again.
> Is there a formal user-space command sequence to do this kind of job?

Normally when a device misbehaves too badly, the SCSI core sets it offline 
and just leaves it.  That's what's happening to you.  By writing to the 
sysfs file you are bringing it back online, so that commands will once 
again be sent to the device.  There is no "formal" command sequence to do 
this, any more than there is a "formal" command sequence to display the 
contents of a file.  Any procedure that sends the correct characters to 
the correct sysfs file will be okay.

Alan Stern



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to