Upgrade from 2.2 RC to 2.2 Final… Kernel trap error 12 on boot
-
The fact the last thing that it shows is gpioapu, and that it changed between such a short period and one other person reported same, makes me pretty sure something in gpioapu caused that to break on hardware that returns unusually for smbios.system.product.
https://redmine.pfsense.org/issues/4363
Hopefully get that addressed for 2.2.1. -
Same issue with my FWA7204.
As a workaround, is there a way to disable GPIOAPU with a kernel option at boot?
Any other idea for a workaround?
If not, 2.2 is not an option for me until this problem is resolved. Right now it look I have to go back to 2.1.5.
Bummer! :'(
-
A workaround on the firebox was to enable ACPI in the BIOS. You might be able to do that.
https://forum.pfsense.org/index.php?topic=87542.msg484384#msg484384Steve
-
Try this at a loader prompt:
set hint.gpioapu.0.disabled=1And then add it to /boot/loader.conf.local
hint.gpioapu.0.disabled=1 -
A workaround on the firebox was to enable ACPI in the BIOS. You might be able to do that.
https://forum.pfsense.org/index.php?topic=87542.msg484384#msg484384Steve
Thanks for the tip, but no ACPI configuration available in BIOS configuration.
-
Try this at a loader prompt:
set hint.gpioapu.0.disabled=1And then add it to /boot/loader.conf.local
hint.gpioapu.0.disabled=1I gave it a try, but no effect.
Thank you.
-
Did it appear to actually disable the gpioapu driver? It no longer appears in the boot messages? Can you post a copy of that?
Did you at any time see a message relating to 'smbios.system.product' ?
Just to confirm this is your box: http://ibt.ca/v2/items/fwa7204/index.html
Steve
-
I missed the notifications on this thread.
I will try the 'set hint.gpioapu.0.disabled=1' tonight on my Axiomtek server and see if it allows it to work on my system.
If it doesn't work I will try to figure out how to get a snapshot full install (assuming that is an option) to test that has the latest fix that was mentioned in the redmine issue.
https://redmine.pfsense.org/issues/4363
" Updated by Ermal Luçi 6 days ago
Status changed from New to Feedback
gpioapu corrected to avoid comparison with NULL in strncmp." -
If it doesn't try this:
https://forum.pfsense.org/index.php?topic=88363.msg487877#msg487877Steve
-
This didn't help…
set hint.gpioapu.0.disabled=1The setting below did. I was able to boot the 2.2 i386 full install final CD.
set smbios.system.product="XPS"I assume if I put that in the 2.1.5 /boot/loader.conf.local file it will stay in the transition on the upgrade to the 2.2.
Thanks for the info.
-
Doesn't have to be XPS by the way just something other than APU or null.
Steve
-
Did it appear to actually disable the gpioapu driver? It no longer appears in the boot messages? Can you post a copy of that?
Did you at any time see a message relating to 'smbios.system.product' ?
Just to confirm this is your box: http://ibt.ca/v2/items/fwa7204/index.html
Steve
Hi, sorry for the delay, but i had other priorities.
There are no references to "smbios.system.product" in my boot log.
yes http://ibt.ca/v2/items/fwa7204/index.html is my box.
Now for the good news, I tried
set smbios.system.product="XPS"
And it looked like it does the trick. I was able to do a complete boot on the upgraded version installed on my box.
This is a good workaround for that problem. According to this post:
https://redmine.pfsense.org/issues/4363
a real solution should be available in version 2.2.1.
Thanks you again for the replies and for the good work.
-
Great, thanks for confirming that. :)
Should be fixed in 2.2.1 as you say.Steve
-
The only behavior that should be changed by that action is whether or not the reset button utility is run.
Try running /usr/local/sbin/APUresetbtn to see if that triggers the panic.
If you're brave. :-)
-
There are 2.2.1 snapshots available now, if someone with an affected system can test and report back here in this thread or on its bug ticket:
https://redmine.pfsense.org/issues/4363I'd like to confirm that's definitely good. It should be fixed, but we don't have any affected systems internally to fully verify.
-
2.2.1 27th Feb snap boots fine on my box in a configuration that previously threw this error.
Steve
