Fórum Ubuntu Linux - PT
Suporte Técnico => Sistema => Tópico iniciado por: zekkerj em 04 de Agosto de 2016, 16:28
-
Olá pessoal,
Como já comentei com vocês, precisei trocar o HD de meu note, e ele voltou com o Ubuntu 16.04 (http://ubuntuforum-br.org/index.php/topic,120401.0.html), 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:
[ 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?
-
É, 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?
-
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
-
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. :-\
-
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.
-
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").
-
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.
-
Meu medo é bloquear o módulo e zoar de vez o sistema de vídeo, já que é um sistema com chaveamento dinâmico. :-\
-
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 (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1608042).
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! :P
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 (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1608042/comments/31), 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):
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:
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):
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:
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. 8)
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!
-
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.
-
Mas eu te disse! Eu te disse! :P
Tem que trocar de kernel!
-
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. :P
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.
-
Mas eu te disse! Eu te disse! :P
Tem que trocar de kernel!
Realmente, você está certo. Escrevi mais para complementar aquele seu comentário, mas o que você escrevera está certinho. :)
-
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.
-
[...] 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. :)
-
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.
Eu entendi, só achei sua decisão muito conservadora.
De qualquer modo, cabe a cada um pesar os prós e contras que vê nessa decisão de instalar (ou de não instalar) um kernel RC. Afinal, o computador é seu.
De minha parte, decidi instalar o kernel RC da versão 4.6 porque tenho a impressão de que demorará até os kernels C receberem upstream patch (correção proveniente da versão 4.6). Já faz duas semanas que reportei qual foi o commit que causou a eliminação do bug, mas até agora nenhum kernel developer se manifestou a respeito do que será feito. A priori, os códigos dos kernels v4.6-rc1-wily e v4.5.7-yakkety precisarão ser confrontados, para se verificar quais as diferenças entre os dois códigos-fonte, e daí rastrear o que foi que eliminou o bug. Isso talvez demore meses. Já vi bug de kernel demorar mais de 2 anos para ser corrigido. Uma hora o patch há de ser construído e ser aplicado aos kernels anteriores ao 4.6-rc1 (e daí o próximo apt-get upgrade atualizará os kernels do repositório), mas até lá... Haja paciência. ::)
Eu custei a largar o XUbuntu 14.04: quando larguei, foi porque o Catalyst deu pane e eu estava sem paciência para reinstalar e configurar tudo de novo. Foi quando decidi fazer uma instalação "limpa" do XUbuntu 16.04.1 (eu não queria instalar a versão 16.04, mas a versão 16.04.1 atualmente disponibilizada já vem com alguns bugs corrigidos, está bem mais estável). Ainda assim, deparei-me com esse bug no kernel. Mas contornei com a instalação do kernel RC e agora está tudo muito bom. :)
-
Esqueci de comentar uma coisa interessante: realizaram diversos benchmarks (testes de desempenho) comparando o desempenho gráfico do Ubuntu 14.04 usando fglrx (driver gráfico proprietário da AMD) com o desempenho gráfico do Ubuntu 16.04 usando amdgpu/radeon (os drivers de código aberto para dispositivos gráficos da AMD). O resultado: com os drivers amdgpu/radeon o desempenho de 5 diferentes GPU (chips gráficos) da AMD foi superior ao desempenho obtido com o driver fglrx. :D
Fonte: http://www.phoronix.com/scan.php?page=article&item=ubuntu-1604-amd&num=2
Para quem acessar o link acima: as barras azuis representam o desempenho dos dispositivos gráficos AMD no Ubuntu 14.04 com driver fglrx. Já as barras vermelhas representam o desempenho dos mesmos dispositivos gráficos AMD no Ubuntu 16.04 usando driver amdgpu ou radeon (o Ubuntu seleciona ou o driver amdgpu ou o driver radeon, dependendo do dispositivo gráfico AMD que esteja em uso).
-
Parabéns Sampayu, pela aula no post anterior de como resolver o pepino com as Radeons e o Ubuntu 16.04!
Não querendo abusar, mas já abusando...
Não rola um Tuto no Dicas e Truques? ::)
-
(...)Por isso eu sou bastante conservador no meu sistema.
Eu entendi, só achei sua decisão muito conversadora.
Conversador??? :'(
-
(...)Por isso eu sou bastante conservador no meu sistema.
Eu entendi, só achei sua decisão muito conversadora.
Conversador??? :'(
Eita, erro de digitação. :-[ Kkkkkk, ouquêi, tá corrigido, obrigado. ;D
-
Parabéns Sampayu, pela aula no post anterior de como resolver o pepino com as Radeons e o Ubuntu 16.04!
Não querendo abusar, mas já abusando...
Não rola um Tuto no Dicas e Truques? ::)
Vou criar (na verdade já estou criando) um tutorial (http://ubuntuforum-br.org/index.php/topic,120620.0.html). :)
-
Parabéns Sampayu, pela aula no post anterior de como resolver o pepino com as Radeons e o Ubuntu 16.04!
Não querendo abusar, mas já abusando...
Não rola um Tuto no Dicas e Truques? ::)
Vou criar (na verdade já estou criando) um tutorial. :)
Valeu!
-
Ao zekkerj e a quem mais possa interessar: como eu havia comentado antes, os *Ubuntu 16.04 estão vindo com kernel versão 4.4, que não funciona com o driver gráfico proprietário fglrx, da fabricante AMD. Além disso, o kernel 4.4 possui um bug que dificulta o funcionamento dele com os drivers de código aberto amdgpu e radeon, usados para o adequado funcionamento das GPU (unidades de processamento gráfico) da AMD no sistema GNU/Linux: o bug provoca um kernel panic do qual resulta o completo travamento/congelamento do computador.
Eu havia comentado também que esse bug está presente tanto nos kernels 4.4.X quanto nos 4.5.X, e que por isto a solução consistia em instalar o kernel 4.6-rc1 ou alguma versão posterior. Porém, na ocasião estavam disponíveis somente kernels versão 4.6, e todos do tipo RC, que não são considerados estáveis (embora kernels RC sejam "praticamente estáveis"). De modo geral, não há um risco significativo em se instalar e usar um kernel RC: eu mesmo usei o 4.6-rc1 durante quase 1 mês. Mas há quem sinta receio de usar kernel RC. Por isto, informo que o kernel Linux passou por atualizações e no momento a mais recente versão estável do kernel Linux passou a ser a 4.7.2. Eu migrei para esse kernel, realizei uma série de testes e nenhum problema ocorreu.
Por conta disso, hoje eu atualizei meu tutorial (http://ubuntuforum-br.org/index.php/topic,120620.0.html): agora ele ensina a instalar o kernel estável 4.7.2.
Minha sugestão é que quem estiver com algum problema relacionado ao chip gráfico AMD do computador instale o kernel 4.7.2. Se não souber como se instala um kernel mais novo, basta seguir as instruções do tutorial.
-
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. :-\
o inxi pode te dar informações mais precisas, apenas lembrando:
inxi -FxZ
T+
-
Olá Creto,
Estou aguardando esses novos kernels serem disponibilizados nos repositórios pra intalá-los, não vou ficar dando murro em ponta de faca.
-
Estou aguardando esses novos kernels serem disponibilizados nos repositórios pra intalá-los, não vou ficar dando murro em ponta de faca.
A previsão é que o Ubuntu 16.10 saia com o kernel 4.8, que também deve ser incorporado à LTS release 16.04.2, previsto para fevereiro/2017.
A versão 14.04 no release 5 fica mesmo no kernel 4.4.