amdtemp does not find my CPU.

Jeremy Chadwick jdc at
Wed Mar 13 10:23:51 UTC 2013

On Wed, Mar 13, 2013 at 10:17:51AM +0100, Peter Ankerst?l wrote:
> Hi!
> 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
> 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:

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 |
| UNIX Systems Administrator       |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

More information about the freebsd-stable mailing list