All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald Judt <h.judt@gmx.at>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] w83627ehf: Wrong values reported after resuming from suspend/hibernation
Date: Thu, 25 Oct 2012 17:26:45 +0000	[thread overview]
Message-ID: <50897655.8050001@gmx.at> (raw)
In-Reply-To: <50856051.5070803@gmx.at>

Am 24.10.2012 21:23, schrieb Jean Delvare:
> On Wed, 24 Oct 2012 20:14:41 +0200, Harald Judt wrote:
>> Hi Jean,
>>
>> Am 24.10.2012 20:05, schrieb Harald Judt:
>> [...]
>>> Thank you for your patch. I've applied it on 3.6.2, and it seems to work
>>> fine. The values are saved and restored correctly, and they also keep
>>> changing after resume. Further it gave me a little insight in how
>>> suspend/resume code works.
>>
>> Sorry, I stand corrected. Not all min/max values have been restored:
>>
>> Before suspend:
>> 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.05 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
>> in5:           +1.68 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
>>
>> After resume:
>> 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.05 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
>> in5:           +1.68 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
>>
>> I somehow missed the min/max differences in AVCC and +3.3V, too many
>> numbers ;-)
>
> Odd, I'll take a look.
>
>> But the rest is fine, double-checked now.
>
> To be really sure, it would be good if you could set arbitrary non-zero
> limits to in1, in4, in5 etc. otherwise we can't be sure these limits
> have been restored either.

Good idea. Here is the corresponding part of my adjusted 
/etc/sensors3.conf file:

chip "w83627ehf-*" "w83627dhg-*" "w83667hg-*" "nct6775-*" "nct6776-*"

     label in0 "Vcore"
     label in2 "AVCC"
     label in3 "+3.3V"
     label in7 "3VSB"
     label in8 "Vbat"

     set in0_min  0.5 * 1.00
     set in0_max  2.0 * 1.00
     set in1_min  1.6 * 1.00
     set in1_max  1.95 * 1.00
     set in2_min  2.0 * 1.00
     set in2_max  3.5 * 1.00
     set in3_min  2.0 * 1.00
     set in3_max  3.5 * 1.00
     set in4_min  0.8 * 1.00
     set in4_max  1.2 * 1.00
     set in5_min  1.5 * 1.00
     set in5_max  1.95 * 1.00
     set in7_min  2.0 * 1.00
     set in7_max  3.5 * 1.00
     set in8_min  2.0 * 1.00
     set in8_max  3.5 * 1.00

There are some limits for min/max values, e.g. in5_max will get reset to 
2.04 if you try to use a higher value. Therefore I've set it to 0.95 to 
avoid any confusion.

So, here are the results after sensors -s:

nct6776-isa-0290
Adapter: ISA adapter
Vcore:         +0.96 V  (min =  +0.50 V, max =  +2.00 V)
in1:           +1.84 V  (min =  +1.60 V, max =  +1.95 V)
AVCC:          +3.34 V  (min =  +2.00 V, max =  +3.50 V)
+3.3V:         +3.34 V  (min =  +2.00 V, max =  +3.50 V)
in4:           +1.05 V  (min =  +0.80 V, max =  +1.20 V)
in5:           +1.68 V  (min =  +1.50 V, max =  +1.95 V)
3VSB:          +3.47 V  (min =  +2.00 V, max =  +3.50 V)
Vbat:          +3.31 V  (min =  +2.00 V, max =  +3.50 V)

And after resume:
nct6776-isa-0290
Adapter: ISA adapter
Vcore:         +0.96 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.05 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.00 V, max =  +3.50 V)
Vbat:          +3.31 V  (min =  +2.00 V, max =  +3.50 V)

Apparently, in0-in5 do not get restored, only in7 and in8 do. There is 
no in6 on this chip (verified by looking in /sys/class/hwmon).

>> BTW: cpu0_vid is always +0.000 V, am I right assuming this simply isn't
>> supported on my board?
>
> Yes, that's the most likely. With CPUs reporting their VID through MSRs
> these days, board manufacturers tend to stop wiring the VID pins to
> save space on the PCB.

Thanks for clarification.

Note that I'll be able to respond to mails but not to do any further 
tests on this machine until 2nd of November.

Regards,
Harald

-- 
`Experience is the best teacher.'

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

  parent reply	other threads:[~2012-10-25 17:26 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 15:03 [lm-sensors] w83627ehf: Wrong values reported after resuming from suspend/hibernation Harald Judt
2012-10-22 21:40 ` Guenter Roeck
2012-10-23  7:14 ` Jean Delvare
2012-10-23  9:57 ` Harald Judt
2012-10-23 11:45 ` Jean Delvare
2012-10-23 12:08 ` Harald Judt
2012-10-23 12:34 ` Jean Delvare
2012-10-23 14:01 ` Guenter Roeck
2012-10-23 16:32 ` Jean Delvare
2012-10-23 19:02 ` Harald Judt
2012-10-24  3:45 ` Guenter Roeck
2012-10-24  8:39 ` Jean Delvare
2012-10-24 18:05 ` Harald Judt
2012-10-24 18:14 ` Harald Judt
2012-10-24 19:23 ` Jean Delvare
2012-10-25  9:53 ` Guenter Roeck
2012-10-25 17:26 ` Harald Judt [this message]
2012-10-25 19:07 ` Jean Delvare
2012-10-25 19:16 ` Harald Judt
2012-10-25 20:37 ` Guenter Roeck
2012-10-25 23:49 ` Guenter Roeck
2012-10-26  0:41 ` Guenter Roeck
2012-10-26  0:55 ` Harald Judt
2012-10-26  7:27 ` Jean Delvare
2012-10-26 14:06 ` Guenter Roeck
2012-10-26 14:15 ` Jean Delvare
2013-07-28 20:43 ` Harald Judt
2013-07-28 21:43 ` Guenter Roeck
2013-07-28 22:28 ` Guenter Roeck
2013-07-29  2:24 ` Harald Judt
2013-07-29  2:47 ` Harald Judt
2013-07-29  6:58 ` Guenter Roeck
2013-07-29  9:12 ` Harald Judt
2013-07-29 15:27 ` Harald Judt
2013-07-29 22:46 ` Guenter Roeck
2013-07-31 22:11 ` Guenter Roeck
2013-08-01  9:08 ` Harald Judt
2013-08-01 13:42 ` Guenter Roeck
2013-08-01 14:36 ` Harald Judt
2013-08-01 17:46 ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50897655.8050001@gmx.at \
    --to=h.judt@gmx.at \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.