A Fix for Temperature readouts on apu2b4 boards and reboot bug workaround
-
top stuff. :)
-
@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.
-
no problems, attached on my first post :)
-
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.
-
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)?
-
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.
-
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
-
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.
-
Actually - there is already a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202629
-
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.
-
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.
-
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.
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.
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.
