Intel pentium 8505 support

Changing the BIOS settings don't make much of a difference since they're overwritten by the kernel. The changes to P & CSTATES and need to be made in GRUB for them to take effect and this can be confirmed by running lscpu.

My 8505 is rock solid (low ~30C temps and uptime over a month) after changing GRUB to:

Code:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1 processor.max_cstate=1 pcie_aspm=off"

and loading the latest Intel Microcode (20260210) from github.
Everything was running fine, with my idle in the low 40's (okay for ambient being 25-28C). It looks like a recent update introduced the previous stability issues on Friday. (Looked at logs and the privileged LXC wasn't running when it crashed.)

I verified that the latest microcode was installed and edited the GRUB line as you had indicated. Everything seemed to be running as it was before...until I installed the latest kernel. (7.0.14-20-pve (2026-09-24T10:43Z)) The CPU is now idling at 76-80C with the cores cycling between 3GHz and 4GHz with 400MHz core clocks sporadically being used for a second or two. The system appears to be stable, but I've only had it up for a few hours. My previous uptime was over 70 days. I've tried adjusting the governor, but no change. If I have time tonight I'll try booting with the previous kernel to confirm whether or not the behavior is tied to the newest kernel.
 
Everything was running fine, with my idle in the low 40's (okay for ambient being 25-28C). It looks like a recent update introduced the previous stability issues on Friday. (Looked at logs and the privileged LXC wasn't running when it crashed.)

I verified that the latest microcode was installed and edited the GRUB line as you had indicated. Everything seemed to be running as it was before...until I installed the latest kernel. (7.0.14-20-pve (2026-09-24T10:43Z)) The CPU is now idling at 76-80C with the cores cycling between 3GHz and 4GHz with 400MHz core clocks sporadically being used for a second or two. The system appears to be stable, but I've only had it up for a few hours. My previous uptime was over 70 days. I've tried adjusting the governor, but no change. If I have time tonight I'll try booting with the previous kernel to confirm whether or not the behavior is tied to the newest kernel.
Did you run update-grub after modifying the grub config? Also, are you using the microcode package from the debian repo? If so, it's quite old and misses a lot of fixes for Alder Lake architecture. Check dmesg and see which microcode version is loaded at boot (search for microcode). You'll need to download the latest microcode package from github and install the dpkg manually.
 
Did you run update-grub after modifying the grub config? Also, are you using the microcode package from the debian repo? If so, it's quite old and misses a lot of fixes for Alder Lake architecture. Check dmesg and see which microcode version is loaded at boot (search for microcode). You'll need to download the latest microcode package from github and install the dpkg manually.
update-grub was run after making changes to the grub config file.

It looks like I pulled microcode 20260227 instead of 20260210.
root@H2S:~# dmesg | grep microcode​
[ 0.491702] microcode: Current revision: 0x0000043b​
[ 0.491706] microcode: Updated early from: 0x0000042c​
root@H2S:~#​
root@H2S:~#​
root@H2S:~# apt list -a intel-microcode​
intel-microcode/now 3.20260227.1 amd64 [installed,local]​
 
There were only 2 governors available, performance and powersave. The default is performance. I changed it to powersave to see if there was any difference, but changed it back to performance.

I'll have to dig a bit more concerning how to install the microcode from a github download. (looked for a bit, but can't find anything useful) I ran the community script, which pulls from Debian's "non-free-firmware/i/intel-microcode" which is already a *.deb file.
 
The performance governor might be the reason why your cores are running at higher frequencies and therefore hot. FWIW I'm using the powersave governor and my cores run very cool with undetectable performance penalty.

This is what I used to run the latest microcode from Intel's github repo:

Code:
cd /tmp
git clone --depth 1 https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git
cd Intel-Linux-Processor-Microcode-Data-Files

# Copy the microcode files
cp -v intel-ucode/* /lib/firmware/intel-ucode/

# Update initramfs so the new microcode is loaded early at boot
update-initramfs -u -k all
 
The performance governor might be the reason why your cores are running at higher frequencies and therefore hot. FWIW I'm using the powersave governor and my cores run very cool with undetectable performance penalty.

This is what I used to run the latest microcode from Intel's github repo:

Code:
cd /tmp
git clone --depth 1 https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git
cd Intel-Linux-Processor-Microcode-Data-Files

# Copy the microcode files
cp -v intel-ucode/* /lib/firmware/intel-ucode/

# Update initramfs so the new microcode is loaded early at boot
update-initramfs -u -k all
Thank you for the information. I ran into an issue when running the listed commands. (No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.) I was able to resolve this by running "proxmox-boot-tool init" after confirming that "proxmox-boot-uuids" didn't exist in /etc/kernel/.

Unfortunately, the microcode wasn't installed. I've tried rolling back to "3.20251111.1~deb13u1" and running the commands provided again, but no luck...still on 20251111. Currently at a loss, but I'm searching for a solution.
 
Curious as to if I should delete the contents of "/lib/firmware/intel-ucode" and then copy the new microcode files before attempting to update initramfs again. (Trying to avoid boot issues by doing something stupid, so I'm trying to see if this is safe before proceeding.)