amdtemp does not find my CPU.
jdc at koitsu.org
Wed Mar 13 10:23:51 UTC 2013
On Wed, Mar 13, 2013 at 10:17:51AM +0100, Peter Ankerst?l wrote:
> Im running FreeBSD 9.1 on a AMD APU machine:
> CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1699.36-MHz K8-class CPU)
> FreeBSD 9.1-RELEASE-p1 #0 r243379M: Fri Mar 8 23:16:44 CET 2013
> root at pean.org:/usr/obj/usr/src/sys/GENERIC
> I try to use amdtemp(4) to read the temperature of this CPU but it
> doesnt seem to detect the CPU. The manual states that it should
> support K8-class.
> The amdtemp.c isnt huge so maybe it is very simple to make it work?
A similar discussion happened last month about FreeBSD 8.x and the
amdtemp(4) driver and what models it supports. See thread and my
First post: http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072340.html
Points I'm trying to get across, as someone who has no familiarity with
the amdtemp(4) driver/code, but does have quite a lot of familiarity
with H/W monitoring chipsets:
1. Do not assume it will be simple to "make it work" simply because the
driver you see is ~13KBytes -- the size has no bearing on technical
2. Support for different CPUs have to be added gradually and carefully,
as hardware vendors change methods/models behaviour of the DTSes and
surrounding bits more often than you might think.
Consider what would happen if support was added which in turn
broke/caused issues for other CPU models (either newer or older); the
end result consists of end-users screaming about the breakage, and
people having to rush to provide a fix.
You might want to look at the "Core Temp" utility for Windows, for
example, where it has to be updated periodically to add support for some
models of CPUs; be sure to note all the "Fix:" items too.
3. Low-level technical documentation of behaviour per CPU model is
sometimes not made available publicly by the vendor until after N number
of years. This requires the person adding support to reverse-engineer
existing programs out there (ex. Linux, etc.) that provide such. This
takes time, and can often be more error-prone than real documentation.
And don't forget about CPU bugs/errata too.
4. Do not forget amdtemp(4) is kernel-land: the last thing you want to
do is screw it up (think panic). Userland is often more forgiving,
depending what all you're interfacing with on the kernel side (ex. a
badly-formed ioctl from userland could cause a panic too).
| Jeremy Chadwick jdc at koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-stable