# kernel 2.6.12 slows down usb drive [almost solved]

## vandorp

Hi,

I noticed a preformance problem with my USB drive and kernel 2.6.12-r6 (gentoo-sources-2.6.12-r6). Reading from the drive goes really fast in all cases (about 19 MB/s), but writing to the drive is very slow and varies between kernels.

I did the following measurements:

```

cd /media

mount USBdrive/

time cp ~/installs/deerpark-alpha1.installer.tar.gz USBdrive/ ; time umount USBdrive/
```

(The deerpark installer is 8.3 MB)

My 2.6.12 kernel gives the following result:

 *Quote:*   

> 
> 
> copy: 2min, 10 seconds. 
> 
> unmount: 0.01 seconds.
> ...

 

This is incredibly slow: 63kB/s!

I remember this used to be faster, so I reverted to 2.6.10 (gentoo-sources-2.6.10-r6) because this one was still in portage.

I compiled it using the .config from my 2.6.12 kernel and make oldconfig, and I got the following:

 *Quote:*   

> 
> 
> copy: 18 seconds. 
> 
> unmount: 0.2 seconds.
> ...

 

Much faster, but still only 461 kB/s. (the manual of the USBdrive says 14 MB/s write, 20MB/s read. In windows 2000 I get roughly this performance).

I threw in Knoppix 3.9, which runs a 2.6.11 kernel.

 *Quote:*   

> 
> 
> copy: 0.57 seconds. 
> 
> unmount: 28 seconds.
> ...

 

Rather strange result, but I included it anyway.

I checked the top window during the operations, and it shows the same every time. The system goes to a load of about 1, and the Cpu(s) line looks something like this:

 *Quote:*   

> Cpu(s):  0.3% us,  0.3% sy,  0.0% ni, 0.0% id,  99.6% wa,  0.0% hi,  0.0% si
> 
> 

 

I have the following system:

Mainboard: Asus a7n8x

USBdrive: Apacer Handysteno HT203 (512 MB).

udev-0.56

hal-0.4.7-r2

Any ideas on this? I can post logfiles or run additional tests if anyone has a good idea...Last edited by vandorp on Wed Jul 27, 2005 5:46 pm; edited 1 time in total

----------

## vandorp

Okay, first, I upgraded to udev-058 but this didn't make any difference. 

Next, I donwloaded some vanilla kernels from kernel.org and compiled them. Here are the benchmarks:

 *Quote:*   

> 
> 
> kernel 2.6.12.1
> 
> copy: 1 minute, 53.3 seconds
> ...

 

 *Quote:*   

> 
> 
> kernel 2.6.11.12
> 
> copy: 1.58 seconds
> ...

 

Now that's more like it! This seems to pin down the problem quite well... What should I do next? File a bug report or something? Is there anybody who can reproduce these results?

In the meanwhile, I would like to use a 2.6.11 kernel. Unfortunately, the 2.6.11 kernel series is not in portage anymore (and deleted from my harddisk), and the vanilla kernels don't have vesafb-tng (gentoo-patch obviously)... Should I patch a vanilla kernel by hand? How do I do that?

I would really like to try a gentoo-sources 2.6.11 (also because I'm curious to how it performs), but where do I get it?

EDIT: patched the kernel by hand using the patches from http://dev.gentoo.org/~spock/projects/vesafb-tng/ -> working fine now

----------

## Sławomir Gąsiorowski

Hello !

I have the same problem with performance and stability of USB stick after upgrate to gentoo-sources-2.6.12-r4. Transfer rate during writing (in USB 1, without ehci_hcd module) was similar to yours. In USB2.0 mode computer freezes (without any information of error) during reading or writing (led on USB stick is still on).

I had to back to gentoo-sources-2.6.11-r11. Now I see that unfortunally there is no gentoo-sources-2.6.11 in portage, and I think it was a stupid thing to remove it...

My lspci output:

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge

0000:00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)

0000:00:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)

0000:00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)

0000:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)

0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)

0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)

0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)

0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)

0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800 South]

0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)

0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7 :Cool: 

0000:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)

----------

## augury

sandisk 256mb 

apacer 1gig

2.6.13-rc3-mm1 

601:20:46 wren / # hdparm -tT /dev/sdc1 

/dev/sdc1:

 Timing cached reads:   2468 MB in  2.00 seconds = 1233.92 MB/sec

 Timing buffered disk reads:   26 MB in  3.09 seconds =   8.41 MB/sec

601:21:16 wren / # hdparm -tT /dev/sdd1 

/dev/sdd1:

 Timing cached reads:   2516 MB in  2.00 seconds = 1257.92 MB/sec

 Timing buffered disk reads:   58 MB in  3.08 seconds =  18.85 MB/sec

The cpu spike thing is normal.  Try taking out uhci-hcd from kernel.  Make sure you dont use the low preformance usb storage driver (well what can you do).

----------

## augury

I put these in raid0 once and all i got was  8 MB/sec.  usb is for girls.

----------

## vandorp

Hi,

 *S³awomir G±siorowski wrote:*   

> 
> 
> In USB2.0 mode computer freezes (without any information of error) during reading or writing (led on USB stick is still on).
> 
> I had to back to gentoo-sources-2.6.11-r11. Now I see that unfortunally there is no gentoo-sources-2.6.11 in portage, and I think it was a stupid thing to remove it...
> ...

 

Strange, my computer had no problems reading from the sticks, but writing was slow (no freezes however). 

About the kernel version: I had exactly the same problem  :Smile:  I downloaded a vanilla kernel from www.kernel.org, just like this:

```

cd /usr/src/

rm linux

wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.12.tar.bz2

bunzip2 linux-2.6.11.12.tar.bz2

tar -xf linux-2.6.11.12.tar

ln -s linux-2.6.11.12 linux

```

Then I got the vesafb-tng patches (I don't know if you use them, but this is what I did), like this:

```

cd /usr/src

wget http://dev.gentoo.org/~spock/projects/vesafb-tng/archive/vesafb-tng-0.9-rc6-2.6.11-rc1.patch

cd linux

patch -p1 < ../vesafb-tng-0.9-rc6-2.6.11-rc1.patch

```

After this I copied my most recent .config to /usr/src/linux, did make oldconfig and compiled and installed as usual. System runs fine now. I can now write with about 5 MB/s to the USB stick. This is still below spec, but I can live with it.

Thanks for the lspci. We have quite different chipsets, but the problem seems the same. I also tried a friend's USB stick/mp3 player (forgot the brand, sorry) and it was also slow. There must be more people with the same problem... Here is my lspci:

0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1)

0000:00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)

0000:00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)

0000:00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)

0000:00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)

0000:00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)

0000:00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)

0000:00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)

0000:00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)

0000:00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)

0000:00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)

0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)

0000:00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)

0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)

0000:01:09.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)

0000:01:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 7 :Cool: 

0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)

0000:02:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1)Last edited by vandorp on Fri Jul 29, 2005 5:48 pm; edited 1 time in total

----------

## Naib

There is a change to how the VFAT driver works.

I had this problem with the LOVE sources

have a read of this, just a couple of things that need to be changed

https://forums.gentoo.org/viewtopic-p-2610474.html#2610474

----------

## vandorp

 *Naib wrote:*   

> There is a change to how the VFAT driver works.
> 
> I had this problem with the LOVE sources
> 
> have a read of this, just a couple of things that need to be changed
> ...

 

I did that and it works. Thank you. 

I know nothing of kernel development, but this seems rather strange to me. If it's really true that this can damage your usb drive, then I think that a lot of these things are gonna get fried. I'm also very glad I didn't destroy my friend's stick/mp3 player. I think it's quite expensive and he got it as a gift from his girlfriend. She would have killed us both  :Shocked: 

I'm still using 2.6.11 by the way. I don't like this non-sync behaviour where everything goes fast but it takes forever to unmount the stick.

----------

## widan

 *vandorp wrote:*   

> I know nothing of kernel development, but this seems rather strange to me. If it's really true that this can damage your usb drive, then I think that a lot of these things are gonna get fried. I'm also very glad I didn't destroy my friend's stick/mp3 player. I think it's quite expensive and he got it as a gift from his girlfriend. She would have killed us both 

 

Mounting filesystems sync does increase the number of individual writes to the device (rather than allowing the kernel to combine some of them, and on vfat combining will help a lot since many changes are only for updating the FAT and root directory, which are small structures).

However it should not kill flash chips. It is true that repeatedly writing to the same hardware block of a flash chip will kill that block relatively quickly (the flash chips are usually designed so that each block can stand at least 100000 writes, so it won't die instantly either). But the controller chip in the flash drive will do wear-levelling, and even if you write 100000 times to sector 0 of the block device, it won't write 100000 times to any given block of the flash, but rather spread the writes over all the free blocks.

----------

