How to install AMD Crimson on 64 bit Arch Linux?

Question

I have been trying to install the latest AMD drivers on my Linux machine, but after getting it to compile I am greeted with this message:

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

Please note that I am not too good at this Linux thing, because I am more of a BSD native.

Situational details

• Arch Linux, x86_64, release 2016.01.01
• Kernel version: 4.3.3-2
• AMD Radeon R9 290x
• Crimson, fglrx 15.302

Done so far

In the beginning the installation script was not even getting to the EULA part, because I had to install the kernel-headers package. At this point I actually could start trying to install it.

Just running the script gave me an error:

/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);
        ^

After some minor googling I found this solution, and executed manually /usr/lib/modules/fglrx/build_mod/make.sh

But the compilation ended with these message:

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!

Of course, you are supposed to ignore the warning and so I proceeded to just installing the compiled modules ... which resulted in message:

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

After taking a look at dmesg, I see the following lines:

[ 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)

Some googling lead me to this mail list message: https://patchwork.ozlabs.org/patch/510277/ which mentions the removal of mtrr_add() on basis of it being somehow bad:

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.

So, what should I do now?

I have no idea how to proceed at this point? Should I be diffing at the source, looking for functions using mtrr_add and mtrr_del? Is there some patch I should be applying? Is it all just a big failure and I should give up?

Answer 1

Thanks to @DanielB comments I got it working.

So ... what I had to do was to downgrade to older kernel/xorg version and make sure that it sticks (despite Arch Linux being design to stay on cutting edge). But it was a bit tricky.linux-4.2.5-1

Since I was stuck in console, I manually downloaded older packages from archive (specifically: linux-4.2.5-1, linux-headers-4.2.5-1 and xorg-server-1.17.4-2). I also had to get older version of xorg-drivers package group. I placed those packages in /var/cache/pacman/pkg/ and then downgraded them with command pacman -U /path/to/package-file.pkg.tar.xz.

And then reinstalled Crimson driver and run aticonfig --initial to get xorg.conf generated.

To stop system update from faking it all up, I added these two lines in /etc/pacman.config:

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

These lines will generate warnings, when running pacman -Syu ... so you wont really be able to forget it. When the new AMD Crimson drivers come out, I will be able to temporary disable this temporary.

And then it blew up ...

After running pacman -Syu and rebooting something went wrong (on reboot the initialization got stuck). I am not entirely sure what happened, but what I did was:

• boot from install-usb
• do an arch-chroot in my primary partition
• disable sddm
• reboot
• reinstall Crimson and regenerate xorg.conf
• enable sddm

This fixed it. What I gathered from reading various logs was: after update fglrx module was tainting kernel again, which caused Xorg to fail, which in turn made it impossible for systemd-logind to reach SDDM. And as any reasonable part of OS, systemd just went tits-up locking everything (keyboard was not responding).