Respostas:
Esses congelamentos acontecem quando o processador tenta entrar em um estado de baixa energia (estado c) que o kernel não suporta. Esse problema foi introduzido por
commit 8fb55197e64d5988ec57b54e973daeea72c3f2ff
Date: Tue Apr 7 16:20:28 2015 +0100
drm/i915: Aggressive downclocking on Baytrail
Isso ocorreu no kernel 4.2, e temos problemas desde então. Conforme explicado na resposta do heynnema (e neste post em que tentei coletar informações ), há uma solução simples e eficaz, passando um parâmetro de inicialização que desativa os estados de baixo consumo de energia.
A versão beta do 17.04 atualmente disponível usa 4.9 (é baseada no upstream 4.9.6, pelo que entendi) e, quando o lançamento for lançado em abril, acredito que estará usando o 4.10 . O problema ainda existe nesses kernels, então concluí que não está resolvido a partir de agora . Verifiquei os changelogs do kernel do Ubuntu e não encontrei nada, mas por favor me corrija se estiver errado.
Eu tenho rastreado o bug do estado c aqui no kernel.org por um longo tempo. Em janeiro de 2017, Mika Kuoppala adicionou esse patch ao thread. Aparentemente, ele reverte o commit anterior que causou o problema. O patch é chamado
drm/i915/byt: Avoid tweaking evaluation thresholds
Os testes indicam resultados muito bons com esse patch, que foi enviado aos proprietários do driver i915 em 25 de janeiro. Tudo bem, poderia ser mesclado na janela 4.11. O kernel 4.11 pode ser lançado no final de abril. Uma versão desse patch foi mesclada na janela 4.11 e os relatórios indicam que o bug foi corrigido na 4.11.
Cada um dos problemáticos processadores BayTrail se comporta um pouco diferente com cada kernel diferente. Em 16.04 (kernel 4.4), meu tempo de atividade no Atom Z3735F sem o parâmetro intel_idle estava em torno de 15 minutos antes do congelamento. Testei a ISO beta 17.04 no modo ao vivo e não tive um congelamento em 90 minutos, então parece que tenho sorte com esse kernel. Você pode fazer o mesmo para testar qualquer imagem em seu sistema - basta fazer um USB inicializável e "experimentar o Ubuntu sem instalar" e testá-lo pelo maior tempo possível.
Quando o 17.04 foi lançado, eu o instalei e, nas duas primeiras semanas, o executei sem o intel_idleparâmetro, eu tinha apenas três congelamentos de estado c, o que é uma grande melhoria em versões anteriores.
A coisa mais segura a fazer é usar o parâmetro de inicialização. Com base em minha pesquisa, espero que o bug seja corrigido na 17.10 (e em outras versões de distribuição ainda este ano), que usará um kernel> = 4.11, mas não na 17.04.
No entanto, sempre há a possibilidade de que a Equipe do Kernel do Ubuntu possa corrigi-lo. Se você puder tolerar a execução de um sistema instável ocasionalmente, poderá acompanhar o progresso executando atualizações regulares ( sudo apt update && sudo apt full-upgrade) e testando cada novo kernel sem o parâmetro de inicialização quando ele chegar. Você também pode ler os registros de alterações à medida que novos pacotes são instalados ou (novamente, se você pode tolerar a instabilidade) instalar um kernel da linha principal .
i915e provavelmente será corrigido pelo mesmo patch, mas o relatório de bug trata de problemas corrigidos pelo parâmetro intel_idle e, se isso não funcionar, é um bug diferente, de acordo com o pessoal do kernel. Você pode fornecer um relatório de bug ou tópico do fórum (você diz que outras pessoas compartilham o seu problema) onde eu posso descobrir mais, para que eu possa aconselhá-lo sobre o que fazer em seguida? (Eu acho que você pode precisar fazer uma nova pergunta)
Existe uma correção para isso em Como definir intel_idle.max_cstate = 1 .
Em terminal, digite:
gksudo gedit /etc/default/grub
e mude esta linha:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
para incluir isso:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
então faça:
sudo update-grub
reboot
Este é um problema da Intel, não do Ubuntu, mas, graças a Deus, temos uma solução.
Ninguém sabe se o Ubuntu 17.04 exigirá essa correção ou não.
De acordo com o comentário # 1013 no relatório de erros , agora está corrigido:
Não checo esse tópico há muito tempo, mas achei que deveria postar minhas descobertas para o caso de serem úteis a alguém.
Um computador de baixo custo com um Intel N2807 que nunca funcionou mais de 30 minutos sem travar quando eu não defini ... max_cstates = 1 agora funciona perfeitamente bem com um kernel padrão v. 5.3.1 ou 4.19.75. Eu o executei por alguns dias em cada versão sem problemas. O consumo médio de energia também caiu um pouco mais de 10%.
Demorou cerca de quatro anos para corrigir esse bug relatado pela primeira vez em 8 de dezembro de 2015.