USB 2.0 is too slow?
Quoted 1 line
Some problems I met as follows.
You didn't mention what kernel or driver version you used. I'd expect more success with the latest 2.5 code, which should appear as a patch against 2.4.21pre soon.
Quoted 1 line
(1)Sometimes it can copy completely in 30 seconds.
300 MB, 30 seconds ... 10 MB/sec, faster can be had; that shouldn't tax the usb2 hardware at all. But some PCI systems might not like that additional load.
Quoted 2 lines
Is the echi-hcd module instable or immature now? Or the VIA USB 2.0 host controller is bad support?
Some of both. It's explicitly so on 2.4 (CONFIG_EXPERIMENTAL) and has on 2.5 has recently been regaining stability. Not that long ago we switched over so usb-storage uses scatterlists to do queued I/O, stressing the driver and hardware a lot more ... the expected kinds of bugs did show up, and are being squished.
And you need relatively recent drivers for the VIA support to behave, in any case. Or even Intel; there's a timeout that Intel expects to be relatively long, and current kernels have it quite short. We learned that just this week... :)
- Dave
Quoted 3 lines
You didn't mention what kernel or driver version you used. I'd expect more success with the latest 2.5 code, which should appear as a patch against 2.4.21pre soon.
Kernel 2.5.45, 2.5.51, 2.5.52 and 2.4.20 which I've tested. Redhat 8.0, VIA VT8235 SB, Lacie USB2.0/1394 10GB HDD.
Quoted 5 lines
Quoted 1 line
(1)Sometimes it can copy completely in 20 seconds.
300 MB, 30 seconds ... 10 MB/sec, faster can be had; that shouldn't tax the usb2 hardware at all. But some PCI systems might not like that additional load.
Sometimes I got the messages below during copying some large data. (in kernel 2.5.45)
drivers/usb/core/message.c: usb_sg_cancel, unlink --> -22 drivers/usb/core/message.c: usb_sg_cancel, unlink --> -22 drivers/usb/core/message.c: driver for bus 00:08.2 dev 2 ep 2-in
corrupted data!
If the messages were shown, it spent more longer than 20 secs. Although it didn't show the same messages above in kernel 2.5.52, but it copied slowly as before.
The connection of USB2.0 devices, OS and the ehci-hcd is suspect in my test.
Quoted 7 lines
Quoted 2 lines
Is the echi-hcd module instable or immature now? Or the VIA USB 2.0 host controller is bad support?
And you need relatively recent drivers for the VIA support to behave, in any case. Or even Intel; there's a timeout that Intel expects to be relatively long, and current kernels have it quite short. We learned that just this week... :)
Intel and I seemed to get into the same situation. :)
BTW, do u have any solution for following problem.
**If two USB2.0 devices (HDD and CD-RW) are pluged into the same usb hub,
Two situations I met as follow. ( check /proc/scsi/scsi )
A. 2 devices are found and can be attached.
B. 2 devices are found but only one device can be attached.
Thanks for your response.
BR,
Joseph
-----------------------------------------------------------------
< 每天都 Yahoo!奇摩 > www.yahoo.com.tw
Quoted 9 lines
Subject: Re: USB 2.0 is too slow? From: "Joseph" <jospehchan () yahoo ! com ! tw>Quoted 3 lines
You didn't mention what kernel or driver version you used. I'd expect more success with the latest 2.5 code, which should appear as a patch against 2.4.21pre soon.
Kernel 2.5.45, 2.5.51, 2.5.52 and 2.4.20 which I've tested. Redhat 8.0, VIA VT8235 SB, Lacie USB2.0/1394 10GB HDD.
I think you'd be better off with 2.5.52bk8 or 2.4.20pre with the ehci24-1220 patch [*]. Fewer problems over all, and with that version, fewer severe ones.
Quoted 6 lines
Sometimes I got the messages below during copying some large data. (in kernel 2.5.45)
drivers/usb/core/message.c:usb_sg_cancel, unlink --> -22drivers/usb/core/message.c:usb_sg_cancel, unlink --> -22drivers/usb/core/message.c: driver for bus 00:08.2 dev 2 ep 2-in
corrupted data!
All stuff that would never have appeared before 2.5.45; storage is now stressing bulk queueing in all the hcds, using scatterlist primitives. The ohci and uhci drivers have had much more time to get stable queueing than the ehci code. That explains some of the recent updates to the ehci-hcd driver.
I think "message.c" needs a small patch. The unlink diagnostics have a FIXME next to them (there are false alarms), and I'm not entirely trusting that "corrupted" diagnostic either.
Quoted 3 lines
If the messages were shown, it spent more longer than 20 secs. Although it didn't show the same messages above in kernel 2.5.52, but it copied slowly as before.
Some kind of fault was reported, and some of the usb-storage error cleanup paths will delay "HZ*6" (6 seconds). For my tests I sometimes just make it "HZ/6" (36x shorter).
There was a recent usb-storage change (fixed in bk8) to recognize that a particular fault code doesn't indicate an error (so no recovery is needed); it likely affected some of these cases, and the "cleanups" would indeed have caused "slow" transfers.
Quoted 5 lines
BTW, do u have any solution for following problem.
**If two USB2.0 devices (HDD and CD-RW) are pluged into the same usb hub,
Two situations I met as follow. ( check/proc/scsi/scsi)
A. 2 devices are found and can be attached.
B. 2 devices are found but only one device can be attached.
You're describing a situation where /proc/bus/usb/devices shows the devices, but they don't make it all the way into /proc/scsi/scsi? Sounds familiar, as if someone else reported it too.
- Dave
[*] http://marc.theaimsgroup.com/?l=linux-usb-devel&m=104040598627391&w=2
Quoted 3 lines
I think you'd be better off with 2.5.52bk8 or 2.4.20pre with the ehci24-1220 patch [*]. Fewer problems over all, and with that version, fewer severe ones.
OK, I will try what you say. :)
Quoted 3 lines
I think "
message.c" needs a small patch. The unlink diagnostics have a FIXME next to them (there are false alarms), and I'm not entirely trusting that "corrupted" diagnostic either.
:), Will you or someone patch the "message.c" in the future?
Quoted 3 lines
You're describing a situation where
/proc/bus/usb/devicesshows the devices, but they don't make it all the way into/proc/scsi/scsi? Sounds familiar, as if someone else reported it too.
YES, is this bug going to be fixed in next release? BTW, merry christmas and happy new year! 8-)
BR,
Joseph
-----------------------------------------------------------------
< 每天都 Yahoo!奇摩 > www.yahoo.com.tw