Kernel Panics on Intel Apollo Lake Processors
-
@sidegr said in Kernel Panics on Intel Apollo Lake Processors:
I am also wondering if it has anything to do with PowerD that i have enabled and set to Hiadaptive
-
The speedstep/speedshift difference only affects p-states not c-states just for clarity. But you might find speedshift is enabled on a system where speedstep wasn't.
-
So i suppose PowerD doesnt really affect my issue, anyway the current status is that since i have disabled monitor mwait in BIOS and also included some parameters in the loader.conf file to update the cpu microcode on boot the panics significantly reduced in frequency but they are still happening a bit less than ones a day or so
(Edit) Those are the lines i have added to loader.conf
cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin"And this is the output i get from dmesg
CPU microcode: updated from 0x3c to 0x48 -
You should check to see if Speedshift is attaching at boot though. It's enabled by default in 23.01 so it could be doing a bunch of CPU speed scaling that wouldn't have happened in older versions.
-
I see nothing related to speedshift in dmesg the only thing I see is in regards to speedstep and it’s this line
est0: <Enhanced SpeedStep Frequency Control> on cpu0However it only shows up for core 0 some posts I have seen online it shows up for all cores that the cpu exposes to the kernel like 0, 1, 2 and 3 in my case
Not sure if that could be an issue as well
-
This post is deleted! -
That is probably fine. Speedstep can only set the P-states all the same anyway so it only really needs to use core 0. Speedshift can set each core individually and does so at much faster rates. But your CPU doesn't support it so not a problem.
-
Oh ok then it makes sense for speedshift to not get attached at boot
Well for now it seems that the only solution is to just keep monitor mwait off on the BIOS side and only let the cores enter at most a C1 state cause anything more than C1 is extremely unstable, it would be nice to see that fixed tough, also it might have to do with the fact the freebsd 14 is still in a fairly early beta stage and might have issues
-
Some times i wish that a 1100 was enough but with a 1Gbps internet connection it won't do and the 2100 is way over budget and an overkill for a home user. Also where i live, they resell the 1100 for 500 euro for a 190 euro device :P
-
Today: 1 dollar = 0,93 €
$189 = 174 €Netgate SG1100 for around ~249 € plus shipping fee
Netgate SG2100 for around ~449 € plus shipping fee -
Yeah see those are prices from a german reseller, the official reseller where i live sells the 1100 for 500 euros :P And i am not sure even if i ordered it from another country i would probably get import charges on top of whatever the price is and who knows how much those would be
Nonetheless the SG1100 is not enough for a gigabit internet connection and the 2100 is out of my budget this is why i went for the ZimaBoard which supposedly supported pfSense they even have it on their website although it has caused me nothing but issues since i installed it.. First the NICs which as i mentioned before i was expecting some issues but my general concensus was that dissabling HW checksum offload would fix most of em but for me it was straight up kernel panics every like 20-30 mins
Then i fixed that by manually adding the realtek kmod driver and now i have the cpu sleep state issues
-
My old box was working like a charm but since it was a thin client pc it only had one integrated nic and i had to use a usb 3.0 to Gbe adapter as my second NIC which was bottlenecking my connection to around 350Mbps since i upgraded to Gbps so i had to change it
Now don't get me wrong the ZimaBoard is a pretty nice SBC and very capable but in the current state of things it is not the best option for someone that intends to use it as a home firewall appliance, the only thing that i was able to run hassle free was Sophos XG Home which is extremely heavy for the cpu and has also a 6GB RAM limit if you don't buy a licence which makes the other 2 on my board useless plus all my experience and setup knowledge was always on pfSense
-
Hello again, i can now confirm that i did not have any kernel panics since my last post
I did not do anything in particular i have just switched back the max C state to C1 and i kept the microcode update process enabled in the loader.conf
I have now just updated to the 23.05 Release and lets hope it will continue to be stable :P
-
Also, how come that 23.05 is in "RELEASE" but it still shows up as the "next stable release" and not the "current stable release" in the updates menu?
-
@sidegr said in Kernel Panics on Intel Apollo Lake Processors:
Also, how come that 23.05 is in "RELEASE" but it still shows up as the "next stable release" and not the "current stable release" in the updates menu?
It was quick changed for a moment to Release and then
it was switched back, but the image is the same as it
was confirmed by @stephenw10 in another thread. -
You should see the release as current stable now.
