Questa fonte presenta una solida sequenza ufficiale di troubleshooting. L’N3350 dello ZimaBlade è rimasto intorno a 795-800 MHz anche mentre Jellyfin portava l’utilizzo della CPU al 100%. Le temperature erano di soli 34-45 °C circa, e lo stesso comportamento si è riprodotto su uno ZimaBoard appena installato con lo stesso processore. IceWhale ha quindi esaminato la politica della frequenza della CPU e ha rilevato scaling_governor inaspettatamente impostato su userspace.
Zima-Jerry ha proposto di passare il governor a una politica dinamica. L’autore originale del post lo ha impostato su ondemand e ha confermato esplicitamente che la CPU è poi aumentata fino a circa 2,3 GHz e che la reattività è migliorata notevolmente. Un secondo utente ha segnalato che la soluzione temporanea è tornata a userspace dopo il riavvio, e IceWhale ha risposto che la versione successiva avrebbe risolto il problema. Pertanto, questo caso dovrebbe essere considerato una regressione storica del governor di ZimaOS con una soluzione temporanea applicabile a runtime e confermata dalla fonte, non una diagnosi di guasto hardware.
Le prove di origine non supportavano l’ipotesi di una riduzione termica della frequenza
L’utente aveva aggiunto un dissipatore/ventola personalizzato e aveva segnalato temperature della CPU inferiori a 45 °C sotto carico. Aveva inoltre osservato che in precedenza il sistema era stato più caldo—fino a circa 65 °C—senza lo stesso problema di reattività.
Questo ha reso poco compatibile con le prove osservate l’ipotesi «la CPU si surriscalda e riduce la frequenza a 800 MHz».
Lo stesso comportamento è stato riprodotto su un altro sistema ZimaOS appena installato
In seguito, l’autore del post ha installato da zero ZimaOS su uno ZimaBoard con lo stesso processore e ha riscontrato lo stesso limite di 800 MHz e lo stesso comportamento lento di Jellyfin. Ciò ha reso meno probabile l’ipotesi di una singola scheda ZimaBlade danneggiata.
IceWhale ha chiesto la politica effettiva della frequenza della CPU
I comandi diagnostici ufficiali hanno verificato:
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_governorSi tratta di controlli in sola lettura e sono più sicuri rispetto a forzare immediatamente la frequenza massima o modificare le impostazioni di alimentazione del BIOS.
IceWhale ha rilevato scaling_governor=userspace
Zima-Jerry ha detto che l’output di origine mostrava userspace, mentre in quel momento i criteri previsti da ZimaOS non avrebbero dovuto lasciare la CPU bloccata su quel valore.
Le opzioni runtime suggerite includevano powersave oppure ondemand, a seconda del driver cpufreq e dei governor disponibili.
ondemand è stato confermato dalla fonte come soluzione per ripristinare l'aumento della frequenza della CPU
Il comando riportato nella fonte era:
echo ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorL'autore del post originale ha poi segnalato aumenti fino a circa 2,3 GHz e un drastico miglioramento della reattività.
Questo comando proveniva direttamente dallo staff di IceWhale nella discussione storica, ma i sistemi attuali potrebbero esporre governor predefiniti diversi, come schedutil. Controlla lo stato attuale prima di scrivere qualsiasi cosa.
La soluzione temporanea non è rimasta applicata per un altro utente
Khapra ha detto che i comandi hanno risolto il problema durante la sessione in corso, ma dopo il riavvio il governor è tornato a userspace. Zima-Jerry ha risposto che il problema sarebbe stato risolto nella versione successiva.
Non creare un servizio personalizzato all'avvio su un sistema ZimaOS attuale, a meno che il bug non sia effettivamente riproducibile nella release attuale e IceWhale non lo abbia già corretto.
Jellyfin è stato il carico di lavoro che ha fatto emergere il bug dei criteri della CPU
La generazione delle miniature e la transcodifica hanno portato il carico della CPU a un livello sufficiente per rendere evidente il limite di frequenza. Non è stato dimostrato che l'app fosse la causa principale: il problema a livello di sistema era lo stato del governor della CPU, che impediva al processore di rispondere al carico.
Esegui prima un nuovo test con l'attuale versione stabile di ZimaOS
La fonte si riferiva al ramo di release 1.4.x. L'attuale ZimaOS è molto più recente. Su un sistema attuale, controlla il governor e la frequenza sotto carico prima di applicare la soluzione temporanea del 2025.
La documentazione hardware attuale dello ZimaBlade identifica il modello 3760 con la stessa piattaforma Intel N3350, quindi la diagnosi storica rimane utile quando i sintomi corrispondono.
Usa la configurazione hardware attuale dello ZimaBlade.
FAQ sullo ZimaBlade a 800 MHz
La fonte ha dimostrato che la CPU dello ZimaBlade era difettosa?
No. Lo stesso problema si è riprodotto su un altro sistema ed è cambiato immediatamente quando è cambiato il governor della CPU.
Quale impostazione ha individuato IceWhale?
scaling_governor era impostato su userspace.
ondemand funzionava?
Sì. L'autore del post originale ha confermato che la frequenza della CPU è salita a circa 2,3 GHz e che la reattività di Jellyfin e del sistema è migliorata drasticamente.
