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 > r...@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 j...@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | _______________________________________________ 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"
