Início / ubuntu / Perguntas / 1286254
Accepted
John Chrysostom
Asked: 2020-10-24 04:30:56 +0800 CST

Como solucionar problemas de travamento total do sistema

  • 772

Eu tenho um novo laptop System76 Lemur Pro com Ubuntu 20.04. Eu realmente quero amá-lo, mas estou descobrindo que ele está travando completa e totalmente várias vezes por semana, o que meio que atrapalha meus sentimentos. Estou em contato com o suporte do System76, mas também estou tentando resolver alguns problemas por conta própria. Sou relativamente novo no Linux e espero aprender não apenas como consertar minha máquina, mas também as etapas gerais de solução de problemas que seriam úteis no futuro.

O sistema : System76 Lemur Pro, i7, 40 GB de RAM, SSD único. Ubuntu 20.04. Todas as atualizações instaladas. Apenas os periféricos são um hub USB com mouse e teclado conectados e um monitor externo conectado via adaptador USB-C para DisplayPort. Nada exótico.

A falha : várias vezes por semana, volto ao meu laptop (geralmente de manhã, depois que ele fica ocioso a noite toda) para descobrir que ele não responde totalmente ao mouse/teclado. Usar ALT+F_ para tentar mudar para um terminal não faz nada. ALT + PRTSCR + REISUB não faz nada. Apertar o botão de energia não faz nada. Tentar ligar o LCD interno não faz nada. Apenas segurando o botão liga / desliga e redefinindo a máquina me permite recuperar. Isso aconteceu apenas uma vez enquanto eu estava usando ativamente a máquina e a área de trabalho do Gnome permaneceu visível, o mouse e o teclado travados, e cerca de 1/4 de segundo da música que eu estava ouvindo ficou preso em um loop. Nada além de hard reset trabalhou para recuperar.

O que eu tentei:

  • CPU de teste de estresse. Eu monitorei as temperaturas da CPU enquanto executava um teste de estresse por vários minutos. As temperaturas nunca ultrapassaram os 80 e o ventilador da CPU entrou em ação para mantê-lo sob controle. Isso parece seguro, já que as temperaturas quentes/críticas foram listadas como 100.
  • Executando o memtest. Looped por 5 vezes, tudo passou.
  • Instalando quaisquer atualizações recomendadas pelo Ubuntu.
  • Examinando os logs do sistema (/var/log/syslog). Esses logs simplesmente ficam em branco quando o sistema trava e ficam em branco até que eu o reinicie. Nada imediatamente antes do acidente parece terrivelmente interessante.
  • Desativando o sono. Já estava desativado, mas pensei em mencionar isso.

Neste ponto, não tenho certeza de quais devem ser meus próximos passos. Existem outros logs que eu possa olhar? Outros diagnósticos que posso executar? Devo presumir que é um periférico e desconectar o teclado/mouse/monitor/hub um de cada vez para tentar isolar? Parece improvável que seja um periférico comum, mas quem sabe.

Edit: conforme solicitado, aqui estão os logs de /var/log/kern.logantes de uma das falhas. Ele inclui muitas informações sobre a limitação da CPU sendo gerenciada. No entanto, essas mensagens ocorrem regularmente quando o computador está estável também...

Oct 22 07:52:00 system76-pc kernel: [44320.095989] mce: CPU4: Package temperature above threshold, cpu clock throttled (total events = 7775)
Oct 22 07:52:00 system76-pc kernel: [44320.095990] mce: CPU1: Package temperature above threshold, cpu clock throttled (total events = 4669)
Oct 22 07:52:00 system76-pc kernel: [44320.095992] mce: CPU3: Package temperature above threshold, cpu clock throttled (total events = 719)
Oct 22 07:52:00 system76-pc kernel: [44320.095992] mce: CPU6: Package temperature above threshold, cpu clock throttled (total events = 752)
Oct 22 07:52:00 system76-pc kernel: [44320.095994] mce: CPU7: Package temperature above threshold, cpu clock throttled (total events = 752)
Oct 22 07:52:00 system76-pc kernel: [44320.096970] mce: CPU2: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096972] mce: CPU0: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096972] mce: CPU5: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096973] mce: CPU3: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096974] mce: CPU6: Core temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096974] mce: CPU7: Core temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096975] mce: CPU4: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096976] mce: CPU1: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096977] mce: CPU6: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096977] mce: CPU7: Package temperature/speed normal
laptop freeze crash 20.04

2 respostas

  1. Esta é uma resposta parcial, baseada em informações atuais, inclusive dos comentários.

    Nos arquivos de log, há indicações de que altas temperaturas da CPU estão envolvidas, de modo que o sistema continua atingindo seu limite de temperatura de estrangulamento. No entanto, os testes de estresse da CPU não indicam nenhum problema.

    Como teste, encontre o ponto operacional do sistema onde os problemas térmicos da CPU não são possíveis e execute dessa maneira por tempo suficiente para determinar o efeito na estabilidade do sistema. O custo deste teste será o desempenho. Mais tarde, um daemon térmico adequado (thermald, tlp, ...) deve ser investigado como forma de recuperar o desempenho máximo.

    O driver de escala de frequência de CPU padrão para o i7-10510U é intel_pstate, e esta resposta foi escrita para esse driver. Verifique através de:

    doug@s15:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu2/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu4/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu5/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu6/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu7/cpufreq/scaling_driver:intel_cpufreq

    O teste de tortura de alto calor mprime (prime95) é usado como teste de estresse da CPU porque consome mais energia do que qualquer teste de estresse da CPU que já testei. Para proteger meu computador de exemplo, que não tem daemon térmico em execução, o ponto de operação desejado de cerca de 80 graus será encontrado no lado inferior. Primeiro, observe o percentual de frequência máxima da CPU atual, observe o mínimo também (o seu será diferente):

    cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
doug@s15:~$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
100
doug@s15:~$ cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
42

    Pode não ser 100% se algum daemon térmico já estiver limitando as coisas. De qualquer forma, vou começar com 50%:

    doug@s15:~$ echo 50 | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct
50

    Em seguida, aumente gradualmente a porcentagem máxima de frequência da CPU, digamos em incrementos de 10%, e encontre o ponto operacional para cerca de 80 graus de temperatura do pacote do processador:

    doug@s15:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt GFXWatt

0.25    1754    725     25      3.81    0.12
0.02    1600    288     26      3.70    0.12
0.06    1600    360     26      3.70    0.12
38.82   1899    7740    39      16.28   0.12
100.00  1900    17594   41      36.20   0.12   <<< mprime torture test started
100.00  1900    17541   42      36.44   0.12
100.00  1900    17552   43      36.39   0.12
100.00  1900    17517   44      36.25   0.12
100.00  1927    17474   48      36.95   0.12
100.00  2300    17389   49      46.51   0.12
100.00  2300    17367   50      46.60   0.12
100.00  2300    17362   52      46.69   0.12
100.00  2300    17438   53      46.77   0.12
100.00  2552    18440   56      54.18   0.12
100.00  2700    17672   58      58.48   0.12
100.00  2700    17590   58      58.59   0.12
100.00  2700    17710   61      58.74   0.12
100.00  2953    17780   66      67.91   0.12
100.00  3100    17876   68      73.38   0.12  <<<< First time at 80%, temp lags.
100.00  3100    17843   69      73.55   0.12
100.00  3100    17860   70      73.64   0.12
100.00  3100    18794   71      73.78   0.12
100.00  3231    17826   77      79.69   0.12
100.00  3500    18305   80      92.33   0.12
100.00  3500    17765   81      92.66   0.12
100.00  3457    17747   80      90.72   0.12
100.00  3300    17720   81      82.62   0.12
100.00  3300    17723   81      82.72   0.12
100.00  3300    17708   80      82.81   0.12
100.00  3300    17712   83      82.95   0.12  <<<< Opps too high
100.00  3300    17788   82      83.08   0.12
100.00  3204    17882   81      79.25   0.12
100.00  3100    17778   80      74.78   0.12
100.00  3100    18571   81      74.83   0.12
100.00  3100    17806   80      74.85   0.12
100.00  3100    17787   80      74.89   0.12 <<<< 80 percent seems stable
100.00  3100    17772   81      74.84   0.12
100.00  3100    17824   81      74.85   0.12
100.00  3100    17777   80      74.89   0.12
100.00  3100    17799   81      74.95   0.12
100.00  3100    17867   81      74.77   0.12

    Portanto, para o meu sistema, limitar a frequência da CPU a 80% do máximo os manterá longe de qualquer limitação térmica adicional incorporada. Execute o sistema desta forma por algum tempo.

    • 0
  2. Best Answer

    Este é um bug do Kernel associado ao gerenciamento de energia da CPU. É corrigido no kernel 5.8, que vem com o Ubuntu 20.10. Atualizei para 20.10, desativei todas as soluções alternativas e estou funcionando estável agora.

    Se a atualização para 5.8/20.10 não for algo que você deseja fazer, você também pode contornar o bug impedindo que sua CPU entre em estados de baixa energia (isso reduzirá a vida útil da bateria, obviamente). Abra /etc/default/grube adicione intel_idle.max_cstate=1ao conteúdo do valor para GRUB_CMDLINE_LINUX_DEFAULT. Salve, execute sudo update-grube reinicie. Inverta o processo para reverter a solução alternativa.

    É possível que um valor de cstate maior que 1 ainda seja uma solução alternativa estável, mas nunca experimentei o suficiente para verificar.

    • 0

relate perguntas