On Wed, 2 Apr 2003, David Brownell wrote:
I generally find the usb-storage messages to be unusable; there's so much "this worked right, that too, hey so did this" going on (surely at least a dozen per request!) that any messages about things that went wrong get drowned in the noise. And those delays have *always* negatively affected timing-related bugs: slowdowns of two or three orders of magnitude. It'd be different if it were only reporting errors (or even just faults) -- those hardly ever happen, so printing out messages then wouldn't break anything.
Yeah, it would be awfully unwieldy and it might not show you anything in the end. But sometimes it helps to have the "success" messages as well as the "failure" messages since together they delineate the overall flow of control. Things like what you saw often don't happen because something specific goes wrong that would show up in an error log; they happen because the flow of control got derailed somewhere.
Right "sometimes" it helps to see "success" too ... but as a rule, it's just noise. The policy I usually adopt is that only "verbose" debug messages expose flow-of-control, and I've found that I hardly ever need to use it. There won't be too many ways to get into a given branch of a conditional.
So I don't think that suggestion can help. It was running for an hour, and getting the same amount of I/O done with the storage debugging messages would take a couple days logging to disk (turns 20+ Mbyte/sec request rates to kBytes/sec); and a lot longer logging to a serial console.
A serious drawback. If you like, I could send you a small patch to log a message just at the start and the end of each request. That would at least let you see whether all the requests are being handled and whether the driver is really quiescent when your system hangs.
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 ... :)
Anyway, there were no error messages from usb-storage, suggesting that nothing was going wrong there except when dealing with the higher level code. Although it's hard to know that for sure, since the success and failure messages are controlled by the same compile flag.
If usb-storage truly was just waiting for a request, after having successfully fulfilled all the previous requests, and dd was just blocked on a read, that points to a problem somewhere in the intermediate levels of the block I/O system or the SCSI system. Not much help there, since you must already be aware of that.
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.
- Dave
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
