[plug] hdparm troubles

[Steve Boak]

On Sat, 17 Jul 2004 03:28 pm, Craig Ringer wrote:
[...]
> Have you tried flipping unmasked interrupts (-u) on? 
it is on by default: (and makes no difference if I turn it off)
min:~# hdparm /dev/hda
/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 23937/16/63, sectors = 156250000, start = 0

> I'd also try 
> enabling DMA without trying to set the speed (let the disk/interface
> decide it) by omitting the -X68. 
min:~# hdparm -c1 -m16 -d1 /dev/hda
/dev/hda:
 setting 32-bit IO_support flag to 1
 setting multcount to 16
 setting using_dma to 1 (on)
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 using_dma    =  1 (on)
min:~# hdparm -Tt /dev/hda
/dev/hda:
 Timing buffer-cache reads:   192 MB in  2.00 seconds =  96.00 MB/sec
 Timing buffered disk reads:   12 MB in  3.17 seconds =   3.79 MB/sec

> I'd also try 16 bit mode .. just in case there's some stupid driver or
> controller bug.  
min:~# hdparm -c0 -m16 -d1 /dev/hda
/dev/hda:
 setting 32-bit IO_support flag to 0
 setting multcount to 16
 setting using_dma to 1 (on)
 multcount    = 16 (on)
 IO_support   =  0 (default 16-bit)
 using_dma    =  1 (on)
min:~# hdparm -Tt /dev/hda
/dev/hda:
 Timing buffer-cache reads:   176 MB in  2.02 seconds =  87.13 MB/sec
 Timing buffered disk reads:   12 MB in  3.36 seconds =   3.57 MB/sec

> On the same line of 
> thinking, I'd also run some tests with multicount disabled.
Also makes no difference.

>
> When you're doing the testing, what sort of CPU load do you see?
>
Cache test 100% cpu usage, disk reads about 10-20%

> Have you tried a recent kernel? Perhaps the via IDE drivers have
> improved for these boards. IIRC they're known to be a little eccentric
> and have had Linux support issues in the past.

OK, how hard can it be to move up to 2.6 :-)

> Do the boards have an IO-APIC? If yes, try booting with 'noapic' in case
> it's braindead. 
Don't know, but tried it anyway - no difference :-(

> Check /proc/interrupts to see if your IDE controller is 
> being forced to share interrupts with anything. 
min:~# cat /proc/interrupts
           CPU0
  0:     208512          XT-PIC  timer
  1:       9269          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:       1513          XT-PIC  VIA686A
  9:       5229          XT-PIC  usb-uhci, usb-uhci
 10:          0          XT-PIC  eth1
 11:        388          XT-PIC  eth0
 12:      29373          XT-PIC  PS/2 Mouse
 14:      62866          XT-PIC  ide0
NMI:          0
LOC:          0
ERR:          0

Does XT-PIC mean anything significant?

min:~# cat /proc/dma
 4: cascade

How about cascaded dma? Is this important?

> Do you have anything 
> else in the system that might be generating heavy interrupt loads (TV
> input cards, for example)?
Nope - only room for one extra RTL PCI NIC card. 
From top: Cpu(s):   3.2% user,   3.2% system,   0.0% nice,  93.6% idle

>
> > min:~# hdparm -Tt /dev/hda
> > /dev/hda:
> >  Timing buffer-cache reads:   192 MB in  2.03 seconds =  94.58 MB/sec
> >  Timing buffered disk reads:   12 MB in  3.20 seconds =   3.75 MB/sec
> >
> > 3.75 MB/sec ???
>
> Wow.
>
> --
> Craig Ringer

Thanks everyone.

I have found a couple of mentions of similar, though not exactly the same, 
problems through google - but unfortunately no answers yet.

I'll leave the settings with dma off and put up with ~6MB/sec for the moment 
until I decide if I should upgrade the kernel. At least it's twice as fast as 
it was before. Thank goodness I don't have to trawl terrabytes of data that 
some of you guys mention in passing as though it was an everyday 
occurrence :-)

Steve

-- 
VOIP-Phone - Free World Dialup number 454566 - Via 128k ISDN 

"Most men occasionally stumble over the truth, but most pick themselves
up and continue on as if nothing had happened." - Winston Churchill