Elimine o travamento / kernel panic do Ubuntu 16.04 com gráficos AMD

[gelk98]

  Olá Sampayu, lamento informar de que não funcionou, ou seja, a tela do youtube para transmissões ao vivo continua com o problema.

Minha curiosidade é por que no ubuntu 17.10 funcionava?

Desde já obrigado por toda a atenção, acho que + lá para frente deverá haver uma solução.

abs

[Sampayu]

Olá Sampayu, lamento informar de que não funcionou, ou seja, a tela do youtube para transmissões ao vivo continua com o problema.

Minha curiosidade é por que no ubuntu 17.10 funcionava?

Desde já obrigado por toda a atenção, acho que + lá para frente deverá haver uma solução.

abs

Você está usando kernel versão 4.7.10? No kernel 4.7.10 o driver gráfico open-source da AMD funciona normalmente e o Flash carrega normalmente. Acabei de acessar o YouTube e assistir um vídeo ao vivo nos três navegadores (Firefox, Opera e Chrome) sem problema nenhum. Você já experimentou assistir outros vídeos ao vivo e nenhum deles funcionou? Qual é o navegador que está (ou quais navegadores que estão) dando problema?

Você está tentando assistir vídeo ao vivo ou transmitir vídeo ao vivo?

[gelk98]

Prezado Sampayu, na resposta 59 eu menciono qual é o Kernel ( 4.10.0-28 - generic )

Lembro que após o processo anterior que realizamos, não consegui mais acessar o banco do brasil pelo Firefox, muito menos pelo Chromo, apesar de tentar reinstalar o warsan diversas vezes e tendo limpado o que era possível.

Obs.: Já tentamos instalar a versão que vc menciona e não conseguimos, posso tentar novamente....

[gelk98]

Olá, Sampayu

Dando prosseguimento para mudança do Kernel, seguindo o passo a passo existente, o mesmo retornou com a seguinte configuração:

luciene@Inspiron-1545:~$ uname -r
4.13.0-26-generic
luciene@Inspiron-1545:~$


ou seja, passou do 10 para o 13???

[gelk98]

  Olá, bom dia Sampayu,

Bom desde já agradeço pela ajuda em acessar o banco do Brasil e ter o Youtube na transmissões ao vivo funcionando.

Detalhe, não posso afirmar, mas após habilitar os codecs, o sistema através do Firefox passou acessar até com a nova versão do Kernel, veja o Kernel que estou utilizando: 4.13.0-26-generic
, não só o Firefox, mas o Chromo também, inclusive abri três telas no Youtube, transmissões ao vivo ao mesmo tempo, e funcionou perfeitamente.
Acredito que possa ser utilizado como fonte de informação para todos aqueles que possam estar tendo problemas com o processador AMD e placa gráfica igual a minha que citei acima.

Um grande abraço

[gelk98]

Olá, bom dia Sampayu,

Bom desde já agradeço pela ajuda em acessar o banco do Brasil e ter o Youtube na transmissões ao vivo funcionando.

Detalhe, não posso afirmar, mas após habilitar os codecs, o sistema através do Firefox passou acessar até com a nova versão do Kernel, veja o Kernel que estou utilizando: 4.13.0-26-generic
, não só o Firefox, mas o Chromo também, inclusive abri três telas no Youtube, transmissões ao vivo ao mesmo tempo, e funcionou perfeitamente.
Acredito que possa ser utilizado como fonte de informação para todos aqueles que possam estar tendo problemas com o processador AMD e placa gráfica igual a minha que citei acima.

Um grande abraço


Esqueci de mencionar que no caso do navegador Choromo há necessidade de sempre habilitar o Flash o tempo todo.

[Sampayu]

Olá, bom dia Sampayu,

Bom desde já agradeço pela ajuda em acessar o banco do Brasil e ter o Youtube na transmissões ao vivo funcionando.

Detalhe, não posso afirmar, mas após habilitar os codecs, o sistema através do Firefox passou acessar até com a nova versão do Kernel, veja o Kernel que estou utilizando: 4.13.0-26-generic
, não só o Firefox, mas o Chromo também, inclusive abri três telas no Youtube, transmissões ao vivo ao mesmo tempo, e funcionou perfeitamente.
Acredito que possa ser utilizado como fonte de informação para todos aqueles que possam estar tendo problemas com o processador AMD e placa gráfica igual a minha que citei acima.

Um grande abraço

Olá.

De nada.

A instalação dos codecs não tem relação com a instalação e versão do kernel (e vice-versa). O que ocorre é que o kernel 4.13 que você está usando não tem o bug citado no tópico deste tutorial. Os codecs servem apenas para habilitar recursos multimídia, como por exemplo a execução de faixas de áudio MP3, de faixas de vídeo AVI, de faixas audiovisuais (áudio + vídeo) WEBM do YouTube etc. O fato de o sistema operacional ter os codecs instalados não faz o bug surgir no kernel ou ser eliminado do kernel: se o kernel tiver o bug, seu sistema irá "travar"/"congelar" independentemente de os codecs estarem ou não instalados. E, se o kernel não tiver o bug, seu sistema não irá "travar"/"congelar", independentemente de os codecs estarem ou não instalados...

...mas seu comentário foi importante porque acabou me lembrando de que eu precisava atualizar o tutorial. Agora o tutorial explica como instalar a versão 4.14.14 do kernel Linux, que também não tem o bug e é mais recente que a sua versão 4.13 e também mais recente (mais novo) que a versão 4.7.10 que eu vinha utilizando.

[marcos90]

Testei o kernel 4.14.14 e pelo menos  na minha maquina não deu certo , travou e reiniciou a sessão . 
Dos Kernels que testei até o momento :

- 4.8.17
- 4.9.78
- 4.10.17
- 4.13.16
- 4.14.14

somente o 4.8.17 rodou bem , apesar de ter travado  umas duas vezes durante quase 1 mês de uso intensivo . Já o bom e velho 4.7.10 rodou sem problemas . Realmente é uma pena isso ! Pois quando estou usando as versões mais novas como as 4.14.14 , noto uma diferença de performance , as páginas carregam mais rapidamente , tudo parece mais "suave" . Mas aí , acontece o travamento e adeus sessão  !   Pelo menos vou ficando com o 4.8.17  que por enquanto está dando para usar de boa no dia a dia . 

[Sampayu]

Testei o kernel 4.14.14 e pelo menos  na minha maquina não deu certo , travou e reiniciou a sessão . 
Dos Kernels que testei até o momento :

- 4.8.17
- 4.9.78
- 4.10.17
- 4.13.16
- 4.14.14

somente o 4.8.17 rodou bem , apesar de ter travado  umas duas vezes durante quase 1 mês de uso intensivo . Já o bom e velho 4.7.10 rodou sem problemas . Realmente é uma pena isso ! Pois quando estou usando as versões mais novas como as 4.14.14 , noto uma diferença de performance , as páginas carregam mais rapidamente , tudo parece mais "suave" . Mas aí , acontece o travamento e adeus sessão  !   Pelo menos vou ficando com o 4.8.17  que por enquanto está dando para usar de boa no dia a dia . 

Oi, Marcos, obrigado por reportar isso. Interessante saber disso, pois como até o momento eu não tive problema com o kernel 4.14.14 eu estava com a impressão de que ele estava 100% livre do bug. Mas, agora que você publicou seu relato, pelo visto a ausência de travamentos depende da configuração do hardware do computador em que o kernel está sendo executado.

Pelo visto, fiz bem em deixar no tutorial o supercomando para quem preferir instalar o bom e velho kernel versão 4.7.10.  No meu notebook (Dell Inspiron 5548) até agora (1 mês e meio de uso) não tive problemas com o kernel 4.14.14, mas se ele em algum momento acarretar congelamento do sistema e eu constatar que o culpado pelo congelamento é o kernel 4.14.14, retorno ao kernel 4.7.10 e reporto isso no tutorial. Se eu ficar sabendo de alguma versão de kernel posterior à 4.7.10 em que o bug foi corrigido, também reporto por aqui. Abraço.

[Sampayu]

Testei o kernel 4.14.14 e pelo menos  na minha maquina não deu certo , travou e reiniciou a sessão . 
Dos Kernels que testei até o momento :

- 4.8.17
- 4.9.78
- 4.10.17
- 4.13.16
- 4.14.14

somente o 4.8.17 rodou bem , apesar de ter travado  umas duas vezes durante quase 1 mês de uso intensivo . Já o bom e velho 4.7.10 rodou sem problemas . Realmente é uma pena isso ! Pois quando estou usando as versões mais novas como as 4.14.14 , noto uma diferença de performance , as páginas carregam mais rapidamente , tudo parece mais "suave" . Mas aí , acontece o travamento e adeus sessão  !   Pelo menos vou ficando com o 4.8.17  que por enquanto está dando para usar de boa no dia a dia . 

Embora meu notebook não esteja travando com o kernel 4.14.14, recentemente descobri que o kernel 4.14.14 estava "reclamando" que a versão de firmware¹ da CPU Intel é antiga. Eu vi isso nos logs do sistema. Se quiser testar para ver se o kernel que você está usando também está "reclamando" da versão de firmware da CPU Intel do seu computador, execute este comando, no terminal do shell, imediatamente após ligar o computador e efetuar login no sistema:

Código Selecionar Expandir

dmesg |grep -i microcode

Se o comando acima fizer aparecer na tela uma mensagem do tipo [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x25 (or later),² instale o pacote que atualiza o microcode da Intel. O comando é este:

Código Selecionar Expandir

sudo apt-get install intel-microcode iucode-tool -y ; sudo telinit 6

Não é possível modificar permanentemente o firmware de uma CPU (um processador): diferentemente de um BIOS, que pode ser substituído, o firmware de um processador não pode. A solução, portanto, consiste em instruir o sistema operacional a inicializar um firmware alternativo (mais novo) toda vez em que o sistema operacional estiver sendo inicializado (boot). Portanto, a instalação dos pacotes acima não atualizará o firmware que está dentro do processador, mas fará com que a cada boot (inicialização) do Linux um firmware alternativo (armazenado no disco rígido ou unidade de estado sólido do seu computador) seja carregado (inicializado) no lugar do firmware padrão que está embutido no processador.

Após você executar o comando acima e o computador reiniciar, execute novamente o comando dmesg |grep -i microcode. Caso o comando lhe mostre estas mensagens:²

Código Selecionar Expandir

microcode: microcode updated early to revision 0x25, date = 2017-01-27
microcode: sig=0x306d4, pf=0x40, revision=0x25
microcode: Microcode Update Driver: v2.2.

...então um microcode mais novo (uma versão alternativa e mais recente do firmware do processador do seu computador) está presente na unidade de armazenamento na qual o sistema operacional Linux está instalado, e esse microcode está sendo corretamente inicializado pelo sistema operacional Linux, durante o "boot".

...mas se o comando acima continuar lhe retornando a mesma mensagem de erro, experimente instalar também o pacote para microcode da AMD:

Código Selecionar Expandir

sudo apt-get install amd64-microcode -y ; sudo telinit 6

Após o microcode estar atualizado, você pode de repente instalar um kernel mais novo, como por exemplo o da versão 4.14.14, e verificar se o congelamento / travamento do sistema ocorre. Eu não sei se os congelamentos que estão ocorrendo no sistema operacional do seu computador estão sendo causados por algum conflito da versão do microcode do processador com a versão do driver de vídeo, mas não custa atualizar o microcode (mal não vai fazer: o pior que pode acontecer é não mudar nada) e testar se essa atualização melhora alguma coisa no funcionamento do processador e no comportamento do kernel em relação ao processador e à GPU que porventura esteja embutida no processador.


Notas de rodapé
¹ Um firmware é um pequeno programa que fica gravado no chip de um dispositivo eletrônico. O firmware facilita a interação de um ser humano (ou de outro programa) com o dispositivo no qual o firmware está instalado. O BIOS do computador, por exemplo, é um firmware: ele é um programa que permite que você configure o comportamento dos chips que se encontram na placa-mãe do computador.
² Algumas informações nas mensagens podem ser diferentes. No caso do meu computador, por exemplo, o comando informa que a versão do microcode precisa ser 0x25 ou posterior (o código hexadecimal 0x25 corresponde ao número decimal 37, portanto a versão 0x25 é a versão 37). A mensagem seguinte mostra "date = 2017-01-27", o que significa que em 27/01/2017 eu atualizei o microcode do processador. Caso você atualize o microcode em outro dia, a data mostrada ali evidentemente será a desse outro dia em que você atualizou o microcode.

[marcos90]

Não apareceu nenhuma mensagem de bug. A única diferença que reparei foi que  o driver do  4.8.17  parece ser mais antigo que o do 4.14.14  .

Kernell 4.8.17
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[    1.436515] microcode: sig=0x306a9, pf=0x2, revision=0x10
[    1.436545] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>

Kernell 4.14.14
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[    1.454860] microcode: sig=0x306a9, pf=0x2, revision=0x10
[    1.454896] microcode: Microcode Update Driver: v2.2.

[Sampayu]

Não apareceu nenhuma mensagem de bug. A única diferença que reparei foi que  o driver do  4.8.17  parece ser mais antigo que o do 4.14.14  .

Kernell 4.8.17
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[    1.436515] microcode: sig=0x306a9, pf=0x2, revision=0x10
[    1.436545] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>

Kernell 4.14.14
marcos@marcos-H67H2-M3:~$ dmesg |grep -i microcode
[    1.454860] microcode: sig=0x306a9, pf=0x2, revision=0x10
[    1.454896] microcode: Microcode Update Driver: v2.2.

Que bom que não apareceu mensagem de bug: sinal de que o kernel está sendo inicializado com um microcode adequado para o processador. O único lado negativo disso é que, se o microcode está atualizado, então os travamentos que você está eventualmente vivenciando não estão sendo provocados por causa da versão de microcode em uso para o processador, portanto o "culpado" pelo travamento é outro.

As diferenças de versão são normais: entre as versões de microcode disponíveis no sistema, cada kernel inicializa a versão mais adequada para que a interação dele (kernel) com o processador seja a melhor possível. O microcode é executado durante cada boot (inicialização do sistema operacional), então se você inicializar o sistema com uma versão de kernel diferente pode mesmo acontecer de outra versão de microcode ser inicializada junto com esse outro kernel.

[marcos90]

Fiz um teste usando o Kernel 14.14  Lowlatency e surpreendentemente funcionou bem durante 2 dias , mas travou como antes  .   Então mudei para o Kernel 13.16 Lowlatency e estou usando durante 3 dias sem problemas até agora .  Lembrando que quando testei o Kernel 13.16 Generic , o travamento acontecia em questão de minutos ou  horas após instalado .  Será que tem algo  a ver ?  Teoricamente meu processador é fraco ( Celeron G1610 Dual Core ) .   Sei que ainda é muito cedo para dar uma opinião formada sobre os travamentos  . mas postei só pra deixar o relato .

EDITADO : Atualizando ,  não deu certo    , no quarto dia começou a travar e reiniciar a sessão , igual das outras vezes .  Tentei com o v4.14.17 mas deu a mesma coisa inclusive travou em menos de 10 minutos quando ia abrir um arquivo no gerenciador Thunar .      .   Estou voltando para o Kernel  4.8.17 .   
Inclusive acho que podem apagar esta mensagem , já que não acrescentou nada ao tópico .

[Sampayu]

Fiz um teste usando o Kernel 14.14  Lowlatency e surpreendentemente funcionou bem durante 2 dias , mas travou como antes  .   Então mudei para o Kernel 13.16 Lowlatency e estou usando durante 3 dias sem problemas até agora .  Lembrando que quando testei o Kernel 13.16 Generic , o travamento acontecia em questão de minutos ou  horas após instalado .  Será que tem algo  a ver ?  Teoricamente meu processador é fraco ( Celeron G1610 Dual Core ) .   Sei que ainda é muito cedo para dar uma opinião formada sobre os travamentos  . mas postei só pra deixar o relato .

EDITADO : Atualizando ,  não deu certo    , no quarto dia começou a travar e reiniciar a sessão , igual das outras vezes .  Tentei com o v4.14.17 mas deu a mesma coisa inclusive travou em menos de 10 minutos quando ia abrir um arquivo no gerenciador Thunar .      .   Estou voltando para o Kernel  4.8.17 .   
Inclusive acho que podem apagar esta mensagem , já que não acrescentou nada ao tópico .

Oi. 

Eu ia comentar um pouco a respeito do kernel de baixa latência, mas daí me lembrei deste vídeo do Dionatan (blog "Diolinux") que explica superbem o que é kernel, latência e kernel low latency. Enfim: o vídeo é bem didático. Recomendo.

Em síntese: não vejo vantagem em você utilizar um kernel de baixa latência, a menos que você trabalhe com produção profissional de conteúdo audiovisual (filmes com áudio). O fato de o kernel ser de baixa latência não vai eliminar o bug, já que o problema de atraso na criação do ponteiro (razão do kernel panic) continuará presente.

[marcos90]

Surgiu uma dúvida aqui .  Quando o Ubuntu 16.04 foi lançado , o Kernel era 4.4.x ou 4.5.x .   Quem usava sem problemas  desde aquela época , ainda está usando o Kernel 4.4.x  até os dias de hoje   ?    Pergunto isso , pois queria testar essas versões mais antigas do que a 4.7.10 .
Quando baixei o Xubuntu 16.04 Xenial e instalei  , acho que foi em novembro de 2017 , não lembro qual o kernel original que veio com ele .