[lm-sensors] resume lm_sensor from hibernate or suspend

[lm-sensors] resume lm_sensor from hibernate or suspend

[Nikola Pajkovsky]

Hi guys,

    I'd like to talk about bug 
https://bugzilla.redhat.com/show_bug.cgi?idH6874. Hans says that's not 
good idea resume automatically with sensors -s in 
/usr/lib/pm-utils/sleep.d.
Do you have any other idea?

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] resume lm_sensor from hibernate or suspend

[Jean Delvare]

Hi Nikola,

On Tue, 14 Jul 2009 13:59:30 +0200, Nikola Pajkovsky wrote:
> Hi guys,
> 
>     I'd like to talk about bug 
> https://bugzilla.redhat.com/show_bug.cgi?idH6874. Hans says that's not 
> good idea resume automatically with sensors -s in 
> /usr/lib/pm-utils/sleep.d.
> Do you have any other idea?

This has the merit of being very simple and to solve the problem
immediately at hand. However there are a few things to keep in mind:

* Whether limits need to be rewritten may depend on several things,
  including but not limited to:
  - resume from RAM vs. resume from disk
  - hardware monitoring chip model
  - BIOS implementation details

* You should only call "sensors -s" if you also do it on system boot.
  If the user/admin is somehow given an option to run it or not at
  system boot then his/her choice should also be honored at resume time.
  That being said, the default libsensors configuration file these days
  no longer contains any possibly wrong "set" statement, so we should
  be on the safe side either way.

* I thought that restoring devices to their pre-suspend state was the
  kernel's job? With the proposed user-space solution, I can imagine a
  scenario where the system is resumed with random sensor limits, an
  alarm triggers because of this, and only then "sensors -s" is run.
  This could cause spurious beeping or system halt for example,
  depending on how the monitoring device in question is wired.
  That being said, these are issues we would already hit now without
  your proposed implementation, so it can't make it worse.

All in all I see no problem implementing you idea on a per-distribution
basis as long as my second point above is taken into consideration.

Hans, did you have any specific issue in mind, which I overlooked?

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] resume lm_sensor from hibernate or suspend

[Hans de Goede]

On 07/14/2009 01:59 PM, Nikola Pajkovsky wrote:
> Hi guys,
>
>      I'd like to talk about bug
> https://bugzilla.redhat.com/show_bug.cgi?idH6874. Hans says that's not
> good idea resume automatically with sensors -s in
> /usr/lib/pm-utils/sleep.d.
> Do you have any other idea?
>

Hi,

Thanks for taking this discussion here!

I'm not saying that this necessarily is a bad idea, I'm just not sure it is
a good idea. I cannot think of any side effects from the top of my head,
but maybe others can.

Also if we do a script doing this to be placed in /usr/lib/pm-utils/sleep.d
then we should do this in upstream lm_sensors, so that all distro's get it
(and there do turn out to be issues we have one central place to fix this).

Regards,

Hans



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] resume lm_sensor from hibernate or suspend

[Hans de Goede]

On 07/14/2009 03:21 PM, Jean Delvare wrote:
> Hi Nikola,
>
> On Tue, 14 Jul 2009 13:59:30 +0200, Nikola Pajkovsky wrote:
>> Hi guys,
>>
>>      I'd like to talk about bug
>> https://bugzilla.redhat.com/show_bug.cgi?idH6874. Hans says that's not
>> good idea resume automatically with sensors -s in
>> /usr/lib/pm-utils/sleep.d.
>> Do you have any other idea?
>
> This has the merit of being very simple and to solve the problem
> immediately at hand. However there are a few things to keep in mind:
>
> * Whether limits need to be rewritten may depend on several things,
>    including but not limited to:
>    - resume from RAM vs. resume from disk
>    - hardware monitoring chip model
>    - BIOS implementation details
>
> * You should only call "sensors -s" if you also do it on system boot.
>    If the user/admin is somehow given an option to run it or not at
>    system boot then his/her choice should also be honored at resume time.
>    That being said, the default libsensors configuration file these days
>    no longer contains any possibly wrong "set" statement, so we should
>    be on the safe side either way.
>
> * I thought that restoring devices to their pre-suspend state was the
>    kernel's job? With the proposed user-space solution, I can imagine a
>    scenario where the system is resumed with random sensor limits, an
>    alarm triggers because of this, and only then "sensors -s" is run.
>    This could cause spurious beeping or system halt for example,
>    depending on how the monitoring device in question is wired.
>    That being said, these are issues we would already hit now without
>    your proposed implementation, so it can't make it worse.
>
> All in all I see no problem implementing you idea on a per-distribution
> basis as long as my second point above is taken into consideration.
>
> Hans, did you have any specific issue in mind, which I overlooked?
>

No, I just thought it would be good to discuss this with a wider
audience, and maybe come up with an upstream solution.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors