Problema após instalar ubuntu 16.04

daniellopes2006 · 22 de junho de 2016

Bom dia, gostaria de uma ajuda no seguinte problema:

Comprei um Dell Inspiron 15 5548 que já vem com windows.

Instalei o Ubuntu 16.04 LTS e funciona tudo perfeito, mas ao encerrar a sessão o sistema trava todas as vezes e aparece linha de códigos até a metade da tela.

Obrigado a todos.

29 de junho de 2016

O Ubuntu não deve estar conseguindo encerrar algum processo.
Talvez em modo texto voce consiga identificar alguma coisa.
Use o CTRL+ALT+F1 para ir para o modo texto.
Digite seu usuário e senha.
Digite:
sudo poweroff (para encerrar)
sudo reboot (para reiniciar)

Amanda Santini · 29 de junho de 2016

2 horas atrás, Fernando Apratto disse:

Digite:
sudo poweroff (para encerrar)
sudo reboot (para reiniciar)

É importante notar se aparece alguma mensagem de erro, @daniellopes2006

Sampayu · 8 de agosto de 2016

Em 22/06/2016 às 09:18, daniellopes2006 disse:

Bom dia, gostaria de uma ajuda no seguinte problema:

Comprei um Dell Inspiron 15 5548 que já vem com windows.

Instalei o Ubuntu 16.04 LTS e funciona tudo perfeito, mas ao encerrar a sessão o sistema trava todas as vezes e aparece linha de códigos até a metade da tela.

Obrigado a todos.

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

Sampayu · 24 de agosto de 2016

Em 22/06/2016 às 09:18, daniellopes2006 disse:

Bom dia, gostaria de uma ajuda no seguinte problema:

Comprei um Dell Inspiron 15 5548 que já vem com windows.

Instalei o Ubuntu 16.04 LTS e funciona tudo perfeito, mas ao encerrar a sessão o sistema trava todas as vezes e aparece linha de códigos até a metade da tela.

Obrigado a todos.

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)

Amanda Santini · 30 de agosto de 2016

@Sampayu Ótima contribuição, parabéns. Não deixe de contribuir sempre que puder!

Sampayu · 30 de agosto de 2016

53 minutos atrás, AmarildoJr disse:

@Sampayu Ótima contribuição, parabéns. Não deixe de contribuir sempre que puder!

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

Marcos FRM · 30 de agosto de 2016

Não daria para a Canonical backportar as correções para a série 4.4 oficial do 16.04 (ainda mais levando em conta que o 4.4 é no momento o último LTS do kernel.org)? Acho importantíssimo ter o kernel vindo do repositório oficial, pois do contrário somos nós que viramos os empacotadores e a responsabilidade de lidar com falhas de segurança fica por nossa conta.

Amanda Santini · 30 de agosto de 2016

agora, Marcos FRM disse:

Não daria para a Canonical backportar as correções para a série 4.4 oficial do 16.04 (ainda mais levando em conta que o 4.4 é no momento o último LTS do kernel.org)?

Pelo que lembro, tanto as políticas dos desenvolvedores upstream do Kernel (kernel.org) quanto a da Canonical, é de não fazer backport de funcionalidades, apenas de segurança. Acredito que esse problema do módulo (que poder ser o AMDGPU, ou o RadeonSI, dependendo da arquitetura da placa) não seja considerado de segurança por eles, e por esse motivo eu acho pouco provável que o backport seja feito.

Mas como o Yuri disse, dá pra usar Kernels mais novos no Ubuntu. Até mesmo no Debian Stable, dá pra usar o atual kernel estável 4.7.2 no Debian Stable sem problemas hehehehe. Se não houver um Kernel mais novo, o usuario pode fazer o backport sozinho ou corrigir com um patch.

agora, Marcos FRM disse:

Acho importantíssimo ter o kernel vindo do repositório oficial, pois do contrário somos nós que viramos os empacotadores e a responsabilidade de lidar com falhas de segurança fica por nossa conta.

Depende, pois se a fonte do Kernel ainda for a Canonical ou Kernel.org, estaremos recebendo os fixes da mesma forma se estivessemos usando pela distro ou pelo Kernel.org. Eu, por exemplo, tenho que recompilar meu Kernel umas 2x por semana, pois os desenvolvedores do driver RadeonSI colocaram a minha placa de vídeo numa lista de "Quirk" que desabilita o DPM nela, fazendo com que meu monitor fique piscando. Então eu pego todas as sources do Kernel lá no repositório do Arch, altero a PKGBUILD para pegar o patch que corrige esse problema, e digo para a PKGBUILD aplicar o patch e recompilar o Kernel. É 99.9999% o mesmo Kernel usado no Arch, que em si é pego lá do Kernel.org, só que com aquela pequena alteração. Então eu não preciso manter esse Kernel e nem me preocupar com a segurança pois tudo isso já está sendo tomado conta e todas as alterações vão cair em mim do mesmo jeito

Sampayu · 30 de agosto de 2016

3 horas atrás, Marcos FRM disse:

Não daria para a Canonical backportar as correções para a série 4.4 oficial do 16.04 (ainda mais levando em conta que o 4.4 é no momento o último LTS do kernel.org)? Acho importantíssimo ter o kernel vindo do repositório oficial, pois do contrário somos nós que viramos os empacotadores e a responsabilidade de lidar com falhas de segurança fica por nossa conta.

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.

Amanda Santini · 30 de agosto de 2016

@Sampayu Realmente fazer RCB demora muito, ainda mais no Kernel que é um pacote grande.

Agora, quanto ao 4.6-rc1. Há algum motivo em especial de escolher um Release Candidate? Pois se o fix é dessa versão em diante, seria melhor ir com o Kernel estável atual em vez de usar um Kernel que ainda nem tinha virado estável ("Candidato a Lançamento").

Sampayu · 30 de agosto de 2016

55 minutos atrás, AmarildoJr disse:

@Sampayu Realmente fazer RCB demora muito, ainda mais no Kernel que é um pacote grande.

Agora, quanto ao 4.6-rc1. Há algum motivo em especial de escolher um Release Candidate? Pois se o fix é dessa versão em diante, seria melhor ir com o Kernel estável atual em vez de usar um Kernel que ainda nem tinha virado estável ("Candidato a Lançamento").

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.

Amanda Santini · 31 de agosto de 2016

agora, Sampayu disse:

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.

É que o 4.6 já saiu de RC faz tempo hehehehe. Atualmente o RC é o 4.8. e o estável é o 4.7.3.

Eu estava testando o 4.9 esses dias, que só vai sair em RC daqui 4 meses. Esse Kernel é o seguinte: os desenvolvedores da AMD estão trazendo suporte às placas GCN 1.0 para o driver AMDGPU (essa geração de placas atualmente só funciona bem com o RadeonSI), e estão já trazendo ao público as mudanças que vão cair no Kernel 4.9 (porque as que vão cair no 4.8, que atualmente está em RC, não mudam mais).

Para usar o Kernel 4.9 hoje é preciso:

Mas esses pacotes são os que eu criei para compilar no Arch. O Mareko (Xorg developer) tem um repositório para o Ubuntu, se não me engano.

Só que como eu detalhei nesse post, esse driver ainda está em estágio MUUUUITO experimental e mal funciona hehehehe. Só daqui uns meses pra que o suporte esteja legal.

Sampayu · 31 de agosto de 2016

@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.

Amanda Santini · 31 de agosto de 2016

agora, Sampayu disse:

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.

Então você vai adorar caçar um bug para a comunidade TF2 que atinge ambos usuários da RadeonSI/AMDGPU quanto usuários de placas Intel, hehehehe: https://bugs.freedesktop.org/show_bug.cgi?id=93649

agora, Sampayu disse:

Você pelo visto é entusiasta do desenvolvimento do kernel. Obrigado por me avisar a respeito dessas versões mais recentes do kernel.

Nada, comecei agora mesmo hehehehe

(estamos um pouco off-topic. Se quiser, sinta-se a vontade para me chamar por MP e podemos estender essa conversa indefinidamente hehehe).

Marcos FRM · 31 de agosto de 2016

Quando tiver algum resultado do bisect poste! Tem outra possível solução no futuro: a Canonical de uns tempos para cá atualiza version/patch level do kernel dos Ubuntu LTS, não? Então, daqui algum tempo, suponho eu, o kernel 4.4 do 16.04 pode ser atualizado para o próximo LTS do kernel.org, que será o 4.9.

Sampayu · 3 de setembro de 2016

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.

lcomedeiros · 8 de setembro de 2016

@Sampayu Meus parabéns pelo tutorial.

Sampayu · 8 de setembro de 2016

1 hora atrás, lcomedeiros disse:

@Sampayu Meus parabéns pelo tutorial.

Obrigado.

Sampayu · 12 de setembro de 2016

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

Marcos FRM · 17 de setembro de 2016

@Sampayu Muito obrigado por dedicar seu tempo e achar o problema. Menos mal ser um commit isolado, que provavelmente não vá quebrar mais nada se for backportado para a série 4.4.

Precisamos muito deste tipo de ajuda.

Sampayu · 17 de setembro de 2016

39 minutos atrás, Marcos FRM disse:

@Sampayu Muito obrigado por dedicar seu tempo e achar o problema. Menos mal ser um commit isolado, que provavelmente não vá quebrar mais nada se for backportado para a série 4.4.

Precisamos muito deste tipo de ajuda.

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.