Intel pentium 8505 support

[gyrex]

Did you try C3 in the meantime?

Nah, I'm ok with C1 and if it ain't broke...

 

[celemine1gig]

If you are fine with the higher idle consumption, then why not. I was just curious.

 

[gannam]

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:

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.

 

[gyrex]

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.

 

[gannam]

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]​

 

[gyrex]

Out of interest, what changes have you made to the governor? Updating the kernel shouldn't have changed anything...

Microcode 20260811 or later is what you want since it's got fixes to Alder Lake processors, especially C-State issues: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20260811

 

[gannam]

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.

 

[gyrex]

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:

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

 

[gannam]

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:

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.

 

[gannam]

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.)

 

[gannam]

I was not able to install the latest microcode from github. No idea why it failed, but I was able to reinstall 20260227 after downgrading to 20251111. This will at least protect against some critical vulnerabilities.

I believe that I have found a fix for the high clock speeds and constant 80C temperatures. I started to look into what I could adjust with intel's P-States from within linux. HWP is enabled in the BIOS, and when checking, the P-State driver is in active mode, not passive. I've set the HWP preference to balance_power and the governor to powersave. This allows the CPU to boost when needed, but keeps my average clock speed at around 1.7GHz and temps around 45C.

---

---

Here is an overview of what I reviewed concerning capabilities and options, and what I did to get the system working to my requirements. (What I ran is in blue. Please note that I still need to test the persistance systemd service, but am not able to reboot at this time.):

# Check current mode (My system was/is setup with P-State as active)​

cat /sys/devices/system/cpu/intel_pstate/status​

# Outputs: active, passive, or off​

​

# Switch to passive mode (enables available generic CPUFreq governors)​

echo passive | sudo tee /sys/devices/system/cpu/intel_pstate/status​

​

# Switch back to active mode​

echo active | sudo tee /sys/devices/system/cpu/intel_pstate/status​

---

Despite being named powersave, the Intel P-State powersave governor is dynamic - it ramps up when needed. The difference from performance is how aggressively it ramps up and how quickly it drops back down.

# powersave governor - dynamically adjusts, prioritizes power​

echo powersave | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor​

​

# performance governor - prefers high frequencies​

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor​

---

Hardware-Controlled P-States (HWP)

# Check if HWP is available​

cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences​

# Example output: default performance balance_performance balance_power power​

​

# Set HWP preference (affects how hardware makes frequency decisions)​

# Apply to all CPUs​

echo balance_power | tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference​

​

# Options:​

# default - hardware chooses​

# performance - maximize performance​

# balance_performance - lean toward performance​

# balance_power - lean toward power saving​

# power - maximize power saving​

​

---

Persistent Configuration: Systemd Service

# Create a script to apply P-State settings at boot​

tee /usr/local/bin/intel-pstate-tune.sh << 'EOF'​

​

# Set powersave governor with balanced_power HWP preference​

for governor in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do​

[ -e "$governor" ] || continue​

echo powersave > "$governor"​

done​

for cpu in /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference; do​

[ -e "$cpu" ] || continue​

echo balance_power > "$cpu"​

done​

EOF​

​

​

#Give the file executable permissions​

chmod +x /usr/local/bin/intel-pstate-tune.sh​

# Create systemd service​

tee /etc/systemd/system/intel-pstate-tune.service << 'EOF'​

​

[Unit]​

Description=Intel P-State Tuning​

After=multi-user.target​

​

[Service]​

Type=oneshot​

ExecStart=/usr/local/bin/intel-pstate-tune.sh​

RemainAfterExit=yes​

​

[Install]​

WantedBy=multi-user.target​

EOF​

​

systemctl daemon-reload​

systemctl enable intel-pstate-tune​

systemctl start intel-pstate-tune​