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.
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.
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.
> Do you happen to know of such problems in those intermediate levels?
>
> I was under the impression that the block layer was pretty stable by
> now, though the SCSI code was (still) in flux.
I thought so too, and I don't know of any such problems. Maybe this is a
new one?
Alan Stern
-------------------------------------------------------
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
