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 >> > r...@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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"