# Extremly slow HDD after 2.6.19

## Oak

Hi!

I installed and configured vanilla-sources-2.6.19 a couple of days ago and since then, my hdd has been slow as hell.

I copied my .config from my old 2.6.18 and checked every option in the new kernel. I have also tried every known option in hdparm without any improvement. My computer is a laptop (P-M Centrino 1,7 GHz, 1 GB ram, 100 GB ATA HDD), and I've never had any problems with the disks before.

My root partition has ReiserFS 3.6 and the other partition is on Ext3. There is no visible speed difference between the two partitions. Do anyone know what might be going on with this?

----------

## frostschutz

make oldconfig?

You can easily exclude filesystems from the possible causes by benchmarking the HDDs directly (for example using hdparm -Tt /dev/hda). If this is too slow, you most likely have some problem with DMA. Check wether it is enabled or not and what the Kernel (dmesg) says about your IDE / SATA / Whatever Controller and hard drives.

----------

## Oak

The output from hdparm looked just fine and DMA is enabled, but I discovered that it's probably not kernel related,

since the results are identical even on 2.6.18. What I discovered what that my root partition (ReiserFS) isn't slow at all.

I've tried md5sum and cksfv on some 50MB files, and according to the results my reiserfs partition executes it 6 times faster.

I did an e2fsck on it, without any difference. I found this in dmesg:

```

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

```

This looks strange?

[Edit]

My dmesg reports:

```

hda: 195371568 sectors (100030 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100)

```

Shouldn't UDMA/100 run at 100 MHz? In that case, maybe this is the slow-down?

[/Edit]

----------

## frostschutz

 *Oak wrote:*   

> 
> 
> ```
> 
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ...

 

Maybe, but PIO mode is not DMA, and I get the same message and HDD performance on my system is fine.

----------

## Oak

Alright, then I have to keep investigating...

Thanks for the answer!

----------

## [myrddin]

Hi,

in 2.6.19 the SATA config moved. I think that your system uses an minimal driver for your sata chipset. Try enabling the right driver in Device Drivers-->Serial ATA (prod) and Parallel ATA (experimental) drivers

----------

## Oak

That would be the answer if I had a SATA interface. Unfortunately, I don't.

Thanks for the answer anyway.

 :Smile: 

----------

## Mickael

Hi, 

I don't know if this is a problem of sata/pata, but with the 2.6.19, there is a big change with SATA/PATA drivers. So take a look here :

Linux 2 6 19.

Maybe the kernelnewbies home page would help you... i'hope.

----------

## Gentree

Finally seems that something has been done to replace the chronically slow vfat sync option that spent most of it's time hammering the FAT sector (capable of burning up the writable lifetime of some devices)

Thanks to Chris Mason for that.

There's been a lot of deep changes in 2.6.19, looks like this is one kernel upgrade that needs a bit more reading before diving in.

Thanks for the link.  :Cool: 

----------

## NeddySeagoon

Oak,

What does 

```
hdparm /dev/hd...
```

 show for the device ?

----------

## Oak

I've tried changing between the old ATA drivers and the new PATA in the kernel without any difference. I've also tried fiddling around with hdparm, as said before.

This is my output of hdparm

```

vasquez dv01dem # hdparm /dev/hda

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 65535/16/63, sectors = 195371568, start = 0

```

The only reason for changing from 2.6.18 to 2.6.19 is the support for my internal card reader.

----------

## Gentree

```
bash-3.2#hdparm /dev/hd

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  1 (32-

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  0 (off

 readonly     =  0 (off

 readahead    = 256 (on

 geometry     = 16383/2

```

you may want to look at why you are set to 16 bit IO.

 :Cool: 

----------

## NeddySeagoon

Gentree,

Since there is only a 16 bit path down the IDE cable, 16 bit or 32 bit data transfers make very little difference.

32 bit I/O helps free up memory cycles though

----------

## Oak

Changing from 16-bit to 32-bit didn't do anything.

----------

