On Sat, 27 Mar 2004, Brian S. Stephan wrote: > >> after a while (USB debug or not) I also get the following SCSI noise: > >> > >> SCSI error : <1 0 0 0> return code = 0x6000000 > >> end_request: I/O error, dev sdb, sector 1952 > >> Buffer I/O error on device sdb1, logical block 1920 > >> lost page write due to I/O error on sdb1 > > > > Those messages appear because the various error recovery strategies have > > all failed to work, and SCSI has given up on trying to transfer some of > > the information. > > That's what I figured. Here's something I forgot to mention, the > sector/logical block numbers go up incrementally for a while, but then > either transfers become "good" again or it's just skipping around (which > could be normal, right?) until errors show up at a new location where they > increment again for a while, repeat.
That's because when the errors start to occur, the SCSI layer retries the transfers incrementally and those retries tend to fail also. Each time another sector doesn't get written properly you see it in the log. When things are working properly you don't see any error messages. > I thought a simple 2.4 vs. 2.6 thing at first too, but was thrown off by it > working correctly on the 2.6 laptop (with a different host controller). And > it doesn't look like it's data dependent... this slowness is very > independent. I once tried to transfer an audio CD's worth of ripped .ogg > files and the umount was going 48 hours strong before I gave up. That's kind of ridiculous. Clearly there's no point in trying to transfer a large amount of data when you have to pause a couple of minutes for error recovery every few megabytes. > While writing I thought to try some ASCII files but it doesn't seem to be > that either. mount && cp some-small-files && umount went at an acceptable > speed, but mount && cp a 164,963 b file && umount took way too long. Over > 15 minutes. The smaller files were 8 files all at about 15 kb, which > combines them to about 3/4 the size of the one larger file. Very puzzling > to me. It's not a matter of time or size, it's a matter of "Is the device working?" When it doesn't work properly, you shouldn't try to use it. Even if it seems to work (albeit very slowly), you're probably losing data. > The 164,963b file had spaces in it so I cp'd it locally to 'chrono.t' and > tried another mount && cp chrono.t && umount, and the umount went a lot > faster. Useful to know or an abberation? The original test file had no > spaces and still takes a long time. So writing the same data, just from a different location on your hard disk, worked okay? I have no idea why that should be. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
