RELENG_8: amdtemp module and newer CPUs not working. MFC?
Don Lewis
truckman at FreeBSD.org
Mon Feb 25 01:50:29 UTC 2013
On 20 Feb, Jeremy Chadwick wrote:
> On Wed, Feb 20, 2013 at 10:29:05PM -0800, Don Lewis wrote:
>> On 17 Feb, Torfinn Ingolfsen wrote:
>> > Hello,
>> > I'm running FreeBSD 8.3-stable on a machine with an AMD A8-5600K cpu.
>> > tingo at kg-quiet$ uname -a
>> > FreeBSD kg-quiet.kg4.no 8.3-STABLE FreeBSD 8.3-STABLE #2: Fri Jan 4 19:18:15 CET 2013
>> > root at kg-quiet.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64
>> > tingo at kg-quiet$ dmesg | grep CPU | head -1
>> > CPU: AMD A8-5600K APU with Radeon(tm) HD Graphics (3618.02-MHz K8-class CPU)
>> >
>> > Unfortunately, the amdtemp.ko module doesn't work:
>> > tingo at kg-quiet$ kldstat | grep temp
>> > 10 1 0xffffffff8123e000 f0f amdtemp.ko
>> > tingo at kg-quiet$ sysctl dev.amdtemp
>> > sysctl: unknown oid 'dev.amdtemp'
>> >
>> > Based on a thread[1] on the forums, amdtemp.c from -CURRENT work.
>> > But it doesn't compile under FreeBSD 8.3-stable:
>>
>> Updating amdtemp is on my TODO list. It has some issues even on
>> -CURRENT. This is kind of far down my priority list because on most of
>> my AMD machines, I can also get the temperature without amdtemp:
>>
>> % sysctl hw.acpi.thermal.tz0.temperature
>> hw.acpi.thermal.tz0.temperature: 30.0C
>
> There's an implication in your statement here, so I want to clarify for
> readers (as the author of sysutils/bsdhwmon):
>
> acpi_thermal(4) does not necessarily "tie in" to an on-die DTS within
> the CPU. Your motherboards and CPUs (both matter! (e.g. for Intel CPUs,
> see PECI (not a typo)) may offer this tie-in, but such is not the case
> for many people. I tend to find ACPI thermal zones used in laptops and
> very rarely anywhere else.
>
> acpi_thermal(4) may return temperatures from zones that are mapped to
> readings from Super I/O chips or dedicated H/W monitoring ICs (such as
> ones provided by Nuvuton/Winbond, LM, ITE, ADT, etc.). It all depends
> on how the BIOSes ACPI tables are written/what maps to what.
>
> Such ICs DO NOT have anything to do with the on-die DTS which both
> amdtemp(4) and coretemp(4) use -- instead, these chips use external
> thermistors which may be placed anywhere on the motherboard (such as
> under the CPU socket, or wherever the manufacturer chooses (and more
> often than not, does not document)).
>
> My point: under the CPU thermistor != within the CPU DTS. They measure
> two different things, and are not guaranteed to be even remotely
> similar. I can show proof of this (a very large delta between Core i5
> core DTSes and an on-board IT87xxx) if requested.
You are correct. It had been several months since I looked at this and
was misremembering the details.
With amdtemp loaded on one of my systems where it works:
hw.acpi.thermal.tz0.temperature: 34.0C
dev.cpu.0.temperature: 37.2C
dev.cpu.1.temperature: 42.2C
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%parent: hostb3
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.core0.sensor0: 37.5C
dev.amdtemp.0.core0.sensor1: 32.7C
dev.amdtemp.0.core1.sensor0: 42.2C
dev.amdtemp.0.core1.sensor1: 28.2C
When I looked at this previously (on another system with only one DTS),
I noticed that dev.amdtemp.0.core0.sensor0 was giving the same answer as
dev.cpu.0.temperature. I was unaware that amdtemp was responsible for
both sysctl nodes and thought that some other kernel driver was
responsible for dev.cpu.0.temperature, which is why I stopped work on my
amdtemp updates. I see that the amdtemp(4) man page explains the
situation.
Thanks for the heads up about sysutils/bsdhwmon.
More information about the freebsd-stable
mailing list