Hi,
Am 23.10.2012 09:14, schrieb Jean Delvare:
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.
Actually that's what I did. Why the need to reload the service after
suspend? Restarting the service causes some user applications to crash
(yes maybe they should be fixed so that doesn't happen).
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.
All values except the ones mentioned are being reported correctly after
resuming.
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
I will try this and see if it helps. However, the min/max values or
alarms are not something I use on my desktop, so I don't care very much
if they don't work. In other environments, they will be much more
important I guess.
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.
Maybe people don't notice or care too if _some_ values are missing.
Especially when those values are not vital. CPU temp, fan speeds etc ok,
but how many typical users monitor the VBAT voltage?
The VBAT voltage is not shown in BIOS, while other values are. Maybe the
BIOS is at fault here, and the problem needs to be tackled there.
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.
Harald
--
`Experience is the best teacher.'
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
