I have done more testing with the patch released in hdparm
(9.32-1ubuntu2) and found that there are some problems with the approach
taken. I think this bug should be marked FIXED-FAILED and revisited.
By adding the hdparm -S parameter handling to the power.d script for
'true' and 'false' power.d events in addition to the 'thaw' and 'resume'
events proposed in the original patch, a side effect has now been
introduced. The drive will now be awakened from standby state for every
power event transition ('true' and 'false') so that the hdparm -S
command can be applied.
This is undesirable from several perspectives. First, and foremost, it
wakes a sleeping drive to submit a command that affects how long the
drive should wait before going to sleep. When the drive goes to sleep
again, that parameter will be lost, so waking it to tell it that serves
no positive purpose.
Unlike the -B apm parameter modification, the -S parameter should not be
modified on both a 'true' and 'false' power event, since there is no
side benefit to changing the -S parameter when entering or exiting
powersave mode for a drive that is still awake, since it will already
have the -S parameter from the hdparm.conf file currently applied. The
-S parameter is static in the hdparm.conf file and should have been
applied at power on, or when it last came back from standby or sleep on
a 'resume' or 'thaw' event.
Another undesired consequence of applying the hdparm -S command in the
power.d script is that it creates an incompatibility in the powernap
utility with using the powersave ACTION mode in conjunction with the
DiskMonitor plugin I have proposed
https://code.launchpad.net/~jinfo/powernap/trunk. This is due to the
fact that if the DiskMonitor is monitoring a drive to detect the
standby/sleep state, and then subsequently tries to execute pm-powersave
command, the drive will be awoken by the power.d script, which tries to
apply the hdparm -S command to the drive that is in standby or sleeping,
thus awakening it, and causing an invalidation of the conditions to
enter low power mode (e.g. the drive is now awake).
Indeed, from my testing it seems as if even issuing a pm-suspend causes
the 'true' condition of the power.d script to be triggered, as I am
seeing sleeping drives awoken when I issue pm-suspend prior to the
system going into standby. So the drives are awoken, given the new
hdparm -S command and then the system enters standby where the drives
are again immediately put back into standby, not good.
In my opinion, my original patch is the more correct handling of the
loss of hdparm -S (spindown) settings within pm-utils. The
reapplication of these settings should only be done from within the
sleep.d script for 'resume' and 'thaw' events. Upon reawakening from
sleep or standby are the only times the drive would have "lost" the
settings contained in hdparm.conf.
Please reconsider using the original patch.
Best Regards,
-Jim Heck
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/738757
Title:
spindown settings lost on pm-suspend indirectly affects powernap power
savings
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
