On Thu, Dec 06, 2012 at 10:59:27AM +0100, G. Schlisio wrote:

...

after updating my laptop today [0] (no testing enabled) i notice that my harddisk keeps spinning down and up every 10 seconds or so. might this be related to the update or where can i stop this?

somehow it resolved itself today. now hdd is running continuously again.

If it happens again, you can check this with: hdparm -B /dev/sdx If it's spinning down too often, try: hdparm -B 254 /dev/sdx -- Jonathan Steel

On 6 December 2012 17:05, G. Schlisio wrote:

Am 06.12.2012 21:07, schrieb Jonathan Steel:

On Thu, Dec 06, 2012 at 10:59:27AM +0100, G. Schlisio wrote:

...

...

after updating my laptop today [0] (no testing enabled) i notice

...

that my harddisk keeps spinning down and up every 10 seconds or so. might this be related to the update or where can i stop this?

somehow it resolved itself today. now hdd is running continuously again.

If it happens again, you can check this with:

hdparm -B /dev/sdx

If it's spinning down too often, try:

hdparm -B 254 /dev/sdx

thank you for your advice.

hdparm -B /device returns 254 to me now, thats quire expected, because now everything works fine.

i wonder, how/whether it could have been altered yesterday. do programs like powertop touch those values?

If you are messing around with powertop, yes I think that could have been it. Usually powertop can adjust hd settings

On 12/08/12 at 09:48pm, G. Schlisio wrote:

Am 07.12.2012 01:49, schrieb Calvin Morrison:

...

On 6 December 2012 17:05, G. Schlisio wrote:

...

Am 06.12.2012 21:07, schrieb Jonathan Steel:

On Thu, Dec 06, 2012 at 10:59:27AM +0100, G. Schlisio wrote:

...

...

after updating my laptop today [0] (no testing enabled) i notice

...

that my harddisk keeps spinning down and up every 10 seconds or so. might this be related to the update or where can i stop this?

somehow it resolved itself today. now hdd is running continuously again.

If it happens again, you can check this with:

hdparm -B /dev/sdx

If it's spinning down too often, try:

hdparm -B 254 /dev/sdx

thank you for your advice. hdparm -B /device returns 254 to me now, thats quire expected, because now everything works fine.

i wonder, how/whether it could have been altered yesterday. do programs like powertop touch those values?

If you are messing around with powertop, yes I think that could have been it. Usually powertop can adjust hd settings

i uninstalled powertop after my last post, but yesterday it happend again. when i checked the APM level it was set to 1. i only experience this after suspend to ram. how can i get to know, why this is happening, and maybe stop it?

When I still had rotational hard drives, I noticed that my APM level would reset after suspend. This, I later found, is expected behavior. So you either need to put something in /usr/lib/systemd/system-sleep or make an appropriate service file to reinstate the APM. Why it defaults to 1 I have not idea though. Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com

Am 09.12.2012 18:55, schrieb Leonid Isaev:

On Sat, 08 Dec 2012 21:48:54 +0100 "G. Schlisio" wrote:

...

[...] how can i get to know, why this is happening, and maybe stop it? I suspect the issue is in pm-utils' pm-powersave script which executes "power saving" hooks, and is in turn being called by upower. But to be sure we need to see your pm-utils configuration (in /etc/pm) and and /etc/Upower/Upower.conf...

/etc/pm/ contains conf.d/, power.d/ (both empty) and sleep.d/ (contains 90alsa, not doing much apart aplay). upower [0] contains a RunPowersaveCommand=true, does that include APM=1 setting? what curtis said about expected behavior and default settings, can those be altered somewhere? my /usr/lib/systemd/system-sleep/notify-upower.sh contains some call of upower{,.resuming} via dbus. what irritates me is that i experience this after last update, and never before. [0] my upower.conf: [UPower] SleepTimeout=1000 AllowHibernateEncryptedSwap=true RunPowersaveCommand=true EnableWattsUpPro=true PollDockDevices=false IgnoreLid=false

On Thu, 13 Dec 2012 00:35:32 +0100 "G. Schlisio" wrote:

Am 10.12.2012 00:13, schrieb G. Schlisio:

...

Am 09.12.2012 18:55, schrieb Leonid Isaev:

...

On Sat, 08 Dec 2012 21:48:54 +0100 "G. Schlisio" wrote:

...

[...] how can i get to know, why this is happening, and maybe stop it? I suspect the issue is in pm-utils' pm-powersave script which executes "power saving" hooks, and is in turn being called by upower. But to be sure we need to see your pm-utils configuration (in /etc/pm) and and /etc/Upower/Upower.conf...

/etc/pm/ contains conf.d/, power.d/ (both empty) and sleep.d/ (contains 90alsa, not doing much apart aplay). upower [0] contains a RunPowersaveCommand=true, does that include APM=1 setting? what curtis said about expected behavior and default settings, can those be altered somewhere? my /usr/lib/systemd/system-sleep/notify-upower.sh contains some call of upower{,.resuming} via dbus. what irritates me is that i experience this after last update, and never before.

[0] my upower.conf:

[UPower] SleepTimeout=1000 AllowHibernateEncryptedSwap=true RunPowersaveCommand=true EnableWattsUpPro=true PollDockDevices=false IgnoreLid=false seems unrelated to suspend, but related to switch between external and internal power supply. where can i adjust hese settings? may kde interfere here? suggestions appreciated.

Sorry for a late reply... The RunPowersaveCommand= tells upower to run hooks in /usr/lib/pm-utils/power.d/ via calling /usr/sbin/pm-powersave whenever power state is altered (e.g. plugging the AC power). Changing it to 'false' will disable calling pm-powersave command altogether. However, on my system I have nothing in that directory which calls hdparm (and yes, I disabled the above option). Do you happen to have a 'harddrve' hook there? Regarding KDE: just kill X, from tty call something like "upower -d" (as a normal user) to start upower if it's not running already, and replug the external power... -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D