LinuxQuestions.org - USB2.0 Ext. Disk: Kernel should use two different modules for read and write?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - USB2.0 Ext. Disk: Kernel should use two different modules for read and write? (https://www.linuxquestions.org/questions/slackware-14/usb2-0-ext-disk-kernel-should-use-two-different-modules-for-read-and-write-673248/)

USB2.0 Ext. Disk: Kernel should use two different modules for read and write?

I have a 2002 P4 machine with on board USB1 and have added a USB2.0 pci card.

Like others, I have had considerable problems with my external disks and I have come to a working solution. I have two kernels - one with EHCI_HCD and one without. Later I will try and use one kernel with EHCI_HCD as a loadable and removable module.

Here's why I use two kernels:

With EHCI_HCD:

Writing to the external disk is fast - especially with large files.

Reading files is not good, eg when watching a film, it will pause every couple of minutes making it an unpleasant experience.

When copying, the source directory is difficult to navigate (with ls or mc).

Without EHCI_HCD:

Writing to the external disk is painfully slow - 40+mins to copy a dvd.

Reading is excellent - one can watch a film without pauses.

If one did decide to copy a file, one can continue to navigate the source directory as normal.

Do these observations point to a basic bug in the kernel and that the kernel itself should use the EHCI_HCD module when writing, but not when reading?

I would be grateful if the kernel experts would comment on my observations and conclusions - and perhaps express them in a more technically correct way since I am considering submitting this as a bug to the kernel developers.

Interesting... Can you post the part of your kernel configs for the USB options?

This is, I hope, the relevant extract from the kernel configuration file WITHOUT EHCI_HCD. Sorry if I have included too much.

Code:





#

# Miscellaneous USB options

#

CONFIG_USB_DEVICEFS=y

CONFIG_USB_DEVICE_CLASS=y

# CONFIG_USB_DYNAMIC_MINORS is not set

# CONFIG_USB_SUSPEND is not set

# CONFIG_USB_PERSIST is not set

# CONFIG_USB_OTG is not set



#

# USB Host Controller Drivers

#

# CONFIG_USB_EHCI_HCD is not set

CONFIG_USB_ISP116X_HCD=y

CONFIG_USB_OHCI_HCD=y

# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set

# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set

CONFIG_USB_OHCI_LITTLE_ENDIAN=y

CONFIG_USB_UHCI_HCD=y

CONFIG_USB_U132_HCD=m

CONFIG_USB_SL811_HCD=y

CONFIG_USB_SL811_CS=m

CONFIG_USB_R8A66597_HCD=m



#

# USB Device Class drivers

#

CONFIG_USB_ACM=m

CONFIG_USB_PRINTER=m



#

# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'

#



#

# may also be needed; see USB_STORAGE Help for more information

#

CONFIG_USB_STORAGE=y

# CONFIG_USB_STORAGE_DEBUG is not set

CONFIG_USB_STORAGE_DATAFAB=y

CONFIG_USB_STORAGE_FREECOM=y

CONFIG_USB_STORAGE_ISD200=y

CONFIG_USB_STORAGE_DPCM=y

CONFIG_USB_STORAGE_USBAT=y

CONFIG_USB_STORAGE_SDDR09=y

CONFIG_USB_STORAGE_SDDR55=y

CONFIG_USB_STORAGE_JUMPSHOT=y

CONFIG_USB_STORAGE_ALAUDA=y

CONFIG_USB_STORAGE_KARMA=y

# CONFIG_USB_LIBUSUAL is not set

The other kernel is the standard /boot/vmlinuz-huge-smp-2.6.24.5-smp from the distribution 12.1.

I believe IIRC, that there are two modules in use for USB (possibly 3 if it is based of the intel UHCI) There is EHCI and OHCI, one is for USB 2.0 and the other is for 1.0. Between the two there is a huge difference in speed.

The two main drivers are: USB_OHCI_HCD & USB_UHCI_HCD. The USB_EHCI_HCD is a high-speed driver.
I am not sure that the problem the OP is having is a bug, but it does sound like one. The kernel 2.6 USB sub-system is undergoing contant change, so it would be no surprise if ther is some inconsistency. It may just be that the read and write code for the EHCI_HCD driver are not at the same level of development.

I can't say with any authority what is going on there. But, I have a couple of suggestions. First, try using a different version of the kernel, using the sa,e setup and config options, to see if the same thing is happening under other kernel versions. I'd suggest trying both a newer and an older kernel and not using 'rc' versions. For instance, try the 2.6.25.5 and 2.6.23.9. There have been *huge* changes in the kernel since 2.6.24 -each micro-version number patch since then has contained over 100,000 lines.

So, if the all the kernel versions exhibit the same behaviour you can probably assume that this is a 'feature' and not a bug -that someone still hasn't figured out how to get both 'sides' of the driver working equally well. If that is the case, a down-n-dirty solution would be to compile all the drivers as modules and then load the module with the best performance for the operation you want to do.
The EHCI driver overrides the UHCI and OHCI drivers when present, so having everything as a module is the only way to get full control of what is going on. The EHCI driver will try to use the faster USB protocol when possible. But when it is not, it 'emulates' either the UHCI or OHCI driver, whichever is appropriate.

I've just done a quick search with 'clusty.com' for 'EHCI write slow' and found several pages which seem to describe the same problem, along with some possible fixes you might try:

1. Add 'pci=routeirq' to your kernel boot options
2. echo 1024 > /sys/block/sd*/device/max_sectors
3. explicitly set your mount option to async in /etc/fstab
4. Use hdparm/sdparm to change the cach-mode for the drive from "write through" to "write back"

A quote from the kernel-devs mailing list:
> When I use flash drive in sync mode, it writes on it only 64kB/s. When I
> umount it and mount it in not sync mode but do sync manually after it writes
> into memory, kernel writes on flash drive 11 MB/s!!! What is wrong in my
> configuration?
That's expected with sync vfat mount. Use other filesystem or async.

OP, you don't mention what filesystem you are using...

From linux-usb users mailing list:
> I tried suggestions from the FAQ, like switching off "assign IRQ for USB",
> booting with acpi=off, noapic, pci=noacpi, pci=biosirq, in lots of
> different combinations - did not change anything.

This thread on the linux-usb mailing lists seems to come closer to diagnosing the problem(maybe). As I mentioned, the 2.6 USB code undergoes lots of changes, so don't be surprised if this problem was fixed once and then turned up again.
http://sourceforge.net/mailarchive/f...ewmonth=200704

Hope this helps you.