I can't get "hdparm -S" to work at all.

Using  "hdparm -S 1" should set the timeout to
5 seconds,  but the drives stay active/idle all the
time. When I set to standby manually, the drives
stay on standby for days, and start up fine when
they are used. I know this because I logged status
every 30 minutes using crontab.

They just don't standby automatically.

I'm using 5 identical drives (see below for drive
info), with software RAID.

Any suggestions? System details follow.


# uname -a
Linux narf 2.6.22-gentoo-r5 #1 Sat Sep 1 13:35:06 CDT 2007 i686
Intel(R) Celeron(R) D CPU 420 @ 1.60GHz GenuineIntel GNU/Linux

# hdparm -S 1 /dev/sda
 setting standby to 1 (5 seconds)

# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       WDC WD5000ABYS-01TNA0
        Serial Number:      WD-WCAPW2171884
        Firmware Revision:  12.01C01
Standards:
        Supported: 7 6 5 4
        Likely used: 7
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors:  976773168
        device size with M = 1024*1024:      476940 MBytes
        device size with M = 1000*1000:      500107 MBytes (500 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, with device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Recommended acoustic management value: 128, current value: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    ...
[ message continues ]

I don't have Raptors here anymore to try it with,
but "hdparm -S1 /dev/sd?" did work fine with them
when last tried.

What do you get when you try this:

hdparm -S1 -C /dev/sda;sleep 6; hdparm -C /dev/sda


??
-

[ message continues ]

Thanks for taking an interest.

I ran the commands and  got the result shown
below. Anything else you want me to try?


# hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda

/dev/sda:
 setting standby to 1 (5 seconds)
 drive state is:  active/idle

/dev/sda:
 drive state is:  active/idle


Should I give sdparm a shot?
-

[ message continues ]

That's interesting.

So, either something is regularly accessing/polling the drive,
or it just doesn't work with the standby timer.

Are there any interesting kernel messages being generated
during execution of those commands?

-ml
-

[ message continues ]

No messages to /var/log/messages as a result of those
commands; I ran several times and did a sync too, just
in case.

I very much doubt that something is regularly accessing
the drives because I have a script that runs every 1/2 hour
to check and log status. The drives stay "standby" for
hours (even days) at a time unless I specifically access
something on the RAID array. Then, they stay "active/idle"
until I manually set them to "standby".

Anything else you'd like me to try?
-

[ message continues ]

Yes:  a stock kernel, please.  Preferably 2.6.23.

Thanks.

-

[ message continues ]

Some things to check:

* Run "hdparm -I" on your drive. In the "Capabilities" section there is 
a line "Standby timer values", for some drives this mentions a device 
specific minimum. I know some drives that ignore any setting below 60 
seconds.

* I also know of quite a number of drives where hdparm -B settings 
override the -S settings, even if you set the -S settings after the 
hdparm -B settings. You could try combinations with various values of 
hdparm -B, especially 1 and 255.

Cheers,
Bart
-

[ message continues ]

Thanks for the suggestions.

The -I command prints out a bunch of stuff including:
Standby timer values: spec'd by Standard, with device specific minimum

I tried setting -B to 1 and and then set -S to 5 minutes.
Also, -B 255 and then set -S to 5 minutes.
No luck with either. These drives want to keep running.

One thing of possible interest: The -B command printed
the following message:

/dev/sda:
 setting Advanced Power Management level to 0x01 (1)
 HDIO_DRIVE_CMD failed: Input/output error

I would guess that the first line came out just before
hdparm tried to do the set, and the second line indicates
that the set failed.

Perhaps -S is failing too, just without the diagnostic?

All of the above using 2.6.22-gentoo-r5
I have not yet tried 2.6.23 as suggested by Mark Lord.

---

"And he puzzled three hours, `till his puzzler was sore."
from "How the Grinch Stole Christmas"
-

[ message continues ]

Ahhh. Spec'd by standard means that each -S unit is worth 5 seconds (for 
values up to 240 = 20 minutes), and the second part means that there is 
a minimum (which is not specified in this report, unfortunately). 
Perhaps you can get a hold of the full drive manual, the exact minimum 


Yes, that seems correct. Nothing too weird there: it simply seems that 
the drive doesn't support the power management knob. (AFAIK you should 
be able to confirm this using the feature sets listed in the output of 

Perhaps, but I'd expect it to print a diagnostic if it fails. I do seem 
to remember that (at least for some drives that I've seen) there isn't a 
diagnostic if you go below the device specific minimum, the value is 
simply ignored.

Cheers,
Bart
-

[ message continues ]

Yes. And hdparm is kind enough to print:

/dev/sda:
 setting standby to 60 (5 minutes)

Here's a bizarre sequence which I just noticed:
/dev/sda:  drive state is:  standby
/dev/sdb:  drive state is:  standby
/dev/sdc:  drive state is:  standby
/dev/sdd:  drive state is:  standby
/dev/sda: drive state is:  active/idle
/dev/sdb: drive state is:  active/idle
/dev/sdc: drive state is:  standby
/dev/sdd: drive state is:  standby
/dev/sde: drive state is:  standby

Note that the -S 60 on /dev/sda affected
/dev/sdb too! This is repeatable.

I have these drives as RAID5 (software RAID).
I don't know if that has anything to do with the
failure of -S or not. Don't know if hdparm bypasses
the RAID or not.
-

[ message continues ]

1. How are you forcing the drives into standby?

2. Have you reproduced this with a stock kernel.org kernel yet?

One possibility is that these drives may be the kind that
generate a "spurious" interrupt when they spin-down via the timer,
and perhaps libata is "processing" that interrupt and sending
additional command(s) that then wake the drive up again immediately.

To rule this out, you could try using drivers/ide for a moment or two,
and see if the same problem persists with those drives.

You could also try dumping /proc/interrupts in conjunction with "hdparm -S1",
and we can compare that with a "known good" system.

Something like this:

hdparm -B255 /dev/sda
hdparm -S1 /dev/sda
cat /proc/interrupts
sleep 6
cat /proc/interrupts

Cheers
-

[ message continues ]

Here's the log for the second suggestion:



narf ~ # hdparm -B255 /dev/sda

/dev/sda:
 setting Advanced Power Management level to disabled
 HDIO_DRIVE_CMD failed: Input/output error

narf ~ # hdparm -S1 /dev/sda

/dev/sda:
 setting standby to 1 (5 seconds)
narf ~ # cat /proc/interrupts
           CPU0
  0:       2268   IO-APIC-edge      timer
  1:          2   IO-APIC-edge      i8042
  8:          5   IO-APIC-edge      rtc
  9:          0   IO-APIC-fasteoi   acpi
 12:          4   IO-APIC-edge      i8042
 14:     206827   IO-APIC-edge      ide0
 16:     350813   IO-APIC-fasteoi   sata_promise, uhci_hcd:usb5
 17:   39596029   IO-APIC-fasteoi   eth0
 18:          0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:     728947   IO-APIC-fasteoi   libata, uhci_hcd:usb3
 20:          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
NMI:          0
LOC:    2736793
ERR:          0
MIS:          0
narf ~ # sleep 6
narf ~ # cat /proc/interrupts
           CPU0
  0:       2268   IO-APIC-edge      timer
  1:          2   IO-APIC-edge      i8042
  8:          5   IO-APIC-edge      rtc
  9:          0   IO-APIC-fasteoi   acpi
 12:          4   IO-APIC-edge      i8042
 14:     206828   IO-APIC-edge      ide0
 16:     350813   IO-APIC-fasteoi   sata_promise, uhci_hcd:usb5
 17:   39596069   IO-APIC-fasteoi   eth0
 18:          0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:     728947   IO-APIC-fasteoi   libata, uhci_hcd:usb3
 20:          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
NMI:          0
LOC:    2736881
ERR:          0
MIS:          0
-

[ message continues ]