Kubuntu 16.04 + Radeon R7 M260/M265 = Kernel Panic e Travamento ao suspender

[zekkerj]

Olá pessoal,

Como já comentei com vocês, precisei trocar o HD de meu note, e ele voltou com o Ubuntu 16.04, que eu, como de costume, transformei em Kubuntu removendo o Unity e instalando em seu lugar o KDE.

Meu "namoro" com o KDE 5 tem progredido razoavelmente, e pelo menos enquanto estou em frente à máquina, tudo funciona tão bem quanto antes.

O problema, no entanto, parece atacar quando me afasto um pouco... se eu fecho a tampa do notebook, é comum que ele trave. Da última vez, além de travar, ele acusou um kernel panic enquanto eu tentava recuperar. Kernel panic esse que eu já tinha visto quando tentava desligar a máquina.

Fuçando um pouco, descobri que a máquina tem 2 placas de vídeo (Intel Broadwell-U i915) e AMD Radeon R7 M260/265. Digo descobri, mesmo depois de um ano usando a máquina, pois como não a uso pra jogos pesados, isso nunca me fez falta, assim não foi das coisas com que me preocupei quando a comprei.

Bem, estou observando algumas coisas interessantes:

1. Só a GPU intel parece estar ativa. Aparentemente é pq os drivers AMD pro 16.04 ainda não estão estáveis.

2. Todos os kernel panics estão associados ao driver "amdgpu", apesar dele não estar em uso.

3. Há vários erros durante o boot, como esses:

Código: [Selecionar]

[   35.323080] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 0 (-2).
[   35.323090] [drm:amdgpu_resume [amdgpu]] *ERROR* resume 4 failed -2
[   35.323100] [drm:amdgpu_resume_kms [amdgpu]] *ERROR* amdgpu_resume failed (-2).
[   35.323219] [drm:amdgpu_sched_run_job [amdgpu]] *ERROR* Error scheduling IBs (-22)
[   35.323237] [drm:amd_sched_main [amdgpu]] *ERROR* Failed to run job!
[   35.323307] [drm:amdgpu_sched_run_job [amdgpu]] *ERROR* Error scheduling IBs (-22)
[   35.323321] [drm:amd_sched_main [amdgpu]] *ERROR* Failed to run job!
[   35.323461] [drm:amdgpu_sched_run_job [amdgpu]] *ERROR* Error scheduling IBs (-22)
[   35.323476] [drm:amd_sched_main [amdgpu]] *ERROR* Failed to run job!
[   35.323572] [drm:amdgpu_sched_run_job [amdgpu]] *ERROR* Error scheduling IBs (-22)
[   35.323586] [drm:amd_sched_main [amdgpu]] *ERROR* Failed to run job!
[   41.829085] [drm] PCIE GART of 2048M enabled (table at 0x0000000000040000).
[   42.066253] [drm:gfx_v8_0_hw_init [amdgpu]] *ERROR* amdgpu: cp failed to lock ring (-2).
[   42.066260] [drm] ring test on 0 succeeded in 1 usecs
[   42.066449] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 1 (-2).
[   42.066463] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 2 (-2).
[   42.066484] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 3 (-2).
[   42.066496] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 4 (-2).
[   42.066507] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 5 (-2).
[   42.066519] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 6 (-2).
[   42.066531] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 7 (-2).
[   42.066542] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: cp failed to lock ring 8 (-2).
[   42.066570] [drm] ring test on 9 succeeded in 7 usecs
[   42.066588] [drm:sdma_v2_4_ring_test_ring [amdgpu]] *ERROR* amdgpu: dma failed to lock ring 10 (-2).
[   42.066596] [drm:amdgpu_resume [amdgpu]] *ERROR* resume 5 failed -2
[   42.066603] [drm:amdgpu_resume_kms [amdgpu]] *ERROR* amdgpu_resume failed (-2).

4. O "lshw" não consegue identificar corretamente a placa AMD como um dispositivo de vídeo:

$ sudo lshw -C display,generic
  *-display
       descrição: VGA compatible controller
       produto: Broadwell-U Integrated Graphics
       fabricante: Intel Corporation
       ID físico: 2
       informações do barramento: pci@0000:00:02.0
       versão: 09
       largura: 64 bits
       clock: 33MHz
       capacidades: msi pm vga_controller bus_master cap_list rom
       configuração: driver=i915 latency=0
       recursos: irq:49 memória:c1000000-c1ffffff memória:d0000000-dfffffff porta de E/S:5000(tamanho=64)
  *-generic
       descrição: Unassigned class
       produto: Illegal Vendor ID
       fabricante: Illegal Vendor ID
       ID físico: 0
       informações do barramento: pci@0000:04:00.0
       versão: ff
       largura: 32 bits
       clock: 66MHz
       capacidades: bus_master vga_palette cap_list rom
       configuração: driver=amdgpu latency=255 maxlatency=255 mingnt=255
       recursos: irq:50 memória:b0000000-bfffffff memória:c0000000-c01fffff porta de E/S:3000(tamanho=256) memória:c2000000-c203ffff memória:c2040000-c205ffff

5. A saída do "lspci" também é um pouco estranha:

$ lspci
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 (rev e3)
00:1c.2 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1c.3 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #4 (rev e3)
00:1c.4 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #5 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07)
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
04:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265] (rev ff)

$ lspci -x -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
00: 86 80 16 16 07 04 90 00 09 00 00 03 00 00 00 00
10: 04 00 00 c1 00 00 00 00 0c 00 00 d0 00 00 00 00
20: 01 50 00 00 00 00 00 00 00 00 00 00 28 10 43 06
30: 00 00 00 00 90 00 00 00 00 00 00 00 ff 01 00 00

$ lspci -x -s 04:00.0
04:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265] (rev ff)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Já a saída do "inxi -Gxxx" mostra informação um pouco mais consistente:
[qiuote]$ inxi -Gxxx
Graphics:  Card-1: Intel Broadwell-U Integrated Graphics bus-ID: 00:02.0 chip-ID: 8086:1616
           Card-2: Advanced Micro Devices [AMD/ATI] Topaz XT [Radeon R7 M260/M265]
           bus-ID: 04:00.0 chip-ID: 1002:6900
           Display Server: X.Org 1.18.3 drivers: ati,intel,amdgpu (unloaded: fbdev,vesa,radeon)
           Resolution: 1920x1080@60.05hz
           GLX Renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2)
           GLX Version: 3.0 Mesa 11.2.0 Direct Rendering: Yes
[/quote]

Não faço muita questão dos gráficos da Radeon, mas tenho ojeriza a travamentos e kernel panics.

Fico pensando se vale a pena bloquear o driver amdgpu, o que vcs me relatam a respeito?

[galactus]

É, a coisa tá feia mesmo pra gente que usa ATI.  Meu PC é um A10, também um R7.  Ainda não atualizei por causa dos Bugs!

Mas tem uma luz no fim do túnel.  O Bug é oficial: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579374


A solução encontrada até agora é fazer o upgrade do kernel para versão 4.6 do PPA mainline!

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc7-wily/


Quem usou diz que o problema parou!

Vale a tentativa.

Outros dizem que não pode passar do kernel 4.4.0-16.  Muitos bugs com as versões seguintes!

Você não se arrisca com kerneis alternativos?

[druidaobelix]

Havia abordado anteriormente a questão nesse tópico:

http://ubuntuforum-br.org/index.php/topic,120102.msg659644.html#msg659644

Depois, num outro tópico, o /nomade/ disse que conseguiu por para funcionar o AMDGPU-PRO, que está em fase beta, numa R7 260X e ainda dá a receita do bolo. Talvez valha a pena tentar ativar e ver o que dá. Confere aqui:

http://ubuntuforum-br.org/index.php/topic,119532.msg659008.html#msg659008

[zekkerj]

O que está me deixando mais bolado é esse bloco de bytes na saída do "lspci -x", para esse dispositivo. É como se o dispositivo não estivesse sendo lido direito...

Enfim; não faço questão do dispositivo ativo, só não quero que ele me atrapalhe.

[druidaobelix]

Pois é, o fato de um módulo não estar carregado não quer dizer que o kernel não tentou carregá-lo antes e ainda que não possa ter havido chamadas provenientes de outras dependências que por isso ou por aquilo precisam do módulo e então o chamam para a execução de algum serviço.

Bem, se não quer e não precisa mesmo do amdgpu suponho que seja possível bloqueá-lo através do método tradicional do blacklist em:

/etc/modprobe.d/amdgpu.conf

blacklist amdgpu

Porém, e agora no 'achismo' mesmo já que não tenho a própria nem algo parecido, talvez seja o caso de além disso implementar o bloqueio também já como parâmetro de kernel, o que seria uma segurança adicional que o módulo não será chamado na carga inicial do sistema.

Como falei, não sei mesmo se funciona, é só palpite baseado em raciocínio abstrato, sem possibilidade de verificação, mas acrescentaria na linha de carga o parâmetro nomodeset em /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

O fundamento abstrato é que o amdgpu requer o KMS (Kernel mode setting) é mandatório e habilitado por default.

Há uma questão adicional que é a chamada posterior do módulo a partir de algum outro módulo-dependente, também não sei se é realmente o caso, sobretudo em se tratando de um módulo tão essencial quanto esse, mas em tese poderia ocorrer.

O raciocínio vem amparado nesse afirmação:

"The blacklist command will blacklist a module so that it will not be loaded automatically, but the module may be loaded if another non-blacklisted module depends on it or if it is loaded manually. "

Se as providências anteriores por si só não funcionaram, então então em tese Isso pode ser contornado acrescentando ao arquivo blacklist.conf (ou amdgpu.conf):

install module_name /bin/false

portanto:

install amdgpu /bin/false

Vai precisar de:

update-initramfs -u

reboot

Quanto a questão do dump apresenta o binário FF em todas as posições, a única interpretração que consigo ter no momento e considerando que o amdgpu não foi carregado é apenas que eletronicamente não há diferença de tensão, ou seja, não significa nada, é amorfo.

[zekkerj]

Não, vc não entendeu... o módulo está carregado sim, só não está em uso --- por algum motivo que ainda não descobri, a placa de vídeo AMD não entra em uso, e quando fiz um teste pra forçar a sua carga, terminei novamente com o sistema travado (o teste era executar o comando "DRI_PRIME=1 glxgears").

[druidaobelix]

Não, vc não entendeu... o módulo está carregado sim, só não está em uso --- por algum motivo que ainda não descobri, [...]

Eita, é verdade, ele está lá mesmo conforme o lshw, na pressa não vi. 

configuração: driver=amdgpu latency=255 maxlatency=255 mingnt=255

Mas isso só reforça o que vem sendo dito, inclusive naqueles links passados antes, não há suporte na versão 16.04 ou apenas de forma experimental para R9 e **algumas** versões R7, como o próprio /nomade/ já havia ressaltado naquele link.

[zekkerj]

Meu medo é bloquear o módulo e zoar de vez o sistema de vídeo, já que é um sistema com chaveamento dinâmico.

[Sampayu]

Meu medo é bloquear o módulo e zoar de vez o sistema de vídeo, já que é um sistema com chaveamento dinâmico.

Tenho um notebook Dell Inspiron 5548. Esse notebook usa gráficos híbridos (possui duas GPU - unidades de processamento gráfico - ao invés de apenas uma): uma das GPU é da Intel e fica embutida no processador i7, enquanto a outra GPU é um chip onboard da AMD, modelo Radeon Topaz XT, também denominada R7 M260/M265. Fiz upgrade do XUbuntu 14.04 para o 16.04 (ambos de 64 bits) e o mesmo problema ocorreu. Trata-se de um bug que eu inclusive reportei lá no Launchpad.

Descrição do problema: os *Ubuntu (Ubuntu, XUbuntu, KUbuntu etc.) versão 16.04 vêm com kernel da série 4.4.X. Esse tipo de kernel do *Ubuntu não funciona com o módulo de kernel fglrx (driver gráfico proprietário da AMD), e por isso os *Ubuntu 16.04 vêm com os módulos de kernel amdgpu e radeon pré-instalados: esses módulos são de código aberto e visam substituir o módulo proprietário fglrx. O kernel 4.4.X (ou posterior) automaticamente seleciona inicializar ou o módulo/driver amdgpu ou então o módulo/driver radeon: isso dependerá do modelo da sua GPU AMD, modelo esse que o kernel identifica antes de decidir qual driver inicializar. Enfim: é automática a instalação e inicialização de um dos dois drivers de código aberto que vêm nos *Ubuntu 16.04...

...porém, os kernels 4.4.X têm um bug que faz com que o driver amdgpu/radeon seja inicializado no momento errado. Isso gera um erro de ponteiro inválido, o que por sua vez induz o kernel panic e o consequente travamento.

Usar a função nomodeset dentro do GRUB realmente contorna o problema, porém isso faz com que o desempenho de ambas as GPU (tanto Intel quanto AMD) torne-se baixo, lento, uma verdadeira porcaria. Os gráficos 3D ficam com um péssimo desempenho e as conexões HDMI param de funcionar. Enfim: não recomendo a ninguém usar nomodeset!

Eu executei um reverse commit bisect (uma espécie de "caça ao bug" que a gente executa de trás para a frente, desde o primeiro kernel livre do bug até o primeiro kernel problemático) e descobri que o bug está presente em todos os kernels versão 4.4.X e 4.5.X, portanto nem percam tempo testando esses kernels.

Conforme eu comentei no relatório do bug, após o reverse commit bisect o que eu descobri foi que a partir do primeiro kernel 4.6.X (que é o kernel versão 4.6-rc1 / compilação 4.6.0-040600rc1-generic) o bug não existe mais.

Portanto, nem é necessário instalar o kernel 4.6-rc7: até mesmo o kernel 4.6-rc1 (o primeiro da série "rc") já elimina o bug.

Segue um passo-a-passo para instalar o kernel 4.6-rc1:

1) Acesse http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/

2) Faça download dos três arquivos para a sua arquitetura de sistema. Vou presumir que você salvará os arquivos .DEB dentro de sua pasta pessoal de Download (/home/seu-nome-de-usuário/Downloads).

2.1) Caso seu sistema seja de 64 bits, faça download destes arquivos (salve-os em sua pasta pessoal de Downloads):
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/linux-headers-4.6.0-040600rc1_4.6.0-040600rc1.201603261930_all.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/linux-headers-4.6.0-040600rc1-generic_4.6.0-040600rc1.201603261930_amd64.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/linux-image-4.6.0-040600rc1-generic_4.6.0-040600rc1.201603261930_amd64.deb

2.2) Caso seu sistema seja de 32 bits, faça download destes arquivos (salve-os em sua pasta pessoal de Downloads):
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/linux-headers-4.6.0-040600rc1_4.6.0-040600rc1.201603261930_all.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/linux-headers-4.6.0-040600rc1-generic_4.6.0-040600rc1.201603261930_i386.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/linux-image-4.6.0-040600rc1-generic_4.6.0-040600rc1.201603261930_i386.deb

Nota: caso não saiba se seu Linux é de 32 ou de 64 bits, execute o comando uname -i. Se o resultado do comando tiver 64, seu sistema é de 64 bits. Caso contrário, seu sistema é de 32 bits.

3) Abra o emulador do shell (terminal de comandos) e execute este comando de instalação (estou presumindo que você salvou os pacotes .DEB em sua pasta pessoal de downloads):

Código: [Selecionar]

sudo dpkg -i ~/Downloads/linux-*deb
Nota: o caractere ~ (til) é um atalho para a sua pasta pessoal.

4) Execute este comando para poder atualizar novamente o GRUB e em seguida forçar a reinicialização do sistema:

Código: [Selecionar]

sudo update-grub ; sudo telinit 6
5) Após reiniciar seu computador, execute o comando abaixo para verificar a versão do kernel que o seu sistema está de fato executando (se tudo deu certo, o resultado do comando começará com o texto 4.6):

Código: [Selecionar]

uname -r
6) Uma vez que seu computador esteja executando o *Ubuntu Linux com kernel versão 4.6.X, volte ao emulador de terminal do shell e execute este comando:

Código: [Selecionar]

DRI_PRIME=1 glxgears
Se as engrenagens apareceram, estão se movimentando e a sua tela não travou, o bug não está presente. Deixe as engrenagens rodando e execute outras tarefas, como p.ex. abrir seu navegador, executar um MP3, assistir a um vídeo no YouTube, jogar algum jogo que use gráficos 3D, executar alguma proteção de tela que seja 3D etc. Se mesmo assim nada travar, o upgrade do kernel deu certo.

PS: não adicione os drivers amdgpu e radeon à blacklist (lista negra). O problema é no kernel, não nos drivers! E não existe driver alternativo que funcione com GPU da AMD em sistemas *Ubuntu que usem kernel 4.4.X ou posterior!

[zekkerj]

Rapaz, uma coisa que me deixa muito de pé atrás é marretar pacote fora dos repositórios, principalmente um pacote de kernel.
Acho que vou me aguentar mais um pouco, até esse kernel entrar no repositório.

[galactus]

Mas eu te disse! Eu te disse! 

Tem que trocar de kernel!

[Sampayu]

Rapaz, uma coisa que me deixa muito de pé atrás é marretar pacote fora dos repositórios, principalmente um pacote de kernel.
Acho que vou me aguentar mais um pouco, até esse kernel entrar no repositório.

Ué, mas esses são kernels oficiais do Ubuntu: você não estará pegando o kernel a partir de repositórios de terceiros.

Como o próprio nome deixa subentendido, o kernel 4.6-rc1 é um kernerl RC. A abreviatura RC significa Release Candidate, que significa algo mais ou menos assim: "kernel que é candidato para ser introduzido na próxima versão do Ubuntu". Embora um kernel RC não seja a versão final, ele é uma versão muito próxima da versão final, porque já está concluído, não recebe mais nenhum novo recurso, nenhuma nova função etc.: o único código que pode eventualmente vir a ser introduzido em um kernel RC é algum patch de correção, caso algum bug seja identificado no kernel e sanado antes de ele se tornar uma versão C (current/corrente/atual).

Eu já estou há duas semanas usando esse kernel direto, sem problema nenhum: analiso o dmesg e outros logs do sistema, não tenho visto nada de errado, o computador está funcionando normalmente, nenhum sobreaquecimento nem nada do gênero.

Enfim: acho que abdicar de usar um kernel RC apenas porque ele não consta no repositório da distribuição é mais desvantajoso do que vantajoso. Nenhum kernel é perfeito, até mesmo os kernels C têm bugs. Abdicar de um kernel RC é praticamente condenar a si próprio a mazela de ter de conviver com o kernel 4.4.X, que causa kernel panic, travamentos que requerem que você desligue seu computador "no dedo" (isso é prejudicial ao hardware, pode inclusive danificar algum componente eletrônico do seu computador. Eu já perdi um HD por ter tido de desligar o computador "no dedo", pressionando o botão power). Sei lá, parece-me mais prejudicial insistir no kernel 4.4.X (ou no uso de nomodeset, que basicamente inutiliza sua GPU exceto para as funções VGA mais elementares) do que instalar um kernel RC livre de um bug sério como esse.

Espero que repense sua decisão.

[Sampayu]

Mas eu te disse! Eu te disse! 

Tem que trocar de kernel!

Realmente, você está certo. Escrevi mais para complementar aquele seu comentário, mas o que você escrevera está certinho.

[zekkerj]

Vc não entendeu... esse kernel pode até ser um kernel oficial, mas ele ainda não está no repositório. Ainda é preciso fazer uma instalação personalizada. Sim, eu sou capaz de fazê-la, faço coisas bem mais complicadas que isso... já ressuscitei servidor com glibc corrompida, eu em uma cidade e o servidor em outra. Mas na minha máquina quero tranquilidade, sabe? Por isso eu sou bastante conservador no meu sistema.

[druidaobelix]

[...] ma coisa que me deixa muito de pé atrás é marretar pacote fora dos repositórios, principalmente um pacote de kernel.

Tenho instalado e usado o kernel 4.6.3 (release 4.6.3-04-603) com o Ubuntu 16.04, já há um bom tempo e pelo menos até agora não identifiquei nenhum problema em relação a isso. Claro que o ideal (e até por comodidade) é seguir o passo-a-passo da distribuição, fazendo as atualizações no automático, mas quando há um problema efetivo, pode ser uma solução.

De toda forma, isso é quase rezar missa para o padre, certamente você melhor que ninguém consegue bem avaliar o quadro aí existente.