Date: Sun, 24 Feb 2013 17:40:40 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: jdc@koitsu.org Cc: freebsd-stable@FreeBSD.org, torfinn.ingolfsen@getmail.no Subject: Re: RELENG_8: amdtemp module and newer CPUs not working. MFC? Message-ID: <201302250140.r1P1eeuS017218@gw.catspoiler.org> In-Reply-To: <20130221072339.GA74725@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@kg-quiet.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 >> > tingo@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@kg-quiet$ kldstat | grep temp >> > 10 1 0xffffffff8123e000 f0f amdtemp.ko >> > tingo@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201302250140.r1P1eeuS017218>