Kernel Panics on Intel Apollo Lake Processors
-
I can confirm that it crashed again even with the updated microcode and the crashes again are consistent this time crashing at sched_pickcpu() almost every single time or on cpu_search_highest() again while the system makes those calls the cores are in acpi_cpu_c1() state so the issue seems to be with cpu states in general
From the data i collected it mostly has to do with when some or most of the cores are in sleep state and the scheduler tries to wake them up to assign some task to them and this is when the panic occurs
I will also try your suggestion to add those flags in my tunables as from what i gathered so far my cores doesn't ever go into C3 they only reach C1 as it is now
-
Enabling the C3 state made the issue way worse that it was before so i guess i will stay with C1 for now although i am getting slightly higher temperatures while only allowing it to reach C1
It seems there is a big issue with the kernel and this generation's processors
Let's hope it will get fixed on the final release of 23.05
-
@sidegr said in Kernel Panics on Intel Apollo Lake Processors:
Let's hope it will get fixed on the final release of 23.05
Perhaps I am wrong with, but could it also be the Intel SpeedStep technology in that case? There were also an interesting thread I was sadly not able to find again
here in the forum, where someone was setting up
in the "tune ables" something based on the
SpeedStep technology and that solved that
problem really good. -
I will try and find the original thread or find something on that on the internet in general, i know for sure that i can disable speed step on my BIOS but if there is another solution i would prefer to not do that
-
I am also wondering if it has anything to do with PowerD that i have enabled and set to Hiadaptive
-
@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
-
@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?
