Como instalar o AMD Crimson no Arch Linux de 64 bits?

Question

Eu tenho tentado instalar os drivers AMD mais recentes em minha máquina Linux, mas depois de conseguir compilar, sou recebido com esta mensagem:

modprobe: ERROR: could not insert 'fglrx': Unknown symbol in module, or unknown parameter (see dmesg) failed.

Por favor, note que eu não sou muito bom nessa coisa do Linux, porque eu sou mais um nativo do BSD.

Detalhes da situação

• Arch Linux, x86_64, release 2016.01.01
• Versão do kernel: 4.3.3-2
• AMD Radeon R9 290x
• Crimson, fglrx 15.302

Feito até agora

No início, o script de instalação não estava nem chegando à parte do EULA, porque eu tinha que instalar o pacote kernel-headers . Neste ponto, eu realmente poderia começar a tentar instalá-lo.

Apenas a execução do script me deu um erro:

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:634:9: error: void value not ignored as it ought to be   
    len = seq_printf(m, "%d\n", major);
        ^

Depois de alguns pequenos googling eu encontrei esta solução , e executado manualmente /usr/lib/modules/fglrx/build_mod/make.sh

Mas a compilação terminou com a seguinte mensagem:

WARNING: "mtrr_add" [/usr/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko] undefined!
WARNING: "mtrr_del" [/usr/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko] undefined!

É claro que você deve ignorar o aviso e, por isso, comecei a instalar os módulos compilados ... o que resultou na mensagem:

modprobe: ERROR: could not insert 'fglrx': Unknown symbol in module, or unknown parameter (see dmesg) failed.

Depois de dar uma olhada no dmesg, vejo as seguintes linhas:

[ 2848.332722] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[ 2848.332725] Disabling lock debugging due to kernel taint
[ 2848.343063] fglrx: Unknown symbol mtrr_del (err 0)
[ 2848.343114] fglrx: Unknown symbol mtrr_add (err 0)

Alguns googling me levam a esta mensagem da lista de e-mail: link que menciona a remoção de mtrr_add() com base em sendo de alguma forma ruim:

The crusade to replace mtrr_add() with architecture agnostic arch_phys_wc_add() is complete, this will ensure write-combining implementations (PAT on x86) is taken advantage instead of using MTRR. With the crusade done now, hide direct MTRR access for drivers.

Então, o que devo fazer agora?

Eu não tenho ideia de como proceder neste momento? Devo estar se diferenciando na origem, procurando por funções usando mtrr_add e mtrr_del ? Existe algum patch que eu deveria estar aplicando? Tudo é apenas um grande fracasso e eu devo desistir?

    

Answer 1

Obrigado ao @DanielB comentários Eu trabalhei .

Então ... o que eu tive que fazer foi fazer o downgrade para uma versão mais antiga do kernel / xorg e ter certeza de que ele fica (apesar do Arch Linux ser um design para ficar na vanguarda). Mas foi um pouco complicado.linux-4.2.5-1

Desde que fiquei preso no console, baixei manualmente pacotes antigos do arquivo (especificamente: linux-4.2.5-1, linux -headers-4.2.5-1 e xorg-server-1.17.4-2). Eu também tive que obter uma versão mais antiga do grupo de pacotes xorg-drivers . Eu coloquei esses pacotes em /var/cache/pacman/pkg/ e então fiz um downgrade deles com o comando pacman -U /path/to/package-file.pkg.tar.xz .

Em seguida, reinstalei o driver Crimson e execute aticonfig --initial para gerar xorg.conf.

Para impedir que a atualização do sistema falsifique tudo, adicionei essas duas linhas em /etc/pacman.config :

IgnorePkg   = linux linux-headers xorg-server
IgnoreGroup = xorg-drivers

Estas linhas irão gerar avisos, ao executar pacman -Syu ... para que você não possa realmente esquecê-lo. Quando os novos drivers AMD Crimson forem lançados, poderei desativar temporariamente este temporário.

E depois explodiu ...

Depois de executar pacman -Syu e reinicializar, algo deu errado (na reinicialização, a inicialização ficou presa). Eu não tenho certeza do que aconteceu, mas o que eu fiz foi:

• inicializa a partir do install-usb
• faça um arch-chroot na minha partição primária
• desativar sddm
• reinicializar
• reinstale o Crimson e gere novamente o xorg.conf
• ativar sddm

Isso consertou isso. O que eu recordei da leitura de vários logs foi: após a atualização, o fglrx module estava corrompendo o kernel novamente, o que causou falha no Xorg, o que, por sua vez, tornou impossível para o systemd-logind alcançar o SDDM. E como qualquer parte razoável do sistema operacional, o systemd foi tits-up bloqueando tudo (o teclado não estava respondendo).