On Wed, 2 Apr 2003, David Brownell wrote:
Well, all the evidence points to it being quiescent. It would be more useful to teach usb-storage to dump useful state in a sysfs file, so it can be accessed on-demand rather than needing to be "stored" in dmesg output ... :)
That's an intriguing idea. Did you say that your whole system was hanging or just the 'dd' process? Obviously if it's the whole system then doing this won't help to solve your current problem.
Just the DD. Though there may be additional failure modes; this one was interesting in part because it was the first one I saw, and in part because it suggests failures in a "new" area of code: not usbcore/hcd related, or related to insufficient SCSI-ness in the hardware.
What sort of information would it be useful to expose in this way? A few possibilities that would be easy to implement (stored in the per-device data structure in usb-storage) are:
1. The current state of the driver: IDLE, RUNNING, RESETTING, or ABORTING.
2. A couple of flag bits: urb in progress, sg_request in progress.
Make them human-comprehensible strings instead ... maybe even saying what the command was.
3. Address of the current scsi_cmnd block (if any).
4. Count values for various semaphores/completions: device in use, awaken control thread, wait for abort to complete.
Sounds right. Perhaps also listing any device quirks.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
