cpu läuft auf niedrigster Geschwindigkeit

[thomashoellerer]

Hallo!
vielleicht hat hier wer eine gute Idee ....
Seit kurzer Zeit laufen bei mir bei 2 Servern mit Proxmox 9.2 die CPU auf niedrigster Geschwindigkeit (800MHz) -- sollten eigentlich bis 3,4GHz können und sind auch lange gut gelaufen.
Ich denke es war mit einem Kernel-Update. Es wurde nichts am BIOS oder so verstellt -- nur ein Neustart ...
asus P13R-EMainboard mit XEON Prozessor.
Hat jemand das schn gehabt oder eine Idee dazu?

 

[Impact]

Was sagt das?

apt install -yU linux-cpupower
cpupower frequency-info

 

[Bu66as]

Hm, 800 MHz fest klingt entweder nach Treiber/Governor oder danach, dass die CPU von außen runtergedrückt wird (PROCHOT, Power-Capping). Schau mal was cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver und cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor sagen, und poste am besten noch die Ausgabe von cpupower frequency-info (Paket linux-cpupower). Da sieht man auch, ob die Hardware-Limits auf einmal anders gemeldet werden.

Um rauszufinden, ob der Kernel schuld ist, einfach mal den vorherigen Kernel booten:

proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin <alte-version> --next-boot

Wenn es mit dem alten Kernel wieder auf 3,4 GHz hochgeht, ist der Kernel der Schuldige. Bleibt es bei 800 MHz, würd ich eher beim Board suchen. Falls du da ein BMC/IPMI hast, schau mal nach Power-Limits oder Temperatur-Events im Log. Welche Kernel-Version läuft gerade (uname -r) und welcher Xeon genau?

 

[thomashoellerer]

Was sagt das?

apt install -yU linux-cpupower
cpupower frequency-info

analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.30 GHz, 3.20 GHz, 3.10 GHz, 3.00 GHz, 2.90 GHz, 2.80 GHz, 2.70 GHz, 2.60 GHz, 2.50 GHz, 2.40 GHz, 2.30 GHz, 2.20 GHz, 2.10 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 1.20 GHz and 1.90 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: 1.90 GHz (asserted by call to hardware)
boost state support:
Supported: no
Active: no

aber /proc/cpuinfo sagt immer um die 800MHz

 

[Bu66as]

Interessant, da passt was nicht zusammen. Auf einem aktuellen Xeon würd ich eigentlich intel_pstate als Treiber erwarten, nicht acpi-cpufreq. Deine Ausgabe hört nach den Governors auf, poste mal den Rest mit "current policy", "current CPU frequency" und "boost state support". Kann sein, dass die Firmware per ACPI ein Limit vorgibt. Schau mal, was das hier ausgibt:

cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
cat /proc/cmdline
dmesg | grep -i -E "pstate|throttl|prochot"
grep . /sys/devices/system/cpu/cpu0/thermal_throttle/*

Wenn die Throttle-Counter hochzählen oder PROCHOT im dmesg steht, kommt das Signal vom Board, also von einem Temperatursensor, vom Netzteil oder von einem BMC-Power-Limit. Dann bringt am Kernel rumschrauben nix. Mit turbostat (im selben Paket) siehst du in der Spalte Bzy_MHz, mit welchem Takt die Kerne wirklich laufen. Hast du den Test mit dem alten Kernel schon gemacht?

 

[jim_os]

Moin

@thomashoellerer Sicher das Du Governor nicht auf powersave eingestellt hast. @Bu66as hatte ja bereits gefragt was Dir dabei

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

angezeigt wird? Oder habe ich das hier ggf. übersehen ...

aber /proc/cpuinfo sagt immer um die 800MHz

"Immer" ist relativ. Was wird Dir dann dabei als "Live-Werte" angezeigt:

watch -n 1 "grep 'cpu MHz' /proc/cpuinfo"

Bsp. - in dem Fall steht bei mir Governor auf "powersave".



Unter Last sollten da dann die Werte eigentlich auch hochgehen. Bsp.



VG Jim

 

[thomashoellerer]

Interessant, da passt was nicht zusammen. Auf einem aktuellen Xeon würd ich eigentlich intel_pstate als Treiber erwarten, nicht acpi-cpufreq. Deine Ausgabe hört nach den Governors auf, poste mal den Rest mit "current policy", "current CPU frequency" und "boost state support". Kann sein, dass die Firmware per ACPI ein Limit vorgibt. Schau mal, was das hier ausgibt:

cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
cat /proc/cmdline
dmesg | grep -i -E "pstate|throttl|prochot"
grep . /sys/devices/system/cpu/cpu0/thermal_throttle/*

Wenn die Throttle-Counter hochzählen oder PROCHOT im dmesg steht, kommt das Signal vom Board, also von einem Temperatursensor, vom Netzteil oder von einem BMC-Power-Limit. Dann bringt am Kernel rumschrauben nix. Mit turbostat (im selben Paket) siehst du in der Spalte Bzy_MHz, mit welchem Takt die Kerne wirklich laufen. Hast du den Test mit dem alten Kernel schon gemacht?

Hab ich schon alles durch -- intel_pstate ist gerade deaktiviert (mit boot-parameter), weil acpi hin und wieder einen Kern kurz auf 1900 schalten und gefühlt minimal schneller ist.

 

[thomashoellerer]

Moin

@thomashoellerer Sicher das Du Governor nicht auf powersave eingestellt hast. @Bu66as hatte ja bereits gefragt was Dir dabei


angezeigt wird? Oder habe ich das hier ggf. übersehen ...


"Immer" ist relativ. Was wird Dir dann dabei als "Live-Werte" angezeigt:

watch -n 1 "grep 'cpu MHz' /proc/cpuinfo"

Bsp. - in dem Fall steht bei mir Governor auf "powersave".

View attachment 100491

Unter Last sollten da dann die Werte eigentlich auch hochgehen. Bsp.

View attachment 100493

VG Jim

genau das macht er nicht .... zB laufen 2 VMs mit je 4 Kernen (insgesamt 8) auf 100% und die CPU bleibt gemütlich auf 800; powersave & performance probiert - immer 800MHz

 

[jim_os]

OK dann bin ich auch überfragt. Wenn bei der Anzeige per

watch -n 1 "grep 'cpu MHz' /proc/cpuinfo"

alle Kerne konstant bei ~ 800MHz stehen bleiben und unter Last die Werte dann nicht hochgehen, ist das schon echt komisch. Bei meiner Proxmox Kiste hier mit aktuellen PVE Kernel ist das halt nicht der Fall, aber in der steckt auch kein Asus Motherboard mit einer XEON CPU.

BTW: Ich habe zwar keine Ahnung was Du da für VMs am laufen hast, aber warum laufen 2 VM

laufen 2 VMs mit je 4 Kernen (insgesamt 8) auf 100%

da auf 100%. Das dürfte doch auch nicht so wirklich normal sein. Hier läuft z.B. eine Home Assistant und eine OMV VM mit je zwei CPU, die jeweils eine CPU-Auslastung von unter 10 % haben. Die CPU Gesamt-Auslastung von PVE sieht dann z.B. so aus



und ja mir wird dann natürlich auch immer nur ein MHz-Wert von 800 bis 900 angezeigt, weil die beiden VMs eben so gut wie keine CPU-Last erzeugen.

Aber wie schon gesagt weiß ich auch nicht was da bei Dir wie läuft und wie es vorher

sind auch lange gut gelaufen.

dann lief. Daher muss ich hier dann leider auch passen und hoffe das hier ein anderer User ggf. noch eine Lösung für Dich hat.

VG Jim

 

[Bu66as]

Die 1,2 bis 1,9 GHz in deiner "current policy" sind auffällig. Die Hardware-Grenzen werden mit 800 MHz bis 3,4 GHz gemeldet, trotzdem lässt die Policy nur 1,9 GHz zu. Bei acpi-cpufreq kommt so eine Grenze von der Firmware per ACPI. Dass die Kerne unter Volllast und mit "performance" trotzdem fest auf 800 MHz bleiben, ist typisch, wenn die CPU von außen auf den niedrigsten Takt gedrückt wird (PROCHOT oder ein Power-Limit vom BMC). Der Kernel will 1,9 GHz, die Hardware gibt sie nicht. Poste bitte die Werte von bios_limit, den thermal_throttle-Countern und dem dmesg-grep. Genau da sieht man, wer bremst.

Merkwürdig ist, dass beide Server betroffen sind. Ein kaputtes Netzteil oder verstopfter Kühler ist unwahrscheinlich, eher etwas, das auf beiden eingespielt wurde. Neben dem Kernel kommt auch ein Update von intel-microcode in Frage. Schau mal in /var/log/apt/history.log, ob das beim selben Update mitgekommen ist. Mit dem Boot-Parameter dis_ucode_ldr starten, dann wird das Microcode-Update nicht geladen. Mit dem alten Kernel per proxmox-boot-tool kernel pin versuch auch noch. Wenn es mit beidem bei 800 MHz bleibt, würde ich im BMC nach Power-Capping und dem Event-Log schauen.

 

[thomashoellerer]

Die 1,2 bis 1,9 GHz in deiner "current policy" sind auffällig. Die Hardware-Grenzen werden mit 800 MHz bis 3,4 GHz gemeldet, trotzdem lässt die Policy nur 1,9 GHz zu. Bei acpi-cpufreq kommt so eine Grenze von der Firmware per ACPI. Dass die Kerne unter Volllast und mit "performance" trotzdem fest auf 800 MHz bleiben, ist typisch, wenn die CPU von außen auf den niedrigsten Takt gedrückt wird (PROCHOT oder ein Power-Limit vom BMC). Der Kernel will 1,9 GHz, die Hardware gibt sie nicht. Poste bitte die Werte von bios_limit, den thermal_throttle-Countern und dem dmesg-grep. Genau da sieht man, wer bremst.

Merkwürdig ist, dass beide Server betroffen sind. Ein kaputtes Netzteil oder verstopfter Kühler ist unwahrscheinlich, eher etwas, das auf beiden eingespielt wurde. Neben dem Kernel kommt auch ein Update von intel-microcode in Frage. Schau mal in /var/log/apt/history.log, ob das beim selben Update mitgekommen ist. Mit dem Boot-Parameter dis_ucode_ldr starten, dann wird das Microcode-Update nicht geladen. Mit dem alten Kernel per proxmox-boot-tool kernel pin versuch auch noch. Wenn es mit beidem bei 800 MHz bleibt, würde ich im BMC nach Power-Capping und dem Event-Log schauen.

die Datei bios_limit gibts nicht
hab gerade den Kernel 6.14.11 statt dem aktuellen 7.0.14 gebootet -- leider keine Veränderung;
intel-microcode wurde upgedated -- hab auch ohne versucht; der ist auch geblacklistet - dadurch wird er aber nur später dazugeladen, so weit ich das verstanden habe ....

bin nicht beim Server vor Ort -- muss ich hin und mal das bios/BMC durchschauen ...

danke

 

[Kylie Jenner]

characterconverter Check the CPU governor and power settings first. Also, verify BIOS settings and temperature limits, as these can prevent the CPU from reaching its normal speed.

 

[thomashoellerer]

die Datei bios_limit gibts nicht
hab gerade den Kernel 6.14.11 statt dem aktuellen 7.0.14 gebootet -- leider keine Veränderung;
intel-microcode wurde upgedated -- hab auch ohne versucht; der ist auch geblacklistet - dadurch wird er aber nur später dazugeladen, so weit ich das verstanden habe ....

bin nicht beim Server vor Ort -- muss ich hin und mal das bios/BMC durchschauen ...

danke

Hab jetzt noch einen baugleichen Server mit etwas Update Überhang "gefunden"; Läuft unter Kernel 6..8.12 -- und taktet wunderbar bis 3400MHz
echt seltsam ...

 

[Bu66as]

Das ist mal ein brauchbarer Vergleich. Bevor du hinfährst, würd ich auf dem baugleichen Server genau das gleiche abfragen wie auf den betroffenen und nebeneinanderlegen:

cpupower frequency-info
grep -m1 microcode /proc/cpuinfo
cat /proc/cmdline
dmidecode -s bios-version

Die Microcode-Revision ist das Wichtigste. Mit dis_ucode_ldr lädt der Kernel gar keinen Microcode, ein reines Blacklisting reicht dafür nicht. Wenn die Revision trotzdem höher ist als auf dem guten Server, kommt sie aus dem BIOS. Hat der gute Server eine andere "current policy" als 1,2 bis 1,9 GHz, weißt du eher, wo du suchen musst.

Da 6.14 auch nicht hilft: Einen 6.8er gibt es für PVE 9 nicht im Repo, den Kernel kannst du auf den betroffenen Servern also nicht gegentesten. Läuft der gute Server noch auf PVE 8 (pveversion), unterscheidet er sich nicht nur beim Kernel, sondern auch beim intel-microcode-Paket. Umso mehr lohnt sich der Vergleich oben.

 

[thomashoellerer]

Das ist mal ein brauchbarer Vergleich. Bevor du hinfährst, würd ich auf dem baugleichen Server genau das gleiche abfragen wie auf den betroffenen und nebeneinanderlegen:

cpupower frequency-info
grep -m1 microcode /proc/cpuinfo
cat /proc/cmdline
dmidecode -s bios-version

Die Microcode-Revision ist das Wichtigste. Mit dis_ucode_ldr lädt der Kernel gar keinen Microcode, ein reines Blacklisting reicht dafür nicht. Wenn die Revision trotzdem höher ist als auf dem guten Server, kommt sie aus dem BIOS. Hat der gute Server eine andere "current policy" als 1,2 bis 1,9 GHz, weißt du eher, wo du suchen musst.

Da 6.14 auch nicht hilft: Einen 6.8er gibt es für PVE 9 nicht im Repo, den Kernel kannst du auf den betroffenen Servern also nicht gegentesten. Läuft der gute Server noch auf PVE 8 (pveversion), unterscheidet er sich nicht nur beim Kernel, sondern auch beim intel-microcode-Paket. Umso mehr lohnt sich der Vergleich oben.

"schlechter Server":
analyzing CPU 3:
driver: intel_pstate
CPUs which run at the same hardware frequency: 3
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 3.40 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 800 MHz (asserted by call to kernel)
boost state support:
Supported: no
Active: no
root@pm01:~# grep -m1 microcode /proc/cpuinfo
microcode : 0x132
root@pm01:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-7.0.14-24-pve root=/dev/mapper/pve-root ro quiet
root@pm01:~# dmidecode -s bios-version
2002-ASI0006-25072901

Guter "Server"
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 3.30 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3.30 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.30 GHz (asserted by call to kernel)
boost state support:
Supported: no
Active: no
root@pm01:~# grep -m1 microcode /proc/cpuinfo
microcode : 0x129
root@pm01:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-10-pve root=/dev/mapper/pve-root ro quiet
root@pm01:~# dmidecode -s bios-version
0901-ASI0002-25020701

demnach hat der "gute" eine ältere Firmware und das microcode Update noch nicht eingespielt; Er meint aber auch die CPUs müßten nicht per SW gesteuert werden -- klingt nach BIOS Einstellung??

 

[thomashoellerer]

"schlechter Server":
analyzing CPU 3:
driver: intel_pstate
CPUs which run at the same hardware frequency: 3
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 3.40 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 800 MHz (asserted by call to kernel)
boost state support:
Supported: no
Active: no
root@pm01:~# grep -m1 microcode /proc/cpuinfo
microcode : 0x132
root@pm01:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-7.0.14-24-pve root=/dev/mapper/pve-root ro quiet
root@pm01:~# dmidecode -s bios-version
2002-ASI0006-25072901

Guter "Server"
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 3.30 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3.30 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.30 GHz (asserted by call to kernel)
boost state support:
Supported: no
Active: no
root@pm01:~# grep -m1 microcode /proc/cpuinfo
microcode : 0x129
root@pm01:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-10-pve root=/dev/mapper/pve-root ro quiet
root@pm01:~# dmidecode -s bios-version
0901-ASI0002-25020701

demnach hat der "gute" eine ältere Firmware und das microcode Update noch nicht eingespielt; Er meint aber auch die CPUs müßten nicht per SW gesteuert werden -- klingt nach BIOS Einstellung??

DAs mit "dis_ucode_ldr" hab ich schon probiert -- bringt nichts; wobei -- kann man den überhaupt "deaktivieren" wenn er in die CPU eingespielt wurde?