Diese Quelle enthält eine überzeugende offizielle Fehlerbehebungskette. Der N3350 des ZimaBlade blieb selbst dann bei etwa 795–800 MHz, wenn Jellyfin die CPU-Auslastung auf 100 % trieb. Die Temperaturen lagen nur bei etwa 34–45 °C, und dasselbe Verhalten trat auf einem frisch installierten ZimaBoard mit demselben Prozessor erneut auf. IceWhale überprüfte daraufhin die CPU-Frequenzrichtlinie und stellte fest, dass scaling_governor unerwartet eingestellt auf userspace.
Zima-Jerry schlug vor, die Richtlinie auf eine dynamische Einstellung umzustellen. Der ursprüngliche Verfasser änderte sie auf ondemand und bestätigte ausdrücklich, dass die CPU daraufhin auf etwa 2,3 GHz hochtaktete und sich die Reaktionsfähigkeit deutlich verbesserte. Ein zweiter Nutzer berichtete, dass die Umgehung zurückgesetzt wurde auf userspace Nach dem Neustart antwortete IceWhale, dass die nächste Version das Problem beheben würde. Daher sollte dies als historische ZimaOS-Regression der CPU-Richtlinie mit einer durch die Quelle bestätigten Laufzeitumgehung betrachtet werden – nicht als Diagnose eines Hardwaredefekts.
Die Quellbelege stützten keine thermische Drosselung
Der Nutzer hatte einen eigenen Kühlkörper mit Lüfter angebracht und berichtete unter Last von CPU-Temperaturen unter 45 °C. Außerdem merkte er an, dass das System zuvor bereits heißer gewesen war – bis ungefähr 65 °C –, ohne dass dasselbe Problem bei der Reaktionsfähigkeit aufgetreten war.
Daher passte „Die CPU überhitzt und wird auf 800 MHz gedrosselt“ schlecht zu den beobachteten Beweisen.
Dasselbe Verhalten trat auf einem anderen frisch installierten ZimaOS-System erneut auf
Der ursprüngliche Verfasser installierte später ZimaOS frisch auf einem ZimaBoard mit demselben Prozessor und stellte dieselbe Begrenzung auf 800 MHz sowie das träge Verhalten von Jellyfin fest. Dadurch wurde es unwahrscheinlicher, dass nur ein einzelnes ZimaBlade-Board beschädigt war.
IceWhale bat um die tatsächliche CPU-Frequenzrichtlinie
Die offiziellen Diagnosebefehle überprüften:
cat /sys/devices/system/cpu/intel_pstate/no_turbo
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorDabei handelt es sich um schreibgeschützte Prüfungen, die sicherer sind, als sofort den maximalen Takt zu erzwingen oder die BIOS-Energieeinstellungen zu ändern.
IceWhale stellte scaling_governor=userspace fest
Zima-Jerry sagte, dass die Quellenausgabe Folgendes zeigte userspace, wobei die erwartete ZimaOS-Richtlinie die CPU zu diesem Zeitpunkt nicht dort hätte festsetzen dürfen.
Zu den vorgeschlagenen Laufzeitoptionen gehörten powersave oder ondemand, abhängig vom verfügbaren cpufreq-Treiber bzw. den verfügbaren Governors.
ondemand wurde laut Quelle als Lösung zur Wiederherstellung der CPU-Boosts bestätigt
Der Quellbefehl lautete:
echo ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorDer ursprüngliche Verfasser berichtete anschließend von Erhöhungen auf etwa 2,3 GHz und einer deutlich verbesserten Reaktionsfähigkeit.
Dieser Befehl stammte direkt von den IceWhale-Mitarbeitern aus dem historischen Thread, aber aktuelle Systeme können andere Standard-Governors wie etwa schedutil. Prüfe den aktuellen Zustand, bevor du etwas schreibst.
Die Umgehungslösung blieb bei einem anderen Benutzer nicht dauerhaft bestehen
Khapra sagte, dass die Befehle das Problem während der laufenden Sitzung behoben hätten, der Governor nach dem Neustart jedoch zurückkehrte zu userspace. Zima-Jerry antwortete, dass das Problem in der nächsten Version behoben werde.
Erstelle auf einem aktuellen ZimaOS-System keinen benutzerdefinierten Dienst für den Start, es sei denn, der Fehler lässt sich in der aktuellen Version tatsächlich reproduzieren und IceWhale hat ihn nicht bereits behoben.
Jellyfin war die Arbeitslast, die den CPU-Richtlinienfehler sichtbar machte
Die Thumbnail-Erstellung bzw. Transkodierung erhöhte die CPU-Auslastung so stark, dass die Frequenzbegrenzung offensichtlich wurde. Es war nicht nachgewiesen, dass die App die eigentliche Ursache war: Der CPU-Governor-Zustand war das systemweite Problem, das den Prozessor daran hinderte, auf die Last zu reagieren.
Zuerst mit der aktuellen stabilen ZimaOS-Version erneut testen
Die Quelle bezog sich auf die Versionsreihe 1.4.x. Das aktuelle ZimaOS ist wesentlich neuer. Prüfe auf einem aktuellen System unter Last den Governor und die Frequenz, bevor du die Umgehungslösung von 2025 anwendest.
Die aktuelle ZimaBlade-Hardwaredokumentation nennt für das Modell 3760 dieselbe Intel-N3350-Plattform, daher bleibt die historische Diagnose nützlich, wenn die Symptome übereinstimmen.
Verwende die aktuelle ZimaBlade-Hardwarebasis.
FAQ zum ZimaBlade mit 800 MHz
Bewies die Quelle, dass die CPU des ZimaBlade defekt war?
Nein. Dasselbe Problem trat auf einem anderen System erneut auf und änderte sich sofort, als der CPU-Governor gewechselt wurde.
Welche Einstellung hat IceWhale gefunden?
scaling_governor war eingestellt auf userspace.
Hat ondemand funktioniert?
Ja. Der ursprüngliche Verfasser bestätigte, dass die CPU-Frequenz auf etwa 2,3 GHz stieg und sich die Reaktionsfähigkeit von Jellyfin bzw. des Systems deutlich verbesserte.
