Sampayu

De nada. O commit bom é bem simples, apenas reativa o gerenciamento de energia do driver para dispositivos gráficos AMD. Acredito que não quebrará nada.

Olá, @Marcos FRM e quem mais esteja interessado neste assunto: concluí o RCB (reverse commit bisect). Surpreendentemente (digo: ao contrário do que eu imaginava), o primeiro commit a remover o bug não está na versão 4.6-rc1 do kernel, mas sim na 4.6-rc4. Trata-se do commit e9bef455af8eb0e837e179aab8988ae2649fd8d3: Revert "drm/amdgpu: disable runtime pm on PX laptops without dGPU power control" - This reverts commit bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1. Anexei um arquivo PDF contendo a tabela de commits e compilações que executei. Por causa da "surpresa" ao constatar que o kernel 4.6-rc1 também tinha o bug, tive de executar várias outras compilações. No total, foram 26 - daí a minha demora em voltar aqui. Meu report completo encontra-se disponível aqui (em inglês). Após isso, meu bug report no Launchpad passou a receber prioridade alta. Resta saber quanto tempo demorarão para aplicar a correção downstream (que é quando você pega uma correção presente numa versão mais recente e a aplica a versões mais antigas: no caso, nos kernels 4.4.X e 4.5.X). rcb.pdf

Obrigado.

Sobre o kenerl estável 4.7.2: fiz uns testes e ele realmente não tem o bug. Por isto, atualizei o tutorial. Sobre o bisect, estou fazendo aos poucos, desde a versão 4.5 do kernel até a versão 4.6-rc1: são mais de 6 mil commits, a compilação é demorada e eu tenho de testar uma por uma. Graças a técnica de bisect, não terei de testar os mais de 6 mil commits (imagine ter de compilar e testar kernel mais de 6 mil vezes...), mas mesmo com a técnica de bisect serão pelo menos 12 (provavelmente 13 ou 14) compilações diferentes que eu terei de testar até chegar ao commit responsável pela remoção do bug. No momento, estou compilando o 8º teste. Do teste 1 ao 7 o bug está presente, então, como já é de se esperar, o bug provavelmente foi removido numa versão do kernel 4.5 muito próxima à da compilação do "novo" kernel 4.6-rc1. Quando eu chegar a um resultado eu publico, aqui.

@AmarildoJr Mmmm, interessantes essas informações a respeito do kernel 4.9. Não sabia desse esforço em darem suporte a essas placas GCN. No meu cotidiano eu raramente testo kernels e módulos, geralmente só quando me deparo com um bug: aí eu saio à caça do problema. É por isso que acabo não ficando sabendo dessas atividades que estão em andamento. Também por isso (por não ser um hábito eu ver a última versão do kernel estável e logo atualizá-la), já há alguns dias eu não olhava as pastas em kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D. Mas agora fui lá e vi que foram criadas as pastas dos kernels 4.7 (4.7.0), 4.7.1 e 4.7.2. É impressionante como avança rápido o desenvolvimento do kernel do Linux! Dá até pena de comparar com o Windows. Melhor não comparar, hehe... Por outro lado, isso me deixa um pouco "perdido", pois fico sem saber qual kernel sugerir aos usuários: enquanto estou testando um, pode ser que outro mais recente surja e esteja igualmente livre do bug. Meu tutorial ficou obsoleto muito rapidamente, rs. De qualquer modo, seguindo a lógica de sempre se preferir o kernel stable ante o release candidate, o mais lógico me parece ser recomendar aos usuários a instalação da última versão do 4.7 mesmo. Como lá em kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D eu vi as pastas 4.7, 4.7.1 e 4.7.2 (e em www.kernel.org consta que a última versão estável é a 4.7.2), pelo visto o melhor a fazer é eu testar o kernel 4.7.2, daí se nada de anormal ocorrer durante alguns dias, atualizo o tutorial. Você pelo visto é entusiasta do desenvolvimento do kernel. Obrigado por me avisar a respeito dessas versões mais recentes do kernel.

Eu testei 4.6-rc1, o 4.6-rc5 e o 4.6-rc7. Como estou usando o kernel 4.6-rc1 há cerca de 1 mês e não tive problema nenhum, é a versão em que atualmente confio mais, o que não significa que os posteriores darão problema. Mas esses kernels passam por muitas alterações e eu não sei como eles irão se comportar nos computadores dos outros, no longo prazo. Enfim: escolhi o 4.6-rc1 para fazer o tutorial mais por ser o que estou usando mesmo, por ser o que eu posso confirmar que se encontra realmente bem estável. Quem quiser usar um kernel mais recente, eu sugeriria usar o 4.6-rc7, que foi um que usei por pouco mais de 2 dias contínuos (deixei o notebook ligado mais de 48h consecutivas, executando diversas tarefas) e não deu problema. Eu também cheguei a instalar e testar o 4.8-rc1, e ele também funcionou, porém quando eu o desinstalei ocorreu um problema estranho no meu GRUB e também no módulo amdgpu: tive de reinstalar ambos. Não entendi por que isso ocorreu, mas me deu um trabalhinho para recuperar e conseguir voltar a usar meu 4.6-rc1. São essas coisas esquisitas e inesperadas que me deixam com receio de recomendar a instalação do kernel mais novo: à medida que os kernels vão sendo atualizados e novas versões vão surgindo, bugs vão sendo eliminados deles porém outros bugs vão surgindo. Como o 4.6-rc1 é o que estou usando no dia-a-dia e já constatei que está realmente estável, acabei achando melhor recomendar esse com o qual sinto mais segurança. De qualquer modo, acredito que o tutorial esteja intuitivo o suficiente para que os usuários mais avançados consigam usar a lógica do tutorial para instalar alguma versão mais recente, se quiser. Nos fóruns em língua inglesa há alguns usuários indicando a instalação do 4.6-rc7. Após fazer o RCB posso de repente instalar o 4.6-rc7 e testar por uns dias. Se o kernel se mostrar estável, aí atualizo o tutorial. O importante é livrar os usuários do bug (independentemente da versão de kernel que se instale): quando eu ainda não sabia desse bug, estava já ficando desesperado, porque o computador "congelava" toda hora e com isso me obrigava a ficar desligando o computador "no dedo", o que é péssimo e pode inclusive danificar algum componente eletrônico. Se eu testar o 4.6-rc7 (ou se alguém que tenha computador com GPU AMD decidir instalar o 4.6-rc7 e testar) por alguns dias, e após isso ficar constatado que o 4.6-rc7 não apenas está livre do bug como também está estável (aparentemente não possui nenhum bug novo que impeça o uso regular do computador), atualizo o tutorial. Mas vamos por partes, rs: ainda tenho de arrumar tempo pra fazer o RCB. Será uma ajuda bem-vinda se algum usuário de GPU AMD decidir testar o kernel 4.6-rc7 e puder confirmar que ele também está bem estável.

O Christopher M. Penalver (Launchpad) pediu para eu realizar um reverse commit bisect (RCB), que é um processo que possibilita investigar qual foi o bad commit que causou o bug no kernel. Se eu fizer isso e encontrar o último commit ruim e o primeiro commit bom, ele vai investigar o diff desses commits para verificar quais as mudanças realizadas no código que resultaram na eliminação do bug. Deste modo, teoricamente ele conseguirá identificar qual é o bug e daí aplicar o patch downstream, ou seja, corrigir todos os kernels 4.4 e 4.5... ...mas ele me pediu isso no dia 28/08 e eu ainda não tive tempo de parar para fazer o RCB. Tenho pouco tempo livre, e fazer RCB é trabalhoso e demorado. Pretendo fazer, para que corrijam os kernels, mas veja que estamos já entrando em setembro, daqui a pouco chega outubro e o *Ubuntu 16.10 será lançado. Enfim: a minha sugestão é que quem estiver com esse problema não fique aguardando um eventual kernel 4.4 corrigido. O mais prático, fácil e cômodo de se fazer é seguir o que expliquei lá no tutorial mesmo: baixar os pacotes do kernel 4.6-rc1 e instalá-los. Assim é bem mais cômodo e deixa o computador funcional.

Bacana, obrigado. Vou ficar mais ligado nesses tópicos Linux que surgem por aqui.

Fiz um tutorial explicando como resolver esse problema: http://ubuntuforum-br.org/index.php/topic,120620.0.html (o uso do kernel 4.6-rc1 é preferível, por ser atualmente mais estável, por isso no tutorial eu ensino a instalação do kernel 4.6-rc1)

Somente agora vi este tópico, há tempos não contribuo por aqui. Resolvi efetuar login e comentar que meu notebook é o mesmo que o seu: um notebook Dell Inspiron 5548. Ele vem com gráfico híbrido: uma GPU (unidade de processamento gráfico) Intel Broadwell-U integrada (embutida na CPU) e também uma GPU AMD/ATI Topaz XT (modelo Radeon R7 M260/M265). Alguns kernels do Linux dão problema com computadores que têm gráficos híbridos, não lidam direito com dois drivers de vídeo simultâneos (esses drivers são módulos do kernel, daí a importância de o kernel ser capaz de lidar com tais drivers). Quando eu ainda usava o XUbuntu 14.04, o driver gráfico da Intel (esse módulo chama-se i915) funcionava perfeitamente com os kernels versão 3.X, porém o gráfico proprietário da AMD (um módulo denominado fglrx), embora funcionasse muito melhor que o driver AMD de código aberto (módulo amdgpu), era bastante chato de instalar: um verdadeiro parto! Mas funcionava muito bem. Porém, com o advento do *Ubuntu (Ubuntu, XUbuntu, KUbuntu etc.) versão 16.04 (que vem com kernel versão 4.4.X) as coisas mudaram: a AMD desistiu de continuar desenvolvendo o driver fglrx e, por isto, a partir do 16.04 o kernel vem por padrão com o módulo amdgpu, que, diga-se de passagem, já melhorou bastante, está mais bem construído. Quanto ao módulo i915, ele continua sendo o padrão para as GPU da Intel, nos *Ubuntu 16.04, e está funcionando sem problemas. Essas travamentos, porém, ocorreram no meu laptop, e estão ocorrendo no seu provavelmente pelo mesmo motivo: um bad commit (algum código malfeito) inserido nos kernels 4.4.X causou um problema de funcionamento com o módulo amdgpu. Há diversas reclamações como a sua, Internet afora, e alguns relatórios de bug já foram abertos (eu mesmo abri um lá no Launchpad). Embora você não tenha fornecido praticamente informação nenhuma relativa ao problema que está ocorrendo com seu laptop, muito provavelmente o problema é o mesmo que estava ocorrendo no meu notebook: congelamentos, mensagens de "kernel panic" com erro do tipo "NULL pointer dereference" etc. Uma forma simples de provocar o congelamento é executar este comando: DRI_PRIME=1 glxgears Se o comando acima fizer seu computador travar/congelar, é pane de interação entre o módulo amdgpu e o kernel do Linux. Embora o bug no kernel ainda não tenha sido identificado, eu consegui descobrir que o bug acompanhou os kernels do Linux versões 4.4.X e 4.5.X, mas a partir da versão 4.6-rc1 (que é a compilação 4.6.0-040600rc1-generic) o bug foi removido por um "commit benéfico". Eu recentemente publiquei um comentário-tutorial lá no Viva o Linux (vide o comentário nº 6), explicando como instalar a versão 4.6-rc7 do kernel. Essa versão não tem o bug e funciona perfeitamente bem com o módulo amdgpu, inclusive em computadores híbridos (gráficos Intel + AMD). O arquivo PDF anexo é o comentário-tutorial que publiquei lá. Resolvi salvá-lo aqui em PDF porque se o autor daquele tópico resolver excluir o tópico, meu comentário-tutorial será excluído junto, e daí todas as explicações que postei lá serão perdidas. O PDF anexo é uma "cópia de segurança". Se quiser instalar a versão mais recente do kernel (que eu ainda não testei, mas, pelo que li nos logs da compilação, corrigiu ainda mais bugs relacionados à interação entre o kernel e o módulo amdgpu), basta usar estes três arquivos, quando for instalar o kernel (ao invés de baixar os três pacotes .DEB que eu informei no meu comentário-tutorial): 1 - http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc1/linux-headers-4.8.0-040800rc1_4.8.0-040800rc1.201608072231_all.deb 2 - http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc1/linux-headers-4.8.0-040800rc1-generic_4.8.0-040800rc1.201608072231_amd64.deb 3 - http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc1/linux-image-4.8.0-040800rc1-generic_4.8.0-040800rc1.201608072231_amd64.deb É isso! tutorial_fix_kernel_amdgpu_ubuntu.pdf

Tive um problema similar com meu SSD Kingston V300 novinho em folha, quando fui instalá-lo no meu velho Macbook Pro 13" unibody mid-2009. Mas o SSD estranhamente funcionava bem quando eu o conectava a uma docking station ligada ao meu Macbook via porta USB. Após muito sofrimento com tentativas frustradas de instalar o OS X Snow Leopard, idem o Yosemite e o El Capitan, finalmente tive a "brilhante" ideia de levar à assistência técnica e pedir para trocarem o cabo SATA. Tadá! Era problema no cabo - não no SSD. Depois disso, nunca mais tive problemas com o SSD.

Obrigado, Fernando, pelo elogio. E valeu pela dica. Realmente, se a pessoa já dispuser das dependências corretas instaladas no sistema (apenas o arquivo de controle de dependências do pacote estiver errado), usar o dpkg com a opção --force-depends é uma solução bem prática.

O tutorial que aqui constava foi definitivamente movido para o fórum do Ubuntu, que é mais apropriado para este tema, e portanto será doravante mantido atualizado somente naquele fórum. Consequentemente, considero este tópico fechado, no fórum do Clube do Hardware.

Como eu havia comentado antes, tudo é relativo (e por isto é questionável/ponderável), inclusive sua última afirmação. Caso domine a língua inglesa, pode ler este breve artigo, que essencialmente mostra que o software GNU representa apenas 8% de uma distribuição Linux convencional e que dentro desse pequeno universo de 8% somente o gdb (GNU debugger) parece ainda não dispor de uma boa alternativa, no mundo do software: todas as demais peças de software GNU usadas nas distribuições GNU/Linux atualmente já podem ser substituídas por alternativas. Além disso, o que dá vida a um sistema é uma série de peças de software, inclusive uma infinidade de bibliotecas, e o fato é que menos de 2% das bibliotecas usadas em um sistema GNU/Linux tem origem no projeto GNU: todo o restante é oriundo de inúmeros outros projetos. Enfim: eu sei que, assim como qualquer kernel (de qualquer sistema), o kernel Linux sozinho não serve essencialmente para "nada" (embora ele tenha sido o ponto de partida para o desenvolvimento do sistema Android) e que as distribuições GNU/Linux historicamente têm usado software GNU, e que é por isto (aliás, eu diria que é mais pelas razões históricas do que pela "participação no sistema") que eu mesmo - que acompanho a "vida" do Linux desde que ele surgiu, em 1991 - costumo escrever "GNU/Linux". Mas, francamente, Alexandre: na minha opinião, isso é uma grande bobagem, porque é relativo (e, por isto, subjetivo), sabe? É muita picuinha para algo que não é exatamente relevante. Se você (por exemplo) considerar que o software GNU que vem na distribuição colabora com algumas das (não todas as) funções mais "essenciais" do sistema (embora o primeiro processo do kernel seja o init, que não é software GNU: foi desenvolvido na Bell Labs. Mas hoje em dia está sendo substituído pelo daemon systemd, que é da GNU), até que faz sentido escrever "GNU/Linux". Porém, se você observar o quão pequenos são aqueles 8% e considerar o fato de que praticamente todo o software GNU pode ser substituído por software não-GNU (o que significa que o Linux pode ser o que ele quiser, independentemente de existir ou não GNU), aí já surge um contra-argumento ao meu ver muitíssimo forte contra a grafia "GNU/Linux". Salvo nas ocasiões em que estou com preguiça de digitar, de maneira geral eu grafo "GNU/Linux" mesmo. Mas isso sou eu e apenas pelo fato de eu reconhecer (mais emocionalmente e por razões históricas do que racionalmente) a colaboração que várias peças de software livre da Free Software Foundation (FSF), criadas dentro do projeto GNU, tiveram para ajudar a fazer as distribuições Linux se popularizarem (na forma de sistemas GNU/Linux). Mas daí a transformar a grafia "GNU/Linux" em uma "regra" ou "obrigação" ética e ortográfica (como você fez quando quis me corrigir, no seu primeiro post), aí eu já acho inadequado, porque neste tema controverso não existe Verdade Absoluta: cabe a cada um decidir quais argumentos têm maior peso e daí escolher como irá se referir ao sistema. Em outras palavras: ao que me parece, o mais saudável é apresentar essas informações para as pessoas (como as do artigo que eu mencionei) e deixar a critério de cada pessoa a liberdade para decidir se a abreviatura GNU merece ou não fazer parte do nome do sistema (e se, caso mereça, vale a pena ficar se dando o trabalho de sempre digitar isso, hehe. Eu às vezes simplesmente não tenho paciência!). Caso queira dar continuidade a esta discussão, peço que crie um novo tópico em Geral, para que neste tópico aqui sejam incluídos somente posts referentes à instalação do java da Sun/Oracle. Ouquêi?

Haaa, então funcionou. Show de bola!