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

Bug #361680 reported by Rocko on 2009-04-15
This bug affects 5 people
Affects Status Importance Assigned to Milestone
pm-utils (Ubuntu)

Bug Description

Binary package hint: pm-utils

After each suspend/resume cycle on my Dell XPS M1530, bug #59695 reappears. It doesn't happen in normal circumstances, eg after reboot. More importantly, issuing hdparm -B 254 /dev/sda has no effect - the disk still keeps regularly parking.

The problem is that some process issues the command 'hdparm -S 12 /dev/sda' when I resume without power attached and this overrides the hdparm -B 254 command (see notes in comments below). A hdparm -S command to reverse the effects of hdparm -S 12 is not issued when power is reattached.

I used smartctl in a script to show frequency of disk parking after resume (date and time is included), issued a hdparm command which appears to work, but the script shows that disk parking continues afterwards:

root@pegasus-jaunty:~# ./load.sh
20090415 1653
193 Load_Cycle_Count 0x0032 099 099 000 Old_age Always - 11236
20090415 1946
193 Load_Cycle_Count 0x0032 099 099 000 Old_age Always - 11279
root@pegasus-jaunty:~# hdparm -B 254 /dev/sda

 setting Advanced Power Management level to 0xfe (254)

root@pegasus-jaunty:~# ./load.sh
193 Load_Cycle_Count 0x0032 099 099 000 Old_age Always - 11285
root@pegasus-jaunty:~# ./load.sh
193 Load_Cycle_Count 0x0032 099 099 000 Old_age Always - 11287

If I do the same thing after a reboot on power, the load cycle count does not change, which is what I expect.

This problem didn't happen in Intrepid, and I believe it has only recently started happening in Jaunty (since the beta was released).

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: pm-utils
PackageArchitecture: all
SourcePackage: pm-utils
Uname: Linux 2.6.28-11-generic x86_64

Rocko (rockorequin) wrote :
summary: - hard disk parks reguarly after suspend - hdparm -B 254 has no effect
+ hard disk parks regularly after resume - hdparm -B 254 has no effect
Rocko (rockorequin) wrote :

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.

Rocko (rockorequin) wrote :

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?

Rocko (rockorequin) wrote :

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

Rocko (rockorequin) wrote :

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).

Rocko (rockorequin) on 2009-04-23
description: updated
Rocko (rockorequin) wrote :

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.

Biji (biji) wrote :

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

Rocko (rockorequin) wrote :

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:

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

James (james-ellis-gmail) wrote :

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

 setting standby to 0 (off)

.. let's see what happens

oudalrich (uhkeller) wrote :

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

James (james-ellis-gmail) wrote :

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

Rocko (rockorequin) wrote :

It happens on both amd64 and i386 versions of Jaunty.

Changed in pm-utils (Ubuntu):
status: New → Confirmed
JANWAR (janwar) wrote :

I can confirm this for Compal FL90, Jaunty 32 bit

James (james-ellis-gmail) wrote :

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 ?

Rocko (rockorequin) wrote :

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.

James (james-ellis-gmail) wrote :

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.

Changed in pm-utils (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers