On 6/20/19 8:42 PM, Sébastien Béhuret wrote: > Package: hdparm > Version: 9.58+ds-1 > Severity: serious > > Dear Maintainers, > > In this version of hdparm, a new option 'force_spindown_time' was > introduced to set the spindown time for disks that don't support APM. > This option is supposed to translate to hdparm -S, similarly to the > original option 'spindown_time'. > > hdparm package comes with 3 main scripts: > > 1) /usr/lib/pm-utils/power.d/95hdparm-apm > This script will translate 'force_spindown_time' to hdparm -S and apply > the option even if APM was not detected. > This is the desired behavior. > > 2) /etc/apm/event.d/20hdparm > This script will ignore /etc/hdparm.conf and apply hard-coded defaults > instead. > This behavior is unexpected. > Expected/Desired behavior: Read /etc/hdparm.conf and apply relevant options. > > 3) /lib/hdparm/hdparm-functions (sourced from /lib/udev/hdparm, which is > invoked by udev rule /lib/udev/rules.d/85-hdparm.rules) > - 'force_spindown_time' is buggy because it is not converted back to -S, > which leads to a syntax error during hdparm execution (e.g. hdparm > force_spindown_time$VALUE instead of hdparm -S$VALUE). > - Both options 'spindown_time' and 'force_spindown_time' are processed > even if APM is not supported. From the comments in the configuration > file (/etc/hdparm.conf), it is understood that 'spindown_time' will be > applied for APM disks only and 'force_spindown_time' for all disks (or > possibly for non-APM disks only). > - The scripts will also apply hard-coded defaults for -S and -B if APM > was detected. The hard-coded defaults differ from those used in > /etc/apm/event.d/20hdparm, leading to inconsistent behavior. > > 4) Additional issues with non-APM disks: > - Manually invoking hdparm -S$VALUE /dev/sdx is simply ignored even > though hdparm executes successfully. The disks do not spin down after > the time delay when there was no access. > - Manually invoking hdparm -y /dev/sdx will spin down the disks > immediately. The disks will not wake up unless they are accessed, which > is the expected behavior. > > These were all working fine in hdparm 9.51+ds-1+deb9u1, which is the > current version in stretch. > > In short, it is currently impossible to obtain a consistent and working > configuration for non-APM disks. > > Many thanks and regards, > Sebastien Behuret
Hi Sebastien, 2. As APM is almost dead and most likely there are no laptops using APM and buster. I'll drop /etc/apm/event.d/20hdparm in the next release. 3. This is a real issue. In /lib/hdparm/hdparm-functions I've left the "force_spindown_time$VALUE" option intentionally, it need to be translated to "-S" later in scripts using hdparm-functions like it is done in 95hdparm-apm /lib/udev/hdparm is called by udev and need to be fixed. /usr/lib/pm-utils/power.d/95hdparm-apm called by pm-utils events and takes care only about spin_down and apm options for the disks which support apm. To obtain a consistent behavior /lib/udev/hdparm can call /usr/lib/pm-utils/power.d/95hdparm-apm for spindown and apm options and hdparm directly for all other options. 4. I failed to reproduce that. I couldn't put to standby a non-apm disk on a stretch system with hdparm -S (hdparm 9.51) Could you please try to build hdparm 9.51 or just get a binary package and run it to see if 9.51 works for your disks compared to 9.58? Thank you for the detailed report. Alex
