Alan Stern wrote: > On Fri, 26 Mar 2004, Brian S. Stephan wrote: > >> Hello, >> >> On my desktop (UHCI USB controller, VIA chipset) I get terrible transfer >> speeaberrationspecific device (USB 1.x). The device, a Neuros with 128 MB >> flash storage, works fine on my laptop (OHCI USB, NEC controller) on a >> 2.6 kernel. It also works fine on the desktop when I boot off of a >> 2.4.21-based Gentoo livecd. >> >> The 2.6 slowness has been on a number of kernels, I noticed it when I >> first got the device around 2.6.3-rc?, and has sustained through various >> vanilla and mm kernels up to 2.6.5-rc2-mm3. >> >> To sum up what I'm working with: >> Compaq laptop, OHCI, hotplug + udev, 2.6 device is fine >> AMD+VIA-based desktop, UHCI, hotplug + udev, 2.6 device is very slow >> AMD+VIA-based desktop, UHCI, hotplug + devfs, 2.4 livecd device is fine > > Are you copying the same file to the device in your desktop tests with 2.6 > and 2.4?
Sorry, yes, I am. Same file from the same disk. cp takes maybe a second (could be CDROM spinup) and then umount takes 3-5 sec. >> During the transfer USB debug tells me there are a bunch of bus resets >> and command aborts, as > > Those messages appear because your device fails to transfer its status to > the computer. The computer has to reset the device, and that can be a > very time-consuming operation, especially when it fails (which it did, > several times). > >> 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. >> On the laptop, cp takes a bit (couple seconds) with umount taking at >> _most_ two minutes... so I would say it's working right. And that was on >> a file many orders larger than the original. > > What happens if you try to transfer the same file? Just tested now. cp finishes "immediately" and the umount takes, again, about 3-5 sec. >> I have read that some VIA chipsets may be a bit buggy, but aside from >> this device I haven't had any problems, and the fact it seemingly works >> in 2.4 leads me to believe that it isn't (entirely, at least) the fault >> of the hardware. > > This doesn't look like a VIA problem. > > At least one person has reported a problem in which his device would fail > whenever he tried to write a file containing 0xffff in the last two bytes > of one sector and 0xffff in the first two bytes of the next sector! Your > problem might be similar to that -- data dependent. Or it might be a > timing issue; 2.6 does usb-storage data transfers more quickly than 2.4. 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. 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. 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. Brian ------------------------------------------------------- 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
