very slow Hitachi harddisk with ahci

Hello,

One of my 2 harddisks, a Hitachi HDS72101, is very slow, the driver is ahci.

Output of “hdparm -t /dev/sda”:
/dev/sda:
Timing buffered disk reads: 8 MB in 3.20 seconds = 2.50 MB/sec

No problem with the other one, a Hitachi HDS72161, the driver is pata_ali.

Output of “hdparm -t /dev/sdb”:
/dev/sdb:
Timing buffered disk reads: 224 MB in 3.00 seconds = 74.63 MB/sec

How could I get better performance for /dev/sda ?

My system: openSUSE-11.3 on amd64

TIA for any help!
Peter

Try to check both hard disks with ‘smartctl’ (see the manpage for details) and look for any suspicious differences.

Thanks, here are the differences:

sda:
Device Model: Hitachi HDS721010CLA332
Serial Number: JP2940HQ3MP0EH
Firmware Version: JP4OA3EA
User Capacity: 1,000,204,886,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4

sdb:
Model Family: Hitachi Deskstar 7K160
Device Model: Hitachi HDS721616PLAT80
Serial Number: PV6904ZHTYJESN
Firmware Version: P22OA8BA
User Capacity: 160,041,885,696 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1


sda:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.

sdb:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.


sda:
Device State: SMART Off-line Data Collection executing in background (4)

sdb:
Device State: Active (0)

I guess, sda should be “active” too. I’ve tried the state-change options of smartctl (-s, -o, -S, -X), but the read-speed and the device state don’t change…

Any other ideas?
Peter

Have you checked the settings in the motherboard BIOS?

Some boards have an AUTO setup for UDMA / PIO modes. If this is the case the
settings are chosen when the devices are cold and can handle higher speeds.
Check out how these are set and make sure they match the capability of the HDD’s.

All settings are AUTO. And “hdparm -i” and “hdparm -I” report both that udma6 is active:
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
I suppose, that’s the best mode for the drive? In 1-2 hours, I can check other bios settings.
Then I’ll check also, what happens with openSUSE-rescue system.
Peter

Hello,
No success with other bios-settings. But there is no problem with the
openSUSE-rescue system!
sda and sdb are interchanged, so the drive in question is sdb on the rescue
system.

Here the results after playing with hdparm, smartctl and hwinfo:

command          normal system (sda)                 rescue system (sdb)
--------------------------------------------------------------------------------------
hdparm -t           2.50 MB/sec                       124.31 MB/sec

smartctl -x   Offline data collection activity    Offline data collection activity
              was suspended by an interrupting    was completed without error.
              command from host.

              Device State: SMART Off-line Data   Device State: Active
              Collection executing in background

hwinfo        Config Status: cfg=no, avail=yes,   Config Status: cfg=new, avail=yes,
              need=no, active=unknown             need=no, active=unknown

hdparm -a     readahead = 256 (on)                readahead = 1024 (on)

When I adjust the readahead to 1024 on the normal system,
then I can get 10.00 MB/sec. But that’s still far away from
the 124 MB/sec of the rescue system.

The installed system and the rescue system are both openSUSE-11.3.
I’m puzzled…

TIA for any help!
Peter

hi Peter,

It looks as though you motherboard is not upto it.

Ultra DMA Mode 6 only gives a transferrate of 133,3 MByte/s (UDMA133) which is ok for the drive that’s working.

Your 1TB disk need a transferrate of 300 MByte/s (Serial ATA/300 MB/s).

It looks as though your BIOS does not even give Ultra DMA Mode 7, transferrate of 166 MByte/s (UDMA166).

Or have I misunderstood the info given?

Peter,

I missed the implication of the AHCI selection.

Try IDE instead of AHCI. When you select IDE mode you should see the SATA drives identified.

Hello,
But why is there no such problem when booting the rescue system of the 11.3-dvd on the same hardware?

It looks as though your BIOS does not even give Ultra DMA Mode 7, transferrate of 166 MByte/s (UDMA166).

Indeed, there is no such choice in the bios, udma6 is the best it can do.

Peter

Where can I select this?
Peter

Hi Peter,

It’s selectable in the BIOS.

It depends which BIOS your machine has. On some it’s
→ BIOS SETUP UTILITY
→ Advanced screen
—> IDE Configuration
----> Set the SATA Operation Mode option to [IDE]

Not all BIOS’s are the same but,
it could also be under Integrated Peripherals,
you should have the choice AHCI, IDE, RAID,
it should be on the same page where the SATA in ENABLED.

Hello,

I’m pretty sure, that I’ve already tried all possible bios settings, but I can
try again this evening.

But again: with the same hardware and the same bios settings, there is no
problem when booting the rescue system. So I’m quite sure, that the problem is
in the OS and not in the bios.

Peter

Next step: “init=/bin/bash” Result: 124 MB/sec, good speed.

So, the problem is in the boot-sequence. I had already searched for “warn” and “error” in /var/log/boot.msg before, but this time I’ve spent more time reading this log-file. As result I’ve found this section:


<6>    8.036945] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
<7>    8.036984] HDA Intel 0000:01:00.1: setting latency timer to 64
<3>    8.644897] irq 19: nobody cared (try booting with the "irqpoll" option)
<4>    8.644908] Pid: 538, comm: udevadm Not tainted 2.6.34.7-0.5-desktop #1
<4>    8.644910] Call Trace:
<4>    8.644926]  <ffffffff81005ca9>] dump_trace+0x79/0x340
<4>    8.644933]  <ffffffff8149fa1c>] dump_stack+0x69/0x6f
<4>    8.644939]  <ffffffff810ad8fe>] __report_bad_irq+0x1e/0x90
<4>    8.644944]  <ffffffff810adb01>] note_interrupt+0x191/0x1d0
<4>    8.644949]  <ffffffff810ae8ef>] handle_fasteoi_irq+0xcf/0x100
<4>    8.644954]  <ffffffff81005ba5>] handle_irq+0x15/0x20
<4>    8.644957]  <ffffffff81005812>] do_IRQ+0x62/0xe0
<4>    8.644963]  <ffffffff814a31d3>] ret_from_intr+0x0/0xa
<4>    8.644980]  <00007fc4b4c59476>] 0x7fc4b4c59476
<3>    8.644981] handlers:
<3>    8.644984] <ffffffff81322050>] (usb_hcd_irq+0x0/0x70)
<3>    8.644992] <ffffffffa00a8710>] (ahci_interrupt+0x0/0x120 [ahci])
<0>    8.645002] Disabling IRQ #19

And indeed, the “irqpoll” solves the problem!

Lesson learned: read carefully the boot-log!

Cheers, Peter