hard disk parks regularly after resume - hdparm -B 254 has no effect

With the computer in 'hard disk parking' mode as described above, I just tried a suspend/resume cycle with power plugged in throughout, and the hard disk is no longer parking. So perhaps the computer gets stuck somehow thinking it is running off batteries and keeps issuing 'hdparm -B 128' commands.

When doing the following:

1. Suspend.
2. Remove power.
3. Resume.
4. Reattach power.

these hdparm commands get issued:

hdparm -i /dev/sda
hdparm -B 128 /dev/sda
hdparm -B 1 /dev/sda
hdparm -S 12 /dev/sda
hdparm -i /dev/sda
hdparm -B 254 /dev/sda
hdparm -i /dev/sda
hdparm -B 254 /dev/sda

When doing:

1. Suspend (with power in).
2. Resume.

these commands get issued:

hdparm -B 254 /dev/sda
hdparm -S 244 /dev/sda
hdparm -i /dev/sda
hdparm -B 254 /dev/sda

The first set of commands leave the drive in a state where it constantly spins down, irrespective of the hdparm -B 254 command. Why is a hdparm -B 1 command issued - I thought only 128 and 254 should be used?

Compare that to what happens when the power is removed and reattached without a suspend/resume cycle (which doesn't leave the drive constantly spinning down):

hdparm -i /dev/sda
hdparm -B 128 /dev/sda
hdparm -i /dev/sda
hdparm -B 254 /dev/sda

The command that is causing the rapid spin down is the spindown time command "hdparm -S 12". Manually issuing a hdparm -S 244 command makes the frequent parking stop. The spindown command is obviously taking precedence over the hdparm -B 254 command.

So the bug is that some process on resume is issuing the spindown time command "hdparm -S 12 /dev/sda" when power is not attached. This spindown time command is normally not executed upon power removal, and consequently there is no corresponding spindown time command issued to increase the time when power is reattached.

I can't find any settings for issuing the hdparm -S 12 command so I can't see which script is doing it - does anyone have any suggestions where to look?

The problem is acerbated by another bug ie that hdparm -S 12 is supposed to cause spin down every 1 minute but instead sets spindown to 5 seconds after no disk activity. See https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/309139 (which is not a duplicate of this bug).

I'm still not sure what is issuing the hdparm -S 12 command, but adding hdparm -S 0 to the beginning of /usr/lib/pm-utils/sleep.d/95hdparm-apm issues the -S 0 command after the -S 12 command, so it's a workaround.

this affect me too in jaunty... to reproduce:
1. with power plugged.. Suspend my laptop
2. unplug power, put my laptop on bag
3. ...
4. unpack laptop and resume

when this happened system locked up for some seconds to start spinning harddisk

Biji, does adding hdparm -S 0 near the beginning of /usr/lib/pm-utils/sleep.d/95hdparm-apm fix the problem for you? I've added it as the first line of resume_hdparm_apm(), ie:

resume_hdparm_apm()
{
 hdparm -S 0 /dev/sda
 if [ -e /usr/sbin/laptop_mode ] ; then

This is happening with my Dell M1330 as well. After resume the disk spins down regularly and then sounds like it is parking. It then spins up after about a 1-2 second wait. This has only happened since Jaunty, intrepid was fine.

i read the man page for hdparm:

-S Set the standby (spindown) timeout for the drive. This value is used by the drive to determine how long to wait (with no disk activity) before turning off the spindle motor to save power.

and this would seem to be what is happening - the OS believes it is still suspended and is parking the drive even though it is on mains and resumed.

I've manually done this:

$ sudo hdparm -S 0 /dev/sda

/dev/sda:
 setting standby to 0 (off)

.. let's see what happens

I can confirm this for a Lenovo T60, Jaunty 32 bit. #8 fixed it.

#8 for me as well... not sure if it actually fixes the problem though or works around it.

It happens on both amd64 and i386 versions of Jaunty.

I can confirm this for Compal FL90, Jaunty 32 bit

This is still occurring for me, it's also a great way to reduce the life of a hard disk - which would probably make this a priority fix ?

I think it's fixed in Karmic. There's also no /usr/lib/pm-utils/sleep.d/95hdparm-apm file in Karmic.

This bug might be related to faulty power management - in Karmic System / Prefs / Power Management, there are tickboxes for 'spin down hard disks when possible' in both the AC power and battery sections. I'll bet Jaunty was issuing the hdparm -S 12 command to spin the drive down as per config but not issuing the hdparm -S 0 command when power was restored.

I haven't seen this happening in Karmic either. I use KDE so the problem wasn't only Gnome related. Whatever that 'spin down hard disks when possible' was plugging into in the backend could be the culprit - although KDE doesn't seem to have a spin down setting in its Power Management module (that I can see)

Rocko, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/361680/comments/15 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.