linux-kernel - Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4B0AAA55.3040702@ladisch.de>
Date:	Mon, 23 Nov 2009 16:29:25 +0100
From:	Clemens Ladisch <clemens@...isch.de>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org
Subject: Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h
 CPUs

Jean Delvare wrote:
> On Mon, 23 Nov 2009 08:45:58 +0100, Clemens Ladisch wrote:
>>  Documentation/hwmon/k10temp |   57 ++++++++++++
>>  drivers/hwmon/k10temp.c     |  142 ++++++++++++++++++++++++++++++++
> 
> The name k10temp is a problem, as AMD insists that there is no such
> things as K10 and K11, but instead "family 10h" and "family 11h"
> processors.

K10 was AMD's internal code name, and is widely used in practice.
I'd like to keep this name since it is consistent with the older
k8temp driver.

What name would you propose instead?  "amdfam10temp"?

>> +  control cooling systems. Tctl is a non-physical temperature on an
>> +  arbitrary scale measured in degrees. It does _not_ represent an actual
>> +  physical temperature like die or case temperature. Instead, it specifies
>> +  the processor temperature relative to the point at which the system must
>> +  supply the maximum cooling for the processor's specified maximum case
>> +  temperature and maximum thermal power dissipation.
>> +
>> +The maximum value for Tctl is defined as 70 degrees, so, as a rule of thumb,
>> +this value should not exceed 60 degrees.
> 
> Now I am puzzled. If the temperature value is on an arbitrary scale,
> then the value returned by the driver is essentially fake?

Yes (and it's near enough the absolute value to look plausible).

> Don't we have additional information about the actual maximum Tcase
> value for the different supported models, as we have in coretemp?

For AMD, Tcase is the physical temperature.  Did you mean Tctl?

I'll add Tctl max (= "100% cooling, please") as temp1_max, and there's
a register that contains the Tctl value at which the processor starts
throttling, which could be exported as temp1_crit(_hyst), if I
understand the lm-sensors documentation correctly.

As for your other comments, I'll integrate them in the next version of
the patch.


> If not, then it might be the right time to introduce a new interface
> for relative temperature values. This needs some work, as we must first
> define the interface, then implement support in libsensors and sensors,
> and other monitoring applications, and then convert the affected
> drivers. But apparently we will have to, as major CPU makers are not
> able to implement something as simple as an absolute temperature
> sensor :(

There still is the built-in diode to be read by the motherboard, but the
internal sensor was never intended to be an absolute measurement but
just as a means for controlling the cooling.



Best regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/