Cette source présente une démarche officielle de dépannage solide. Le N3350 de la ZimaBlade restait proche de 795-800 MHz, même lorsque Jellyfin utilisait le processeur à 100 %. Les températures n’étaient que d’environ 34-45 °C, et le même comportement s’est reproduit sur un ZimaBoard fraîchement installé équipé du même processeur. IceWhale a ensuite examiné la politique de fréquence du processeur et constaté que scaling_governor avait été défini de manière inattendue sur userspace.
Zima-Jerry a proposé de basculer le gouverneur vers une politique dynamique. L’auteur du message l’a modifié pour ondemand et a confirmé explicitement que le processeur montait alors à environ 2,3 GHz et que la réactivité s’améliorait considérablement. Un deuxième utilisateur a signalé que la solution de contournement revenait à userspace après le redémarrage, et IceWhale a répondu que la prochaine version corrigerait le problème. Il faut donc considérer cela comme une régression historique du gouverneur de ZimaOS, avec une solution de contournement en fonctionnement confirmée par la source, et non comme un diagnostic de panne matérielle.
Les éléments fournis par la source ne confirmaient pas une réduction thermique de la fréquence
L’utilisateur avait ajouté un dissipateur thermique et un ventilateur personnalisés, et signalait des températures du processeur inférieures à 45 °C en charge. Il a également indiqué que le système avait déjà été plus chaud — jusqu’à environ 65 °C — sans présenter le même problème de réactivité.
Cela rendait peu probable l’hypothèse selon laquelle « le processeur surchauffe et réduit sa fréquence à 800 MHz » au vu des éléments observés.
Le même comportement a été reproduit sur un autre système ZimaOS fraîchement installé
L’auteur du message a ensuite installé ZimaOS sur un ZimaBoard avec le même processeur et a constaté la même limite à 800 MHz ainsi que le même comportement lent de Jellyfin. Cela a réduit la probabilité qu’une seule carte ZimaBlade soit endommagée.
IceWhale a demandé la politique réelle de fréquence du processeur
Les commandes de diagnostic officielles ont examiné :
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_governorIl s’agit de vérifications en lecture seule, plus sûres que de forcer immédiatement une fréquence maximale ou de modifier les paramètres d’alimentation du BIOS.
IceWhale a trouvé scaling_governor=userspace
Zima-Jerry a indiqué que la sortie de la commande source affichait userspace, tandis que la stratégie ZimaOS attendue à ce moment-là n’aurait pas dû laisser le processeur bloqué à cette valeur.
Les choix d’exécution suggérés comprenaient powersave ou ondemand, selon le pilote cpufreq et les gouverneurs disponibles.
ondemand a été confirmé par la source comme rétablissant l’accélération du processeur
La commande source était :
echo ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorL’auteur du message original a ensuite signalé des accélérations jusqu’à environ 2,3 GHz et une amélioration spectaculaire de la réactivité.
Cette commande provenait directement du personnel d’IceWhale dans le fil de discussion historique, mais les systèmes actuels peuvent exposer d’autres gouverneurs par défaut, comme schedutil. Vérifiez l’état actuel avant d’écrire quoi que ce soit.
La solution de contournement n’a pas persisté pour un autre utilisateur
Khapra a indiqué que les commandes corrigeaient le problème pendant la session en cours, mais qu’après le redémarrage, le gouverneur revenait à userspace. Zima-Jerry a répondu que le problème serait corrigé dans la version suivante.
Ne créez pas de service personnalisé exécuté au démarrage sur un système ZimaOS actuel, sauf si le bogue est effectivement reproductible sur la version actuelle et qu’IceWhale ne l’a pas déjà corrigé.
Jellyfin est la charge de travail qui a révélé le bogue de la stratégie du processeur
La génération des miniatures et le transcodage ont suffisamment sollicité le processeur pour rendre évidente la limitation de fréquence. Il n’a pas été démontré que l’application était la cause première : l’état du gouverneur du processeur constituait le problème au niveau du système, empêchant le processeur de réagir à la charge.
Effectuez d’abord un nouveau test avec la version stable actuelle de ZimaOS
La source concernait la branche de publication 1.4.x. La version actuelle de ZimaOS est bien plus récente. Sur un système actuel, vérifiez le gouverneur et la fréquence en charge avant d’appliquer la solution de contournement de 2025.
La documentation matérielle actuelle de la ZimaBlade identifie le modèle 3760 comme reposant sur la même plateforme Intel N3350 ; le diagnostic historique reste donc utile lorsque les symptômes correspondent.
Utilisez la base matérielle actuelle de la ZimaBlade.
FAQ sur la ZimaBlade à 800 MHz
La source a-t-elle prouvé que le processeur de la ZimaBlade était défectueux ?
Non. Le même problème s’est reproduit sur un autre système et a changé immédiatement lorsque le gouverneur du processeur a été modifié.
Quel réglage IceWhale a-t-il trouvé ?
scaling_governor était défini sur userspace.
Le mode ondemand a-t-il fonctionné ?
Oui. L’auteur du message original a confirmé que la fréquence du processeur était montée à environ 2,3 GHz et que la réactivité de Jellyfin et du système s’était considérablement améliorée.
