Hi,
I've rebuilt the latest kernel 2.5.52 and test the USB 2.0 funciton with
my
LaCie USB2.0/1394-Disk Drive 10GB and a Plextor PX-W2410TU USB2.0 CD-RW.
It spneds about 8 minutes to copying a 300MB file. (10 times test)
Do I miss some modules?
Some problems I met as follows.
(1)Sometimes it can copy completely in 30 seconds.
Is the echi-hcd module instable or immature now?
Or the VIA USB 2.0 host controller is bad support?
(2) 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.
(3) What is this file, /proc/scsi/device_info, for?
My configuration, KT333+VT8235+ IBM ATA66 10GB HDD.
Thanks in advance.
Best Regards.
Joseph
-----------------------------------------------------------------
< ?C?ѳ? Yahoo!?_?? > http://www.yahoo.com.tw
> 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.
> (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.
> 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
> 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.
> > (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.
> > 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
-----------------------------------------------------------------
< ?C?ѳ? Yahoo!?_?? > http://www.yahoo.com.tw
> Subject: Re: USB 2.0 is too slow?
> From: "Joseph" <jospehchan () yahoo ! com ! tw>
>
>> 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.
> 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!
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.
> 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.
> 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
> 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. :)
> 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?
> 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.
YES, is this bug going to be fixed in next release?
BTW, merry christmas and happy new year! 8-)
BR,
Joseph
-----------------------------------------------------------------
< ?C?ѳ? Yahoo!?_?? > http://www.yahoo.com.tw