Re: w83627ehf: Wrong values reported after resuming from suspend/hibernation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 22 Oct 2012 14:40:00 -0700, Guenter Roeck wrote:
> On Mon, Oct 22, 2012 at 05:03:45PM +0200, Harald Judt wrote:
> > Hi,
> > 
> > After resuming from suspend or hibernation, the Vbat value is
> > reported to be 0.0. Before that, it reported the correct value.
> > Min/max values are wrong too.
> > 
> > Linux-3.6.2, ASRock Z77 Extreme4 BIOS v1.80.
> > 
> > Before suspend:
> > nct6776-isa-0290
> > Adapter: ISA adapter
> > Vcore:         +0.97 V  (min =  +0.00 V, max =  +1.74 V)
> > in1:           +1.84 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > AVCC:          +3.34 V  (min =  +2.98 V, max =  +3.63 V)
> > +3.3V:         +3.34 V  (min =  +2.98 V, max =  +3.63 V)
> > in4:           +1.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > in5:           +1.68 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > 3VSB:          +3.47 V  (min =  +2.98 V, max =  +3.63 V)
> > Vbat:          +3.31 V  (min =  +2.70 V, max =  +3.63 V)
> > fan1:            0 RPM  (min =    0 RPM)  ALARM
> > fan2:         1289 RPM  (min =    0 RPM)  ALARM
> > fan3:          724 RPM  (min =    0 RPM)  ALARM
> > fan4:          661 RPM  (min =    0 RPM)  ALARM
> > fan5:         1076 RPM  (min =    0 RPM)  ALARM
> > SYSTIN:        +37.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM
> > sensor = thermistor
> > CPUTIN:        +28.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
> > thermistor
> > AUXTIN:        +33.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
> > thermistor
> > PECI Agent 0:  +32.0°C
> > cpu0_vid:     +0.000 V
> > intrusion0:   ALARM
> > intrusion1:   ALARM
> > 
> > After resuming:
> > nct6776-isa-0290
> > Adapter: ISA adapter
> > Vcore:         +0.97 V  (min =  +0.00 V, max =  +1.74 V)
> > in1:           +1.84 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > AVCC:          +3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > +3.3V:         +3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > in4:           +1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > in5:           +1.68 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > 3VSB:          +3.47 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> > Vbat:          +0.00 V  (min =  +0.00 V, max =  +0.00 V)
> > fan1:            0 RPM  (min =    0 RPM)  ALARM
> > fan2:         1271 RPM  (min =    0 RPM)  ALARM
> > fan3:          734 RPM  (min =    0 RPM)  ALARM
> > fan4:          673 RPM  (min =    0 RPM)  ALARM
> > fan5:         1093 RPM  (min =    0 RPM)  ALARM
> > SYSTIN:        +36.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM
> > sensor = thermistor
> > CPUTIN:        +26.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
> > thermistor
> > AUXTIN:        +33.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor =
> > thermistor
> > PECI Agent 0:  +30.0°C
> > cpu0_vid:     +0.000 V
> > intrusion0:   ALARM
> > intrusion1:   ALARM
> > 
> > Reloading the module helps. Of course, a fresh boot too ;-)

Reloading the module shouldn't help for limits, they are set by
user-space. Reloading the lm_sensors service instead should help.

Vbat is indeed enabled by the driver at device bind time, as well as a
few other things. In your case you report battery monitoring missing,
but other settings may be broken, for example temperature monitoring
could be stuck or overall monitoring could be disabled. Do all values
(other than Vbat) change as before? The exact effects really depend on
what the BIOS is doing to the chip at boot time and resume time.

> The driver doesn't implement suspend/resume support, so it is not very
> surprising that the limits get lost - and it looks like vbat monitoring
> is disabled by default, so that gets lost as well.
> 
> Someone would have to submit a patch to add suspend/resume support to
> the driver ... any takers out there ?

I've been pondering this for a long time. Adding support for limit
saving and restoring to all hwmon drivers would be a significant amount
of code. An easier workaround would be to run "sensors -s" after
resume. This is what I had suggested here:
  https://bugzilla.novell.com/show_bug.cgi?id=580988#c3

However I am not totally happy with this either, because 1* relying on
user-space for anything related to hardware monitoring or fan control
always makes me feel a little nervous, 2* there is no guarantee that
the chip limits at suspend time match the libsensors configuration
files and 3* there are a few other settings which aren't covered by the
libsensors configuration files.

For 1* I suppose it can't be worse than the current situation where we
don't do anything at all at resume time. For 2* it should be correct in
99% of the cases. 3* is the real problem, for example if the user has a
custom script at initialization time to alter fan speeds, etc.

That being said, I'm not sure how many monitoring chips actually lose
their configuration at suspend time. My initial assumption was "most of
them" but if that was the case I presume we would have received many
more complaints than we did. The other report I had was also about a
Winbond Super-I/O chip, and these chips have an area named "Value RAM",
as opposed to actual registers. I would bet this is the part which is
lost on suspend.

So it could be that only drivers for Winbond/Nuvoton drivers need to be
taught how to save and restore values at suspend/resume. Well this is 9
drivers still, but this is only a small percentage of the whole driver
set. Plus the "Value RAM" is a contiguous area so saving and restoring
it should be very easy. I'll give it a try.

-- 
Jean Delvare

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



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux