Andre S:
Note: I had to kill the pldd-prozess because accessing the first harddisk stopped after 30-60 mins but pldd neither finished nor displayed an error.
No interesting dmesg near the kill? Or from your next shutdown?
Agreed, having reads of the disk do anything other than repeatedly succeed in roughly equal times indicates trouble somewhere.
You might like your sg_dd results better, after you learn to use bpt=, unless you're willing to patch:
--- http://members.aol.com/plscsi/tools/pldd/pldd.tar.gz --- pldd/lscsi.c ... sg_io_hdr_t * sih = ... ... int minSeconds = (28 * 60 * 60); /* 28*60*60 s = 28 h = 1.125 days */ int minMilliSeconds = (1000 * minSeconds); ... sih->timeout = minMilliSeconds; ... ---
Your surprise at creating a deathless process fits a pattern I think I see in the usb-storage & linux-scsi archives. I gather the Linux social convention is for short timeouts, like the thirty seconds per CBW that the USB DWG has lately been pushing. Here now I wonder, for example, did a timeout in the past provoke the ASC = x4B "data phase error" later?
In my own history of pain, more with device firmware than kernel software, I find that rapid timeouts destroy evidence and inject chaos and betray a prejudice against robots slowly moving disks into place. Me, I like the 28 hours default because if I launch an experiment odds are good I'll revisit it personally within that time. Sounds like I should conform by making the 30 seconds the default and try to remember to ask for 28 hours when I need it.
Pat LaVarre
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
