linux-kernel - Re: [RFT PATCH 0/4] hwmon: k10temp driver improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <00c42e87-dd87-9116-607f-a0bdbf49d948@roeck-us.net>
Date:   Fri, 17 Jan 2020 06:14:35 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Ken Moffat <zarniwhoop73@...glemail.com>
Cc:     linux-hwmon@...r.kernel.org, Clemens Ladisch <clemens@...isch.de>,
        Jean Delvare <jdelvare@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFT PATCH 0/4] hwmon: k10temp driver improvements

On 1/16/20 8:47 PM, Ken Moffat wrote:
> On Fri, 17 Jan 2020 at 03:58, Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> Hi Ken,
>>
>> SMBUSMASTER 0 is the CPU, so we have a match with the temperatures.
>>
> OK, thanks for that information.
> 
>>
>> Both Vcore and Icore should be much less when idle, and higher under
>> load. The data from the Super-IO chip suggests that it is a Nuvoton
>> chip. Can you report its first voltage (in0) ? That should roughly
>> match Vcore.
>>
>> All other data looks ok.
>>
>> Thanks,
>> Guenter
> 
> Hi Guenter,
> 
> unfortunately I don't have any report of in0. I'm guessing I need some
> module(s) which did not seem to do anything useful in the past.
> 
> All I have in the 'in' area is
> nct6779-isa-0290
> Adapter: ISA adapter
> Vcore:                  +0.30 V  (min =  +0.00 V, max =  +1.74 V)
> in1:                    +0.00 V  (min =  +0.00 V, max =  +0.00 V)
> AVCC:                   +3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> +3.3V:                  +3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in4:                    +1.90 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in5:                    +0.90 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in6:                    +1.50 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> 3VSB:                   +3.47 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> Vbat:                   +3.26 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in9:                    +0.00 V  (min =  +0.00 V, max =  +0.00 V)
> in10:                   +0.32 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in11:                   +1.06 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in12:                   +1.70 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in13:                   +0.94 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in14:                   +1.84 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> 
> and at that point Vcore was reported as 1.41V (system idle)
> 

Looks like someone configured /etc/sensors3.conf on that system which tells it
to report in0 as Vcore. So there is a very clear mismatch. Can you report
the values seen when the system is under load ?

Thanks,
Guenter