Sistema congela completamente com o Intel Bay Trail


29

Meu sistema congela completamente em intervalos aleatórios e frequentes. Comecei a ter o mesmo problema no Ubuntu 14.04, mas após a atualização recente para o 16.04, não há melhorias, na verdade parece pior.

Quando isso acontece, é impossível fazer qualquer coisa. Eu tentei de tudo neste tópico: O que fazer quando o Ubuntu congela, mas nada funciona, eu tenho que reinicializar com força. Li todos os logs do sistema e journalctlnunca há informações que possam ajudar a diagnosticar o problema.

Este é um sistema de inicialização dupla com o Windows 10 e não há nenhum problema, portanto, não há hardware defeituoso.

Meu laptop possui um processador Intel Bay Trail (Pentium N3540)


Respostas:


37

Seu processador é afetado pelo bug do estado c

Isso causa congelamentos totais quando a CPU tenta entrar em um estado de suspensão não suportado. É um problema para muitos dispositivos Bay Trail, especialmente com os kernels (4. *) mais recentes.

Processadores afetados AFAIK:

Atom Z3735F (Asus X205TA, Acer Aspire Switch 10, Lenovo MIIX 3 1030) 
Atom Z3735G
Celeron J1900 (Asus ET2325IUK, shuttle XS35V4)
Celeron N2940 (Acer Aspire ES1-711, Chromebook)
Celeron N2840 (Acer Aspire ES1-311)
Celeron N2930 (Jetway JBC311U93, Zotac Nano CI320)
Pentium N3520 
Pentium N3530 (Acer V3-111P)
Pentium N3540 (Dell Inspiron 15 3000, Lenovo G50, ASUS X550MJ)

(sugerir) edite para adicionar seu próprio dispositivo, se afetado)

A lista completa dos processadores Bay Trail pode ser encontrada aqui

Existe uma solução simples para isso, até que seja corrigido corretamente a montante.

Você só precisa passar um parâmetro de inicialização do kernel e o congelamento aleatório para completamente. O parâmetro pode aumentar um pouco o consumo da bateria, mas oferece um sistema utilizável.

Você faz isso editando o arquivo de configuração do GRUB:

Inicie o Ubuntu e abra um terminal pressionando Ctrl+ Alt+ Te digite

sudo nano /etc/default/grub

Encontre a linha que começa GRUB_CMDLINE_LINUX_DEFAULT=

Isso precisa ser alterado para incluir intel_idle.max_cstate=1

Então, depois da sua edição, ela aparece algo como

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

quiete splashsão parâmetros padrão para o Ubuntu Desktop - não é necessário alterá-los ou quaisquer outros parâmetros pré-existentes

Agora salve o arquivo pressionando ctrl+ e, em oseguida, entersaia pressionando ctrl+x

Agora corra

sudo update-grub

Então reinicie.


O que fazer se você não tiver tempo suficiente para fazer isso antes de o sistema travar

Sem problemas. Conforme explicado na página de ajuda à qual vinculei anteriormente, você pode adicionar o parâmetro ao GRUB antes de inicializar. Observe que isso só passa o parâmetro para a inicialização atual; portanto, você ainda precisará editar /etc/default/grubuma vez inicializado para tornar a alteração permanente.

Você precisa acessar o menu GRUB . Se você estiver inicializando duas vezes, isso aparecerá assim mesmo; caso contrário, você deverá pressionar e segurar (ou tocar) shiftdepois de pressionar o botão liga / desliga para ligar.

Quando você chegar a essa tela, selecione Opções avançadas para o Ubuntu . Você pode mover o cursor para um kernel diferente ou deixá-lo no lugar para editar opções para o padrão. Em vez de pressionar enter, pressione ee você vai entrar em modo de edição, olhando vagamente como este .

Mova o cursor para baixo, onde está escrito quiet splash, coloque um espaço após o splash e digite com cuidado, intel_idle.max_cstate=1certificando-se de que haja um espaço depois dele.

Agora pressione F10ou Ctrl+ xpara inicializar.


@ Arronical hehe obrigado! Eu tenho que saber isso - meu sistema irá ficar por ~ 15 minutos sem ele, mas com o param, nunca congelado uma vez :) Todo o crédito para os realmente hackers impressionantes que percebi isso
Zanna

Obrigado! Isso interrompe a não resposta ao Ctrl Alt REISUB? Também a resposta para a edição acima do GRUB foi que, se o Tempo limite oculto estiver definido, a edição acima não funcionará. Como contornar isso se o problema persistir?
clr

@clr os congelamentos do estado c não respondem ao sysrq mágico REISUB, mas essa correção interrompe os congelamentos do estado c. Se o seu sistema congelar por algum outro motivo, o REISUB pode funcionar. GRUB_HIDDEN_TIMEOUT não afeta os parâmetros de inicialização e você deve poder acessar o menu pressionando Shift na inicialização. Se você não puder, no caso em que o sistema congela rápido demais para você editar /etc/default/grub, isso é problemático, mas você pode tentar inicializar uma sessão ao vivo de uma versão com um kernel antigo para editar o arquivo - monte a partição raiz /mnte edite /mnt/etc/default/grubpara adicione o parâmetro
Zanna 28/09

Obrigado por instruções claras. Espero que isso faça o truque. Vou relatar aqui, se não aparecer. Atualmente, estou executando o 16.10 em um Zotac Nano CI320. Eu já havia experimentado o 16.04 e o Debian 8 anteriormente, e também tive congelamentos aleatórios. Eu tentei 16.10 esperando que o problema desaparecesse com um kernel mais recente. Curiosamente, a única vez em que tentei o REISUB (não me lembro qual sistema operacional) funcionou - pode parecer que estou enfrentando um problema diferente.
21716 Jeremy Cook

@ JeremyCook Acabei de instalar o 16.10 e a primeira coisa que fiz foi editar meus parâmetros de inicialização - eu realmente deveria conferir este novo kernel! Por favor, deixe-me saber se funciona ou não aqui.
Zanna

1

Os processadores Linux on Bay Trail e Braswell congelam aleatoriamente com dispositivos de vídeo embutidos.

O problema está no controle de temperatura. Basta remover o módulo thermald:

sudo apt-get remove thermald 

3
Acredito que o bug do Bay Trail esteja no driver i915 (Intel CPU). O processador tenta constantemente entrar em estados de suspensão que não são suportados por ele. Os problemas para os usuários do Bay Trail começaram após o commit no i915, então sempre foi o culpado. No entanto, talvez haja outra causa para alguns, e eu não tenho idéia sobre os congelamentos de Braswell e seria ótimo saber que eles são corrigidos por alguma ação (segura?). Você tem alguma referência para essas informações ou pode nos dizer em qual hardware foi testado e trabalhado?
Zanna

Parece que este ainda é um problema com 19.04. Esperava que já estivesse consertado. Acontece no meu laptop desde 14.04. 15.10 era quase impossível de corrigir.
crip659

0

Para as pessoas que seguem esse bug, aqui está uma atualização. Vá para: Bug 109051 - intel_idle.max_cstate = 1 necessário no baytrail para evitar falhas e pressione a Endtecla. Se necessário, pressione Page Upa mensagem # 1013.

De acordo com o comentário # 1013, agora está corrigido nos kernels recentes:

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 ponta alimentado com um Intel N2807 que nunca funcionou mais de 30 minutos sem travar quando 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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.