Date: Wed, 13 Mar 2013 03:23:49 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Peter Ankerst?l <peter@pean.org> Cc: "stable@freebsd.org" <stable@freebsd.org> Subject: Re: amdtemp does not find my CPU. Message-ID: <20130313102349.GA69118@icarus.home.lan> In-Reply-To: <5140443F.3080507@pean.org> References: <5140443F.3080507@pean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 comments: Thread: http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/thread.html#72340 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 complexities. 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. http://www.alcpu.com/CoreTemp/history.html 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@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130313102349.GA69118>