A Fix for Temperature readouts on apu2b4 boards and reboot bug workaround

A Former User

do this at your own risk, if you dont understand kernel compiles etc, either learn a bit by googling, or wait till a fix is implemented in freebsd/pfsense

Quite a simple fix by me for apu2b4 boards, by simply adding the device ID To amdtemp.c and recompiling the kernel module you can now have temperatures in pfsense.

as such:
In your separate FreeBSD VM/BOX with relevant version of FreeBSD installed (10.1 for 2.2.6, 10.3 for 2.3) with compile tools and kernel code

Go to /usr/src/sys/dev/amdtemp

vi amdtemp.c (or whatever your text editor of choice is you've got installed)

make the following changes to make it look like this

#define VENDORID_AMD 0x1022
#define DEVICEID_AMD_MISC0F 0x1103
#define DEVICEID_AMD_MISC10 0x1203
#define DEVICEID_AMD_MISC11 0x1303
#define DEVICEID_AMD_MISC12 0x1403
#define DEVICEID_AMD_MISC14 0x1703
#define DEVICEID_AMD_MISC15 0x1603
#define DEVICEID_AMD_MISC16 0x1533
#define DEVICEID_AMD_MISC16_X3 0x1583
#define DEVICEID_AMD_MISC17 0x141d

static struct amdtemp_product {
uint16_t amdtemp_vendorid;
uint16_t amdtemp_deviceid;
} amdtemp_products[] = {
{ VENDORID_AMD, DEVICEID_AMD_MISC0F },
{ VENDORID_AMD, DEVICEID_AMD_MISC10 },
{ VENDORID_AMD, DEVICEID_AMD_MISC11 },
{ VENDORID_AMD, DEVICEID_AMD_MISC12 },
{ VENDORID_AMD, DEVICEID_AMD_MISC14 },
{ VENDORID_AMD, DEVICEID_AMD_MISC15 },
{ VENDORID_AMD, DEVICEID_AMD_MISC16 },
{ VENDORID_AMD, DEVICEID_AMD_MISC16_X3 },
{ VENDORID_AMD, DEVICEID_AMD_MISC17 },
{ 0, 0 }

(leaving everything else of course - all I have changed here is we added #define DEVICEID_AMD_MISC16_X3 0x1583 and { VENDORID_AMD, DEVICEID_AMD_MISC16_X3 },)

use scp or whatever takes your fancy to get it across to your pfsense box, copy it to /boot/modules (overwriting the other amdtemp.ko) and enable it in the usual manner, or copy it wherever you like and run it however you like :)

as for reboot - I found the following workarounds have allowed me to reboot the box without lockups …
in system tunables on the pfsense interface create the following two tunables.

hw.acpi.disable_on_reboot 1
hw.acpi.handle_reboot 0

oh, also, if powerd is whining at you in your console with err 6's

hint.p4tcc.0.disabled="1"
hint.acpi_throttle.0.disabled="1"

^^ put this in your loader.conf.

thanks and enjoy.

** use at your own risk the code and attached files. **
edit: attached as a zip file is the .ko for anyone having problems compiling, but you're using a firewall distro, you really should try compiling this code yourself for security sake, or even better waiting for the patch to be implemented in to freebsd.

amdtemp.ko.zip

mrpink

Could you please share your amdtemp.ko module, so I do not need to compile it also.

Thanks :)

A Former User

@mrpink:

Could you please share your amdtemp.ko module, so I do not need to compile it also.

Thanks :)

use at own risk, it's compiled for 2.2.6.

edit removed link - get it from first post instead

mrpink

Thank you, it is working on my testsystem with pfSense 2.3 :)

apu2b4_amdtemp.png_thumb

A Former User

top stuff. :)

Guest

@yodawg
Would you please put it (the .ko file) in a .zip packet and insert it here as a attachement?
It would be better to download for us all, because the link you where sending is a single download file only!

click on replay
drop a line of words
click on attachement
upload the .ko.zip file

If you will find the time to realize it, I would say thank you.

A Former User

no problems, attached on my first post :)

jimp

Those changes should be submitted to FreeBSD so they can make their way back into pfSense from upstream. Running binaries compiled from an external source (especially kernel modules on a firewall!) is not a good idea.

A Former User

@jimp:

Those changes should be submitted to FreeBSD so they can make their way back into pfSense from upstream. Running binaries compiled from an external source (especially kernel modules on a firewall!) is not a good idea.

I agree 110% - that's why I told everyone how to do it in code because I personally wouldn't dream of running something outside of a distro…

Submitted as a 10.1-release bugfix, will they merge it to 10.3 when it comes out? (and 10.2)?

jimp

It's probably too late for 10.3 since it's in prerelease already.

Opening a bug report and attaching the patch is a good start. You might check 11-CURRENT code to be sure it hasn't already been done there.

phil.davis

Not a pfSense issue, but surely in FreeBSD if a bug fix is done in some older version n.n then the fix has to be done in all versions later than n.n (that are not already fixed…), otherwise there will be regressions when people move from, for example, 10.1 to 10.2 to 10.3. Even if it is also fixed in master 11 development, it seems very odd to me that the fix would have been back-ported to 10.1 but not to 10.2 and 10.3

David_W

@phil.davis:

Not a pfSense issue, but surely in FreeBSD if a bug fix is done in some older version n.n then the fix has to be done in all versions later than n.n (that are not already fixed…), otherwise there will be regressions when people move from, for example, 10.1 to 10.2 to 10.3. Even if it is also fixed in master 11 development, it seems very odd to me that the fix would have been back-ported to 10.1 but not to 10.2 and 10.3

If a proposed change in the FreeBSD base system relates to the latest code, it must be made in head first, which is the current development version (11-CURRENT at the time of writing).

Changes can be MFC (Merged From Current) to the stable branches once they have been in head for an appropriate time period. Usually a commit proposed for MFC contains an "MFC after:" in the commit message. MFC is only allowed if the change doesn't change any Kernel Binary Interfaces and, if the relevant stable branch is in code slush or code freeze, release engineering permission is given. Even if there is no KBI change, a change might be felt to be inappropriate for MFC.

MFC is typically to the most recent stable branch (stable/10 at the time of writing, which is 10-STABLE), though can be to any number of stable branches at the committer's discretion. MFCs are only usually made to a stable branch for which there is some possibility of a future release. MFCs to end of life branches are allowed but are rare.

Changes can only be merged to an existing releng branch (release engineering) with release engineering permission. Once the release has shipped, this permission is only normally given if the change is a security fix or a significant enough bug fix to justify an errata notice. If the releng branch relates to a version at Release Candidate stage, release engineering might allow permission for other bug fixes.

Any change to fix a deficiency in 10.1 will have to be submitted in a form suitable for head (i.e. 11-CURRENT). The change could subsequently be MFCed to 10-STABLE, but the stable/10 branch is currently in code freeze prior to the branching of releng/10.3 for the upcoming 10.3-RELEASE. The kind of fix mentioned in this thread may well not get release engineering approval for merging during the code freeze and is very unlikely to be approved for merging to an existing releng branch. If so, the earliest FreeBSD release this fix could appear in is 11.0 or, if there is to be a 10.4 release, 10.4.

As jimp says, the first step is for the original poster to open a FreeBSD bug report, attaching the patch.

a_wein

Actually - there is already a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202629

phil.davis

The bit that had me confused was:

Submitted as a 10.1-release bugfix, will they merge it to 10.3 when it comes out? (and 10.2)?

It surprised me that this would be something to go in the 10.1 branch - I would have expected it to go in 11-CURRENT and then back-port to the 10-STABLE branch so it could appear in whatever 10.* it manged to get into - as David_W has explained.

David_W

@a_wein:

Actually - there is already a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202629

That's a good start. It would help if someone checked out FreeBSD head, applied the patch, built and tested the resulting code, then submitted the patch (svn diff preferred) to the bug, noting the details of the board that it fixes. The more work that is done for a committer, the more likely the fix is to be committed.

A Former User

@phil.davis:

The bit that had me confused was:

Submitted as a 10.1-release bugfix, will they merge it to 10.3 when it comes out? (and 10.2)?

It surprised me that this would be something to go in the 10.1 branch - I would have expected it to go in 11-CURRENT and then back-port to the 10-STABLE branch so it could appear in whatever 10.* it manged to get into - as David_W has explained.

I was confused as to where to actually submit it, I patched it on 10.1 code - now it's been made clear I should submit it against SVN / Head if I actually want it to be accepted.

@a_wein:

Actually - there is already a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202629

I submitted my own bug report also under puma as it is the chip family, again .. easily fixed .. I can even put the tablet code in if need be.

@David_W:

@a_wein:

Actually - there is already a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202629

That's a good start. It would help if someone checked out FreeBSD head, applied the patch, built and tested the resulting code, then submitted the patch (svn diff preferred) to the bug, noting the details of the board that it fixes. The more work that is done for a committer, the more likely the fix is to be committed.

I will do this tonight or tomorrow depending on the free time I get.

Thanks for pointing a few things out, I've had little to do with coding experience and even less with actually submitting something to an open source project (then again the patch isn't much, it's only a couple of id's).

Initially I only posted here to help the community and those who wanted to patch their temps because these things run hot and I know when my room where the apu sits gets up to 40c + in the day it's nice to know what temp it's running at. Thanks.