Esta fonte apresenta uma sequência oficial sólida de resolução de problemas. O N3350 da ZimaBlade manteve-se perto dos 795–800 MHz, mesmo enquanto o Jellyfin elevava a utilização da CPU para 100%. As temperaturas rondavam apenas os 34–45 °C, e o mesmo comportamento reproduziu-se numa ZimaBoard acabada de instalar com o mesmo processador. A IceWhale inspecionou então a política de frequência da CPU e encontrou scaling_governor definido inesperadamente como userspace.
O Zima-Jerry propôs mudar o regulador para uma política dinâmica. O autor original alterou-o para ondemand e confirmou explicitamente que a CPU passou então a aumentar a frequência para cerca de 2,3 GHz e que a capacidade de resposta melhorou drasticamente. Um segundo utilizador comunicou que a solução temporária revertia para userspace após o reinício, e a IceWhale respondeu que a versão seguinte corrigiria o problema. Por conseguinte, isto deve ser tratado como uma regressão histórica do regulador do ZimaOS, com uma solução temporária em tempo de execução confirmada pela fonte — e não como um diagnóstico de falha de hardware.
As evidências de origem não sustentavam uma redução térmica da frequência
O utilizador tinha instalado um dissipador/ventoinha personalizado e comunicou temperaturas da CPU inferiores a 45 °C sob carga. Observou também que o sistema já tinha atingido temperaturas mais elevadas — até cerca de 65 °C — sem o mesmo problema de capacidade de resposta.
Isso tornou pouco provável, face às evidências observadas, que “a CPU esteja a sobreaquecer e a reduzir a frequência para 800 MHz”.
O mesmo comportamento reproduziu-se noutro sistema ZimaOS acabado de instalar
Mais tarde, o autor da publicação instalou o ZimaOS de raiz numa ZimaBoard com o mesmo processador e observou o mesmo limite de 800 MHz e o desempenho lento do Jellyfin. Isto reduziu a probabilidade de se tratar de uma única placa ZimaBlade danificada.
IceWhale pediu a política de frequência real da CPU
Os comandos oficiais de diagnóstico inspecionaram:
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_governorEstas são verificações apenas de leitura e são mais seguras do que forçar imediatamente a frequência máxima ou alterar as definições de energia da BIOS.
IceWhale encontrou scaling_governor=userspace
O Zima-Jerry afirmou que o resultado de origem mostrava userspace, embora a política esperada do ZimaOS nessa altura não devesse ter deixado o CPU preso nesse estado.
As opções de execução sugeridas incluíam powersave ou ondemand, consoante o controlador/governadores cpufreq disponíveis.
Foi confirmado pela fonte que ondemand restaurava o aumento da frequência do CPU
O comando da fonte era:
echo ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorO autor original comunicou então aumentos até cerca de 2,3 GHz e uma melhoria drástica da capacidade de resposta.
Este comando veio diretamente da equipa da IceWhale na discussão histórica, mas os sistemas atuais podem apresentar outros governadores predefinidos, como schedutil. Verifique o estado atual antes de escrever qualquer coisa.
A solução temporária não persistiu para outro utilizador
A Khapra afirmou que os comandos corrigiram o problema durante a sessão em execução, mas, após o reinício, o governador voltou para userspace. O Zima-Jerry respondeu que o problema seria corrigido na versão seguinte.
Não crie um serviço personalizado executado no arranque num sistema ZimaOS atual, a menos que o erro seja efetivamente reproduzível na versão atual e a IceWhale ainda não o tenha corrigido.
O Jellyfin foi a carga de trabalho que expôs o erro da política do CPU
A geração de miniaturas/transcodificação aumentou suficientemente a carga do CPU para tornar evidente o limite de frequência. Não foi provado que a aplicação fosse a causa principal: o estado do governador do CPU era o problema ao nível do sistema que impedia o processador de responder à carga.
Volte a testar primeiro no ZimaOS estável atual
A fonte correspondia à linha de versões 1.4.x. O ZimaOS atual é muito mais recente. Num sistema atual, verifique o governador e a frequência sob carga antes de aplicar a solução temporária de 2025.
A documentação atual do hardware do ZimaBlade identifica o modelo 3760 com a mesma plataforma Intel N3350, pelo que o diagnóstico histórico continua a ser útil quando os sintomas coincidem.
Utilize a referência atual do hardware do ZimaBlade.
Perguntas frequentes sobre o ZimaBlade a 800 MHz
A fonte provou que o CPU do ZimaBlade tinha uma avaria?
Não. O mesmo problema reproduziu-se noutro sistema e mudou imediatamente quando o governador do CPU foi alterado.
Que definição encontrou a IceWhale?
scaling_governor estava definido como userspace.
O ondemand funcionou?
Sim. O autor da publicação original confirmou que a frequência do CPU subiu para cerca de 2,3 GHz e que a capacidade de resposta do Jellyfin/sistema melhorou drasticamente.
