hdparm.conf settings (other than apm) are lost on suspend/resume?

Bug #199094 reported by Jakob Unterwurzacher on 2008-03-06
86
This bug affects 14 people
Affects Status Importance Assigned to Milestone
hdparm (Ubuntu)
Wishlist
Daniel Hahler
pm-utils (Ubuntu)
Wishlist
Unassigned

Bug Description

Update: This is on Intrepid.

Problem:
- Hard disks lose settings (the APM level for example) when they are powered off.
=> Settings in /etc/hdparm.conf persist only from boot to next suspend.

Expected:
All settings in /etc/hdparm.conf should persist across {suspend,hibernate}/resume.

Effects:
At least the apm setting in hdparm.conf is lost. This makes https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 so bad - users are not able to set the apm value without messing with their system (installing stuff from forums) because of this bug.

Jakob Unterwurzacher (jakobunt) wrote :
Jakob Unterwurzacher (jakobunt) wrote :
Jakob Unterwurzacher (jakobunt) wrote :
description: updated
Daniel Hahler (blueyed) wrote :

This sounds like bug 156893. Can you please test the fix from there?

Changed in hdparm:
assignee: nobody → blueyed
status: New → Incomplete
Jakob Unterwurzacher (jakobunt) wrote :

Your patch from bug 156893 restores the APM level after resume, that's the most important thing.
Marking as duplicate.

The patch for 156893 doesn't fix the resume-from-suspend/hibernate bug which makes my HDD apm default to 128, in spite of having set a value of 192 in /etc/hdparm.conf. Something else must be overwriting it on resume, because if I put a script 99-hdparm.sh in /usr/lib/pm-utils/sleep.d which contains hdparm -B 192 /dev/sda it restores the value as it should.

Daniel Hahler (blueyed) wrote :

Valentin, please check if it's bug 89269 that you're experiencing.

description: updated
Changed in hdparm:
status: Incomplete → Confirmed

I upgraded to Hardy yesterday - I am experiencing this bug again. Daniel's patch from bug 156893 had fixed it in Gutsy.
bug 89269 says "Fix released", so I guess that's not it.

That's what happens:
[cold boot]
$ sudo hdparm -I /dev/sda|grep "Advanced power management level:"
 Advanced power management level: 254
[suspend/resume]
$ sudo hdparm -I /dev/sda|grep "Advanced power management level:"
 Advanced power management level: 128

In laptop-mode.conf I have
CONTROL_HD_POWERMGMT=0

In hdparm.conf
apm = 254
/dev/sda {
}

Daniel Hahler (blueyed) wrote :

Jakob, please check if this has regressed for you with acpi-support 0.109 (https://bugs.edge.launchpad.net/ubuntu/+source/acpi-support/+bug/89269/comments/9) - which addressed bug 89269.

No, this is not a regression because of bug #89269. I checked by reverting the changes (removed the extra '*'s from power.sh). Additionally, power.sh would have set the apm level to 1 or 255, not 128.

Attached is the udevmonitor log for a suspend/resume cycle.
It looks like there was no add event for sda, that would explain why the rule wasn't executed.
(I don't really know the /devices/... nomenclatura, but there is none of the words sda, scsi, block, sd, hd)

ethanay (ethan-y-us) wrote :

I am experiencing the same issue in Hardy. Please let me know if I can provide any useful information.

ethanay (ethan-y-us) wrote :

The workaround Valentin Neacsu posted in bug #89269 is working for me so far, so please disregard my last post, I guess

This should finally fix it.
Put it into /usr/lib/pm-utils/sleep.d/30hdparm , and chmod +x it.

Does it look sane? Does it work for everybody?

It did not fix it for me Jakob

This is still happening for me in Hardy. This really should probably be marked 'high' priority - similar to https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/156893

This can lead to hdd damage and poor performance on laptops. Hdd damage because of https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 and poor performance because of hard drive cycles slowing down IO. eg: vim would freeze for me for 5+ seconds on a write waiting for the hard drive to spin back up,..

Daniel T Chen (crimsun) on 2008-12-01
Changed in acpi-support:
importance: Undecided → Wishlist
Max Bowsher (maxb) wrote :

Still a problem on Intrepid....

Jakob's script doesn't quite work as is - did the sysfs layout change?

Anyway, fixed up and trimmed down to:
---- snip ----
#!/bin/sh

# Run hdparm like on boot to restore hdparm.conf settings -
# disk lose them when going to standby.

case "$1" in
    thaw|resume)
    for x in /sys/bus/ide/devices/*/block/* \
        /sys/bus/scsi/devices/*/block/*; do
        # This check is required - x can contain literal
        # '/sys/bus/(bustype)/devices/*/block/*' when the glob did not match
        # anything.
        if [ -e "$x" ]; then
            DEVNAME="/dev/${x##*/}" /lib/udev/hdparm
        fi
    done
    ;;
esac
---- snip ----

it now works for me, successfully restoring my apm=254 hdparm.conf setting on resume.

I think this is a rather important bug, that might even warrant a SRU.

description: updated

In karmic there's been substantial cleanup of the hdparm handling on the system; acpi-support and laptop-mode-tools should no longer be interfering with hdparm settings at all, which leaves only pm-utils.

pm-utils (in cooperation with hdparm) will now use a new 'apm_battery' value in hdparm.conf, falling back to the previous apm value of 128 if no such setting is found. So if you want to use the same apm setting on battery as off, you can now set hda_battery = 254 in hdparm.conf and it will be honored.

I think there's still a valid wishlist request here to have other hdparm.conf settings reapplied to disks after suspend/resume; I don't know if Linux suspend is guaranteed to preserve these for us. So reassigning to pm-utils for consideration of that aspect, which should be the only remaining bug here.

affects: acpi-support (Ubuntu) → pm-utils (Ubuntu)
Changed in pm-utils (Ubuntu):
status: New → Triaged
Changed in hdparm (Ubuntu):
importance: Undecided → Wishlist
summary: - hdparm.conf settings are lost on suspend/resume
+ hdparm.conf settings (other than apm) are lost on suspend/resume?
Changed in hdparm (Ubuntu):
status: Confirmed → Triaged
Torsten Krah (tkrah) wrote :

At least its still missing other aspects.
I need "-S0" to my drive - this is lost after suspend / resume cycle too.
I modified 95hdparm-apm to get this working again, but why not use the values i did specified at /etc/hdparm.conf?

Bryce Harrington (bryce) wrote :

I'm unmarking the patch as a patch since I gather it's long since been integrated into hdparm, to get this off the patches-to-sponsor list. We'll need a new patch for the remaining issue with pm-utils before it can be considered for sponsoring.

Also, it's been a couple years since the last comment; is this issue still reproducing against current Ubuntu?

Changed in pm-utils (Ubuntu):
status: Triaged → Incomplete
Torsten Krah (tkrah) wrote :

Yes this one is still happening on my fresh updated lucid. Custom hdparm options are still lost after resume and i still need to have a custom script to execute in resume process.
Would be nice to see this fixed and hdparm.conf evaluated at resume time.

Bazon (bazonbloch) wrote :

I have an at least similar issue on 12.10 quantal with spindown:
 I want to spin down my external USB drive /dev/sdc as fast as possible:
in /etc/hdparm.conf:

/dev/sdc {
 spindown_time = 1
}

that works, although I get

$ sudo hdparm -C /dev/sdc
/dev/sdc:
SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 drive state is: unknown

but after resume from suspend, it doesn't work anymore.

my workaround is
/etc/pm/sleep.d/20-hdparm

#!/bin/bash
case "$1" in
 thaw|resume)
  hdparm -S 1 /dev/sdc
  ;;

esac

and that works, anyway, spindown settings shouldn't get lost on suspend/resume in the first place.

So what is most reasonable?
 * Deal with that issue in this bug?
 * Reopen bug https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/738757 which is closer to the problem I got?
 * Open a new bug?

Steve Langasek (vorlon) wrote :

So I'm not sure why people are still seeing a bug here. The /usr/lib/pm-utils/sleep.d/95hdparm-apm script does this:

        thaw|resume)
                resume_hdparm_apm
                # only set the -S option on resuming, not necessary for power.d
                resume_hdparm_spindown
                ;;

So it explicitly sets the -B and -S options on resume, which are the exact options that users are reporting problems with. I think someone who's seeing this problem needs to diagnose what's going wrong with that script. Does it work if you run it by hand?

Changed in hdparm (Ubuntu):
status: Triaged → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for pm-utils (Ubuntu) because there has been no activity for 60 days.]

Changed in pm-utils (Ubuntu):
status: Incomplete → Expired
Rafał Ochmański (rmopl) wrote :

I'm affected by this bug. After suspend APM_level is reset to 254

# hdparm -B /dev/sda
/dev/sda:
 APM_level = 254

Settings in /etc/hdparm.conf are ignored

command_line {
        hdparm -S 12 -B 48 /dev/sda
}

Even a workaround with /etc/pm/sleep.d/20_resume

#!/bin/sh
case "${1}" in
 resume|thaw)
  killall ssh
  hdparm -S 12 -B 48 /dev/sda
  ;;
esac

somehow doesn't work. I need to manually run hdparm after every suspend.

Changed in hdparm (Ubuntu):
status: Incomplete → Confirmed
Changed in pm-utils (Ubuntu):
status: Expired → Confirmed
tags: added: quantal
Rafał Ochmański (rmopl) wrote :

Oh, this is Quantal

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal

Graeme Hewson (ghewson) wrote :

I'm experiencing this in 15.04. With the change to systemd, the pm-utils scripts are no longer run when the system resumes after suspend.

Torsten Krah (tkrah) wrote :

"Nice" thread about systemd + hdparm:

http://lists.freedesktop.org/archives/systemd-devel/2012-June/005595.html

So it seems users should write their own udev rules to get this working :-| or some custom distro specific stuff. Its really weird that this one is still around after that many years which have passed now.

Graeme Hewson (ghewson) wrote :

I've given up on hdparm.conf now. As noted in #27, it seems that systemd and udev/udisks2 is the way to go, but it's not clear how exactly.

Here's what I've done. This bug report isn't the ideal place to document it, but I can't find a better place for now. Maybe it'll help someone who finds it through a search engine.

The Ubuntu Disks utility (not in the Launcher by default) allows configuration of the spindown/standby time and other settings. (See below for Kubuntu.) Click on the disk in the left-hand pane, then click the "hamburger" icon at the top right and select Drive Settings.

Great! Except... what it says in the title of this bug. Also:
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1511703

I fixed this by coding a sleep script as shown in
https://wiki.archlinux.org/index.php/Power_management#Hooks_in_.2Fusr.2Flib.2Fsystemd.2Fsystem-sleep
Note the directory in Ubuntu is /lib/systemd/system-sleep/, which is different from Arch Linux.

In the "post/*" case I simply coded the required hdparm command directly, e.g.

hdparm -B 254 -S 120 /dev/sdb

I'd earlier tried to make hdparm.conf work by emulating the pmutils scripts by coding, e.g.,

DEVNAME=/dev/sdb /lib/udev/hdparm

but that didn't work for some reason. I don't think I worked out why.

Kubuntu users (like me) and others who don't have the Ubuntu Disks utility available need to write a config file (which, of course, is what hdparm.conf is) to set the post-boot spindown time, etc. See udisks(8) for the format of the file /etc/udisks2/IDENTIFIER.conf, the file which the Disks utility writes. For instance:

[ATA]
APMLevel=254
StandbyTimeout=120

What is IDENTIFIER? Run "udisksctl dump" (the output is piped to less) and look for an object path starting "/org/freedesktop/UDisks2/drives/" with your drive model and serial number. Within the org.freedesktop.UDisks2.Drive interface underneath that, the Id property is the required IDENTIFIER part of the filename. See
http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Drive.html#gdbus-property-org-freedesktop-UDisks2-Drive.Id

So it seems that in 2015, it's a bit more complicated than writing /etc/hdparm.conf. It seems (unless there's currently a better way) it's necessary to specify the hdparm settings for the post-boot and post-resume conditions in two different ways.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.