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

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

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.

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

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 {
}

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)

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

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

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.

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.

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?

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?

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.

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?

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?

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

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.

Oh, this is Quantal

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

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.

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

Also:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725284
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779412

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.