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?

  • /edit: Small correction: This driver is compatible (well, the seq_printf call anyway) up to Linux 4.2. AMD says it’s compatible up to 3.19. So you’ll have to use an older kernel branch.
    – Daniel B
    Jan 4 '16 at 11:23
  • @DanielB hmm .. since I'm not really good at this, I will just try to reinstall to 2015.12.01 release (it's with 4.2.5 kernel), because based on what I googled, downgrading a freshly installed system might be way too complicated for me.
    – teresko
    Jan 4 '16 at 12:14
  • That won’t work, it’ll break again on the very first update. You need to use a different kernel package or a different distro altogether because Arch is kept up-to-date at all times. Older package versions are removed quickly.
    – Daniel B
    Jan 4 '16 at 19:21

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.