Update 2: Check out the next post in the series for bad news regarding the Crimson driver and my GPU.
TL;DR
My God. They’ve actually whittled down the necessary patching to two
[Update 1: thanks to iUser and Pyracmon below for pointing out the need for one additional hunk in the patch. Thanks to SevM for identifying the missing hunk (which I applied to my own code, and then eliminated from the patch I uploaded here…d’oh)]
three hunks out of the old Catalyst157-413.patch file. That’s all that’s needed, and the installation works. Skiip to the installation steps below and you’re good to go if you’ve been following this document and you already know all the other information; it has not changed in any practical way.
Sadly, I can also report that my initial Half-Life 2: Lost Coast benchmark (using the same settings as with the Catalyst 15.7 driver) came back at 56.63 FPS, putting it noticeably less than the 62.9 FPS achieved with the 15.7 driver. I was hopeful that their remarks in the release notes in which they claim to have fixed that silly rename-the-hl2-executable trick to gain performance indicated that they were paying more attention than that.
Ho-hum. I do see I have the latest Mesa driver updates lined up.. Maybe I was too cavalier about ripping out one of those patches, though they’ve never seemed optional in the past.. Could be an anomalous test – the jerkiness of the test at certain (admittedly more stressful) points seemed like it had to be anomalous, lest this driver iteration be really broken, or experiencing some sort of atypical problem with The Lost Coast.
I’ll abstain from making a judgment until I’ve patched and rebooted my system and whatnot.
Process Development Summary
I’d like to continue to thank Leigh Scott for his activity in packaging the driver with RPMFusion.
For those of you who prefer to install the driver the old fashioned way (such as myself), I’ll continue to provide the instructions below. I have consolidated the patches built up between kernel version iterations into a single patch below, as well. That has included a slight correction to Leigh’s patch for the license which uses an escape character as a slash in “GNU\Proprietary,” (I have simply changed it to a forward slash) causing the installation process to throw an error.
Known Issues (Solutions In Progress)
- TigerVNC has a problem with the driver; KDE crashes when attempts are made to enter the VNC server session.
- SDDM (the Simple Desktop Display Manager; successor to KDM) crashes due to SELinux denials for sddm-greeter of the following nature:
- audit[1528]: <audit-1400> avc: denied { unix_read unix_write } for pid=1528 comm=”sddm-greeter” key=17908779 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xserver_t
- audit[1528]: <audit-1400> avc: denied { unix_read unix_write } for pid=1528 comm=”sddm-greeter” key=17908779 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xserver_t
- Kscreenlocker crashes repeatedly in the following manner:
- abrt-hook-ccpp[23786]: Not saving repeating crash in ‘/usr/libexec/kscreenlocker_greet’
- audit[23787]: <audit-1701> auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=23787 comm=”kscreenlocker_g” exe=”/usr/libexec/kscreenlocker_greet” sig=1
- QEMU throws the following error when an attempt to start a guest domain is made: error: internal error: process exited while connecting to monitor: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object
- This is an SELinux issue, as well:
- audit[5335]: <audit-1400> avc: denied { execmem } for pid=5335 comm=”qemu-system-x86″ scontext=system_u:system_r:svirt_t:s0:c78,c390 tcontext=system_u:system_r:svirt_t:s0:c78,c390 tclass=process
- This is an SELinux issue, as well:
Prerequisite Discussion
Universal Package Prerequisites
Remaining yet unchanged, the general prerequisites are:
- GCC version 3.3.3 or higher.
- Kernel headers or kernel sources matching version of the kernel you’re running. Please consult to documentation for your distribution how to get and install this.
- XFree86 version 4.1.X, 4.2.X, 4.3.X, or XOrg version 6.8.X (Fedora 20 does not use XFree86) or higher.
- Note this is the protocol version, and not the server version discussed above and below.
Heed the warning:
- If you have multiple version of X Window System installed on your computer the installer will try to detect the default X, and install the driver for the detected version. However, you could experience problems trying to run other versions of X after this. Also, if your X Window System is installed into a nonstandard location, installation of the driver could be either problematic or incomplete.
With a fully up-to-date Fedora 22 installation, perform the following command to acquire the requisite packages:
dnf install gcc kernel-headers kernel-devel
Fedora 22 Products and the Proprietary AMD Catalyst Graphics Driver
As Mike points out, it appears the Catalyst driver merely fails to work with GDM, but it will support GNOME if some additional installation steps are followed. It appears all you must do is that which is documented in the “do not reboot after the installation” section and the subsequent “save it replace it” section. I would look into this myself and integrate it into these instructions if I weren’t running the KDE Spin, but feel free to ask any questions that may arise during the process or confirm that it works for others as Mike did in the comments below.
But if you don’t want to do that, I encourage you to install the Fedora 22 KDE Plasma Desktop Spin (or any non-GNOME spin to your liking).
Installing KDE In Fedora 22
If you REALLY don’t want to reinstall your OS entirely, and you don’t want to try the GNOME solution above, you can execute
dnf group install "KDE Plasma Workspaces"
And it’ll probably work. I haven’t tested this yet (I’ll spin up a Fedora 22 Workstation VM soon), but make sure you use SDDM (the successor to KDM) as your Desktop Manager ’cause the GNOME Desktop Manager (GDM) breaks with the Catalyst driver, as well (as addressed above).
Assuming that you’ve set yourself up with KDE and SDDM in some fashion (just install the Spin), or you’re taking whatever measures necessary as described above to get around the GDM issue, you’re in good shape to simply install the driver as described below.
Installation Instructions
1) Download the AMD Catalyst 15.9 (fglrx) driver from AMD’s site.
2) Change your working directory to your ~/Downloads directory and extract the amd-driver-installer-15.20.1046-x86.x86_64.zip file:
$ cd ~/Downloads $ unzip amd-catalyst-15.9-linux-installer-15.201.1151-x86.x86_64.zip
3) Extract the run archive:
$ sh AMD-Catalyst-15.9-Linux-installer-15.201.1151-x86.x86_64.run --extract
Here, you’ll see a message which reads something like: “Created directory fglrx-install.wIhzk3″ and then “Verifying archive integrity… All good.” followed by a “Uncompressing AMD Catalyst(TM) Proprietary Driver-15.20.1046″ followed by a lot of dots.
4) Now, you should see a newly created folder called fglrx-install.whateveryourcomputernamedit (mine, for example, was fglrx-install.wIhzk3). Change your working directory appropriately and apply the Catalyst159-Kernel416.patch.
$ cd fglrx-install.wIhzk3 $ mv ~/Downloads/Catalyst159-Kernel416.patch.doc ~/Downloads/Catalyst159-Kernel416.patch #WordPress does not permit me to upload a .patch file, so I add the .doc extension to lazily get around that restraint $ mv ~/Downloads/Catalyst159-Kernel416.patch ./ #this is not necessary, but I do it for sanity's sake, to keep the patch file with the patched code as a reminder $ patch -p0 < Catalyst159-Kernel416.patch
If you are successful, you will see the following output:
patching file common/lib/modules/fglrx/build_mod/firegl_public.c Hunk #1 succeeded at 277 (offset 8 lines). Hunk #2 succeeded at 3506 (offset 8 lines). patching file common/lib/modules/fglrx/build_mod/kcl_str.c
5) As Jacob Yates points out, one must copy the version.h header file into the build directory for the current kernel version:
$ sudo cp /usr/include/linux/version.h /lib/modules/`uname -r`/build/include/linux/
6) Now that you’ve patched the installation package and copied the header file needed to build the module, run the installation:
$ sudo ./ati-installer.sh 15.201 --install
7) Choose the “Install Driver 15.201 on X.Org 6.9 or later 64-bit” option from the Setup Wizard, and then simply follow the prompts. Ensure that you do not select “Generate Distribution Specific Driver Package (Recommended)”. This will only work if you use one of the officially supported Linux distributions listed on AMD’s site (Fedora is not included).
8) Reboot your machine and enjoy!
Properly Maintaining your Catalyst Implementation
Being a custom kernel module, you unfortunately must rebuild the Catalyst driver every time you upgrade the kernel version or, in some cases, other GPU-dependent packages (like mesa). The surefire way to tell that you need to reinstall your driver is a notice from Steam (for example) that
OpenGL GLX context is not using direct rendering, which may cause performance problems.
The solution to this issue is to uninstall your driver, reboot, reinstall it, and reboot. Don’t wait for this error to pop up after kernel upgrades, however, because you’ll probably just see a black screen and have to enter a CLI terminal to uninstall the driver.
General Guidelines
Before every kernel upgrade:
1. Uninstall the driver
$ sudo aticonfig --uninstall
2. Reboot
$ shutdown -r now
3. Upgrade your system
$ sudo dnf upgrade
4. Reboot
$ shutdown -r now
5. Copy the header file necessary for the driver’s installation into the new kernel’s directory:
cp /usr/include/linux/version.h /lib/modules/`uname -r`/build/include/linux/
6. Reinstall the driver
$ cd /driver/location/fglrx-install.wIhzk3 #Keep your patched driver files around and ready to go! $ sudo ./ati-installer.sh 15.201 --install
It’s not so bad, but it adds a little burden. I hope to design a DKMS solution which automatically handles this for you, but I haven’t gotten to it yet.
Troubleshooting
Remember, if you see this message:
“Your Graphics adapter is not supported by this driver. Installation will not proceed”
Check out the post to which that link sends you for a potential resolution for your problem. You probably have an Intel CPU with an on-die Haswell GPU combined with a Radeon GPU, but let me know if you don’t, or if you encounter an issue that that post doesn’t resolve.
Engineering Walden 
To correct the GDM and SDDM trouble you only need to disable SELinux
Really? I mean, I knew the SDDM issue was purely the result of SELinux, and I intended to make a fix, but never got around to it (I just type my password in a white screen when I’m using the machine for gaming purposes – ha). Is the only current problem with running the driver on GNOME an SELinux issue with GDM?
No, in many laptops the driver fails and you have to patch the “mutter” source code to fix that problem.
Something went wrong on installation and I’m somewhat clueless what that creepy installer wants 😛
I have installed all the prerequirements at least I believe strongly in that…
Yet I get this in error log (wall of text incoming!).
Is there some way out of that?
Thank you for advance and have a nice day~
====
Supported adapter detected.
Check if system has the tools required for installation.
Uninstalling any previously installed drivers.
Creating symlink /var/lib/dkms/fglrx/15.201.1151/source ->
/usr/src/fglrx-15.201.1151
DKMS: add completed.
Kernel preparation unnecessary for this kernel. Skipping…
Building module:
cleaning build area…
cd /var/lib/dkms/fglrx/15.201.1151/build; sh make.sh –nohints –uname_r=4.1.6-201.fc22.x86_64 –norootcheck…..(bad exit status: 1)
[Error] Kernel Module : Failed to build fglrx-15.201.1151 with DKMS
[Error] Kernel Module : Removing fglrx-15.201.1151 from DKMS
——————————
Deleting module version: 15.201.1151
completely from the DKMS tree.
——————————
Done.
[Reboot] Kernel Module : dracut
I’m experiencing the exact same issue as iUser above when using the 15.9 package for 4.1.6-201 kernel.
$ uname -r
4.1.6-201.fc22.x86_64
I’ve followed the steps provided – patch applied successfully with the same output as above. The prerequisites (kernel-headers, GCC etc. are all installed). All packages on system up-to-date. If anybody has any ideas on steps to resolve please share.
Man, I wish I could replicate it, but as the post indicates, the process worked for me. Can you post a screenshot or some console output of the commands (or GUI steps?) and their output leading up to the error?
“Man, I wish I could replicate it, but as the post indicates, the process worked for me. Can you post a screenshot or some console output of the commands (or GUI steps?) and their output leading up to the error?”
Certainly, here are screenshots that occured during the installation.
https://www.sendspace.com/file/p6pz38
Thanks, both – it looks like I accidentally removed a hunk from the old patch that I applied to my system before writing this blog post. I should’ve included the hunk intended for kcl_str.c, as SevM below points out. I have updated the post with the correct patch and expected output (step 4 of the installation instructions). Let me know if the new patch fails to fix your problems (just click the link and download it again, then apply it and ignore the alerts about the first two hunks already being applied; just skip them), but I expect that it will!
Yes! That was it bitwiseoperator. I’ve followed the instructions you’ve provided but using the new patch and the installer finished without error. I’m also loading Steam/Steam games without any errors thrown so I believe we can call this resolved! Thanks everyone that contributed to this patched 15.9 installer. I can confirm it works on Fedora 22 64-bit with 4.1.6-201 kernel.
Hi bitwiseoperator, I think I found a typo: “Lost Coast benchmark with the settings employed with the 15.7 driver came back at 56.63 FPS, putting it noticeably less than the 62.9 FPS achieved with the 15.7 driver.”
Don’t you mean “Lost Coast benchmark with the settings employed with the new 15.9 driver came back at 56.63 FPS, putting it noticeably less than the 62.9 FPS achieved with the old 15.7 driver.”
Also you can just use no log-in manager too, which is the most comfortable for me. Although I don’t know how to switch to that, because I did it by using KDM and then uninstalling KDM. Then I just get a full screen terminal after booting, which is perfect, if you know the command to start your desktop environment (startxfce4 for me). (Also I couldn’t uninstall the group by typing “sudo dnf group remove “KDE Plasma Workspaces”” because of the error that the group has dependencies to the protected packages DNF and systemd. Thank goodness these protections are there 😀 But why are there dependencies since everything worked before without the group installed?)
Also, I’ve read permissive mode for SELinux is enough, no need to disable it entirely. Which is preferable I suppose 🙂
1) Well, that paragraph of mine was mangled pretty badly. Thanks for the linguistic bug report. I fixed it.
2) I could do without a login manager, that’s true. I don’t even have to uninstall it, I can just mask it with systemd. I might do that..
3) The dependency thing is unfortunate; seems like there have been more dependency issues since the productization thing. Post the dependencies you see listed for the KDE Plasma Workspaces if you get a chance; I’d be interested.
4) SELinux won’t have any effect on your system when in permissive mode other than quietly logging infringements of its policies; it’s mostly a troubleshooting mechanism that allows you to observe obstructive SELinux policy without preventing software from working as it happens. I think SELinux is excellent, valuable software, so for what it’s worth, I encourage you to learn to administer it and keep it running! Check out Red Hat’s document (their documentation is a tremendous contribution to the open source community).
Great info as always guys. Finally took the plunge and uninstalled the drivers and updated the kernel then reinstalled the new drivers. Just a heads up the patch still needed to be ran for this file ‘common/lib/modules/fglrx/build_mod/kcl_str.c’ While I was installing new drivers I received an error and logs pointed to this file just an update :D. Also, I was having problems with qemu and came across this fix for it ‘sudo setsebool -P virt_use_execmem=on’ fix it right up for me. So, I can still work with VM’s and game while updates and spin ups are running. I wonder if there is selinux fix to allow whatever it is AMD Catalyst driver is trying to do when loading up the driver. Anyone have log of the error that it reports back when the system hangs? Take care for now.
Sev,
I’m not sure, but probably you can “listen” to SELinux as it blocks the point you are looking for. After that check what SELinux says about it as usually he tells the way to allow that one thing so he won’t bother you anymore.
TL;DR; – “I have stopped this guy from entering the town because he looked suspicious, but if you say he is good guy I will allow him to enter the town from now on” – SELinux
Hi,
How do you patch the kcl_str.c , I am having the same issue here
Looks like I’ll have to look into this issue soon; I’ll try to get an answer posted by tonight.
Update: See the post – I’ve fixed the issue. Just download the new patch file (same location in the post as the old one – just click the link again to get the new patch) and apply it, ignoring the fact that the first two hunks in it are already applied (i.e. don’t reverse them, just skip them). Let me know how it goes!
They, thanks Sev – you were right; I shouldn’t have omitted the kcl_str.c patch. I must’ve mistakenly thought it didn’t apply to my system when it did, in fact, apply, and that’s why my system worked but others were having issues with the process as I described it (i.e. without the kcl_str.c hunk). You da man!
Np Bitwise!! thanks for having a place for us to get together and work out our issues.
With the latest Fedora 22 kernel (4.1.6-201.fc22.x86_64) I had to change kcl_str.c to replace strnicmp with strncasecmp. I’m using amd-catalyst-15.9-linux-installer-15.201.1151-x86.x86_64.zip
Yeah – looks like I erroneously removed that hunk from the old Catalyst 15.7 patch when it is, in fact, still needed. I’ve updated the patch in the post. Thanks for the feedback!
OK, so after struggling to install it for a while, I moved into KDE and now I’m running Plasma with Catalyst. I’m a happy person! Thanks, to all who helped and especially to “bitwiseoperator”!!!!!
Thank you guys, all is good now and I was able to run a phoronix benchmark as well which before I could not …..
Great work as always…..
white screen in place of login screen, i can type password and enter to login but still there is a very ulgy graphical glicth after installing(KDE)
Hi, Jacuzzi I these issue with the previous drivers, however after installing the latest ones, the white screen disappear and now I get the login screen just fine. Check on the Look and Feel that you have select the Fedora 22 theme instead the Breeze… maybe that will do it.
fedora 22, 4.1.6 kernel gnome, facing somethings wrong when login using lightdm. possible problem–
the do not reboot after installation guide.
echo -ne ‘/amd_xversion’ | dd conv=notrunc of=libglx.so bs=1 count=13 seek=$offset
this cmd gives error: DD invalid number ‘ ‘
any fix?
I think I did receive that receive that error as well. I still kept going forward with the process installing lightdm, disabling gdm and enabling lightdm. Once you do a restart you should be greeted with lightdm login screen. It’s not as pretty as GDM but works fine with getting right into your system :). Report back any issues you have if it doesn’t work. I think you should be fine though. It would be nice if we could fix the selinux with SDDM and GDM if that indeed is the case. Possibly send that to AMD or open a case so that they could look into it. I’m not sure what their Developers are using on their workstations gnome or kde but it would be interesting to know also if they run custom selinux settings.
Only you have to disable SELinux by editing /etc/selinux/config where it says, SELINUX=something (where “something” can be disabled, enforcing, permissive), you have to put SELINUX=disabled
tried disabling selinux still the same result, dont know what the problem is, xfce and kde installed the drivers fine but i use gnome and its not working
Just updated to recent Linux kernel and enabled gdm, removed/reinstalled amd drivers and disabled selinux. Sure enough gdm came up no problem. I did get selinux error below. Lightdm apparently gives avc errors as well but doesn’t hang on boot.
“type=AVC msg=audit(1443147735.370:444): avc: denied { unix_read unix_write } for pid=1454 comm=”gnome-shell” key=17908779 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tclass=sem permissive=0″
Turn SELinux on Permissive mode disable lightdm enable gdm and then reboot. Once logged in run selinux troubleshooter and it will tell you how to give gdm accesses it needs to run. Now turn SELinux back on enforcing and reboot. Now you should have gdm working perfectly.
— Comment #1 from Miroslav Grepl —
If you add a local policy
# grep gnome-session /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
That’s the reply I received from redhat about gnome selinux error. I would prefer to add a policy then disable selinux completely. Hope this helps others who don’t want to disable selinux.
yeah i can put in my pass in lightdm but when i press the login key it take me to the something went wrong error instead, tried many times still the same result. and i used fedy to set selinux to permissive mode, not sure it worked or not ill try to disable it by editing and try again
Do you have a laptop with a video card AMD?
Si la respuesta es sí, entonces revisa este vínculo, puede resolver tu problema: https://aur.archlinux.org/packages/mutter-catalyst/
yes, lenovo g505s amd apu 5750m with 8650g + 8570m
how to patch mutter
Shouldn’t you include this link between steps 7 and 8 as part of the instructions? Isn’t it technically step 8 for GNOME users? http://wiki.cchtml.com/index.php/Fedora_21_Installation_Guide#do_not_reboot_after_the_installation
Yeah, I need to revise the guide for GNOME users. I hope to return to being a GNOME user some day. Are those steps really all that is required to make GNOME usable with the Catalyst driver?
I might switch back… I’ve been missing GNOME for years.
pls switch quickly and find the problem
Thx ! manual install works fine but still not able to use Leigh’s packages for some reason… will leave a comment/reply to the comment you linked to.
You did this step as well?
“last part is to Assist Clutter in recognizing the OpenGL version
open gedit and edit /etc/profile at the bottom add those following line
export COGL_DRIVER=gl
export COGL_OVERRIDE_GL_VERSION=1.4
export COGL_RENDERER=GLX
export LD_PRELOAD=/usr/lib64/fglrx/fglrx-libGL.so.1.2
Close the editor and run this command on the terminal”
I get this in the install log when I try this.
Supported adapter detected.
Supported adapter detected.
Check if system has the tools required for installation.
Uninstalling any previously installed drivers.
Unloading radeon module…
rmmod: ERROR: Module radeon is in use
Unloading drm module…
rmmod: ERROR: Module drm is in use by: ttm drm_kms_helper radeon
[Message] Kernel Module : Trying to install a precompiled kernel module.
[Message] Kernel Module : Precompiled kernel module version mismatched.
[Message] Kernel Module : Found kernel module build environment, generating kernel module now.
AMD kernel module generator version 2.1
doing Makefile based build for kernel 2.6.x and higher
rm -rf *.c *.h *.o *.ko *.a .??* *.symvers
make -C /lib/modules/4.1.6-201.fc22.x86_64/build SUBDIRS=/usr/lib/modules/fglrx/build_mod/2.6.x modules
make[1]: Entering directory ‘/usr/src/kernels/4.1.6-201.fc22.x86_64’
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:6438:12: warning: defined but not used [-Wunused-function]
static int KCL_fpu_save_init(struct task_struct *tsk)
^
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.o
/usr/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.c:839:20: warning: defined but not used [-Wunused-function]
static acpi_status KCL_ACPI_Slot_No_Hotplug(KCL_ACPI_DevHandle handle, u32 lvl, void *data, void **rv)
^
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_agp.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_debug.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_io.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_pci.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_str.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_iommu.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl.o
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/kcl_wait.o
LD [M] /usr/lib/modules/fglrx/build_mod/2.6.x/fglrx.o
Building modules, stage 2.
MODPOST 1 modules
CC /usr/lib/modules/fglrx/build_mod/2.6.x/fglrx.mod.o
LD [M] /usr/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko
make[1]: Leaving directory ‘/usr/src/kernels/4.1.6-201.fc22.x86_64’
build succeeded with return value 0
duplicating results into driver repository…
done.
You must change your working directory to /lib/modules/fglrx
and then call ./make_install.sh in order to install the built module.
– recreating module dependency list
– trying a sample load of the kernel modules
failed.
[Error] Kernel Module : Reboot required.
[Reboot] Kernel Module : dracut
Also, if it helps, I run a 295×2 which is why it says, “Supported adapter detected.
Supported adapter detected.” (it says that twice). This card is kind of a special bird. It is like having 2 GPU cards.
What GPU are you using?
The 295×2. https://youtu.be/JEgsG_wl0kc
Bitwise, Would it be worth Michael trying the previous patch since from the error above kcl_acpi is one of the files that was patched previously? Maybe something extra is being called for dual video cards. Are you using the most up to date radeon drivers for linux? https://bluehatrecord.files.wordpress.com/2015/08/catalyst157-kernel413-patch.doc
Actually i think i figured it out. it was linking against the standard mesa libGL.so*
I’ve added /usr/lib64/catalyst in front of my LD_LIBRARY_PATH and re-sourced the shell config.
glxinfo now picks up the correct libGL.
Not having to reinstall at each kernel update will be nice.
What about 4.1.7 kernel?
I’m feeling adventurous before work. I followed the kernel upgrade instructions and didn’t have any issues. Even launched a few games. No issues.
OK thanks
gtk-doc.make:7: *** missing separator. Stop. when i do make -f gtk-doc.make
Maybe we should all bother the 1 or 2 guys over at AMD who write the Linux drivers. We could at least show them this page (and the other pages in the series). Or is me thinking that they will actually support Fedora being too optimistic?
I’m guessing this issue is currently the same on all of Distro’s using gdm and kdm.
If I try to enter tty, the only thing I ses is a black screen.
Fedora 22 kde 4.1.7
sudo cp /usr/include/linux/version.h /lib/modules/`uname -r`/build/include/linux/
no such file or directory
ls -al /lib/modules/`uname -r`/
total 3264
drwxr-xr-x. 6 root root 4096 28 set 20.18 .
drwxr-xr-x. 5 root root 4096 28 set 20.15 ..
lrwxrwxrwx. 1 root root 38 14 set 22.31 build -> /usr/src/kernels/4.1.7-200.fc22.x86_64
drwxr-xr-x. 5 root root 4096 23 set 21.31 extra
drwxr-xr-x. 12 root root 4096 23 set 21.31 kernel
-rw-r–r–. 1 root root 849230 28 set 20.15 modules.alias
….. omitted some modules files…..
lrwxrwxrwx. 1 root root 5 14 set 22.31 source -> build
drwxr-xr-x. 2 root root 4096 14 set 22.30 updates
drwxr-xr-x. 2 root root 4096 23 set 21.31 vdso
ls -al /usr/src/kernels/
total 8
drwxr-xr-x. 2 root root 4096 16 ago 2014 .
drwxr-xr-x. 4 root root 4096 28 set 20.16 ..
Installation abort!
Need help!
Go to ‘/usr/include/linux/version.h /lib/modules/’ and run ls within that directory check and see if your kernel version is there also make sure you have all the prerequistes installed ‘dnf install gcc kernel-headers kernel-devel’
you’re right! I missed kernel-devel dependency!!!
Now all it’s ok. Fedora 22 kde 4.1.7.
Thanky very much!
4.1.7-200.fc22.x86_64, AMD Mobility Radeon HD 5000
Installation worked like a charm, thanks for the effort.
But performance wise it’s worse than mesa.
glmark2 reports 497, while on mesa 6xx!
I’ve seen better performance on my Radeon 7970 with higher settings enabled.
Had someone tried with the 4.1.8 kernel?
Works fine with 4.1.8 🙂
Great to know, going to update the kernel then 😀
On a fresh install of Fedora 22 with the 4.1.8 kernel, I get the following error when starting steam:
“OpenGL GLX context is not using direct rendering, which may cause performance problems.”
Any ideas?
Yeah, as I write in the post, that’s usually a sign that you need to reinstall the driver. If you tried to install it while simultaneously updating dependent packages (like Mesa packages, or maybe Xorg packages, or somesuch) it might have broken. Try uninstalling the driver, restart, fully update your system, restart, and try installing again. Let me know how it goes.
Even works with the 4.1.10 kernel
Not so much with 4.2.3
Yeah broken building the kernel module in 4.2.3
make -C /lib/modules/4.2.3-200.fc22.x86_64/build SUBDIRS=/usr/lib/modules/fglrx/build_mod/2.6.x modules
make[1]: Entering directory ‘/usr/src/kernels/4.2.3-200.fc22.x86_64’
CC [M] /usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:194:22: fatal error: asm/i387.h: No such file or directory
compilation terminated.
scripts/Makefile.build:258: recipe for target ‘/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o’ failed
make[2]: *** [/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o] Error 1
Makefile:1390: recipe for target ‘_module_/usr/lib/modules/fglrx/build_mod/2.6.x’ failed
make[1]: *** [_module_/usr/lib/modules/fglrx/build_mod/2.6.x] Error 2
make[1]: Leaving directory ‘/usr/src/kernels/4.2.3-200.fc22.x86_64’
Makefile:88: recipe for target ‘kmod_build’ failed
make: *** [kmod_build] Error 2
build failed with return value 2
Did you make sure to cp the version.h file to the new kernel directory
“error: asm/i387.h: No such file or directory”
i387.h and fpu-internal.h were renamed and moved to the fpu directory.
https://github.com/torvalds/linux/commit/df6b35f409af0a8ff1ef62f552b8402f3fef8665
Try this additional pach
http://cvs.rpmfusion.org/viewvc/rpms/catalyst-kmod/devel/kernel_4.2_FPU.patch?revision=1.2&root=nonfree&view=markup
Sorry Leigh, but when using that patch and kernel 4.2.3 I’m getting these messages after rebooting:
[ 90.787602] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
[ 90.963809] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
[ 90.963861] 8021q: adding VLAN 0 to HW filter on device enp3s0
and the system hangs. Can’t do nothing but a hard reboot (reset button on PC) …
Sincerely,
HH:-(
I’m having the issue of it hanging in the make_install.sh at the line of modprobe fglrx. It does not install correctly
I’m getting:
fglrx-install.yoG0OX]# patch -p0 < kernel_4.2_FPU.patch
can't find file to patch at input line 15
Perhaps you used the wrong -p or –strip option?
The text leading up to this was:
————————–
|From eb7beb0ea51de526e59a0c3edc76530b28ef10e7 Mon Sep 17 00:00:00 2001
|From: Alberto Milone
|Date: Tue, 14 Jul 2015 12:56:37 +0200
|Subject: [PATCH 1/1] Add support for Linux 4.2
|
|Deal with the FPU code renaming
|—
| firegl_public.c | 38 ++++++++++++++++++++++++++++++++++++++
| 1 file changed, 38 insertions(+)
|
|diff –git a/firegl_public.c b/firegl_public.c
|index 1a39fb7..baec03a 100755
|— lib/modules/fglrx/build_mod/firegl_public.c
|+++ lib/modules/fglrx/build_mod/firegl_public.c
————————–
File to patch:
Hope this helps to solve the issue……
Thanks for all rhe support so far. Up until this one all worked.
Hi Ed, yes but if you edit the patch and change:
— lib/modules/fglrx/build_mod/firegl_public.c
+++ lib/modules/fglrx/build_mod/firegl_public.c
with:
— common/lib/modules/fglrx/build_mod/firegl_public.c
+++ common/lib/modules/fglrx/build_mod/firegl_public.c
it worksand makes the patching then installs with no issues, but when rebooting it just hangs (maybe something amiss?) …
Sincerely,
HH:-(
I seem to be in the same situation. I patched, however, by placing the patch in the common directory of fglrx-install.xxxxx then cd into common and apply the patch. The installation seemed fine (had to use the –force option because of a missing fglrx uninstall script???) but then the machine boots to a black screen (no screen). The machine is fine otherwise (I can ssh into it).
Hi Leigh,
Thanks for the patch, but fglrx.ko stack traces. I hope http://pastebin.com/KhJybWq1 can help in debugging.
ta
What are the steps you guys have done up to this point? Possibly the patch information is still looking for 4.1.*** kernels vs 4.2.*** may have to have wait on Bitwise to report back. What version of linux are you guys using that has 4.2.*** Arch?
Sorry for the late reply, I’m using Fedora 22 (KDE version). I got the 4.2.3 kernel in an update and decided to try since there was a patch to try following this blog.
Like I said before, maybe Leigh’s patch is missing something. It does patch the firegl_public.c (with the necessary changes) without errors and does install without issues (no errors in log), but when rebooting It just hangs with the above mentioned messages.
I know it’s a hassle dealing with the fglrx (sorry, catalyst) driver, but that’s how it goes. Hope someday those guys get the latest kernels (or maybe use Bohdi) so they get their drivers squared away.
In the meantime, this is it. Someone gets a patch that works for the current kernel. I don’t mind trying it (so do everyone else). Sometimes one has things that others don’t installed and that’s how discrepancies occur.
Like I said before, I’m trying to be helpful in describing the best I can my experience with the patch and the process to get it to work (and before you ask, yes I did check all steps, especially the one about the kernel-header version.h; I myself have missed it sometimes in the past, but that’s not the case now).
Sincerely,
HH:-)
Hi
If your system hangs when rebooting, you have to boot into level 3 (text mode) and go to /etc/X11 directory and see if you have a Xorg.0.log file. If you are not running Xorg, you would not.
I yes run a
grep EE Xorg.0.log
and post the results here.
Hi Gil, I’m unable to comply because it won’t get to the graphical X environment.
This is what grep EE Xorg.0.log has:
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
I’m capable of getting to runlevel 3 with “telinit 3” in the grub entry, but to get the Xorg.0.log I must do a startx and that’s when it hangs.
I managed to print the messages that I get after telinit 3 and before login:
Fedora release 22 (Twenty Two)
Kernel 4.2.3-200.fc22.x86_64 on an x86_64 (tty1)
localhost login: [ 18.268631] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
[ 18.268708] 8021q: adding VLAN 0 to HW filter on device enp3s0
[ 21.086794] e1000e: enp3s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 21.087042] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
[ 27.791441] Adjusting tsc more than 11% (3655744 vs 4640019)
Fedora release 22 (Twenty Two)
Kernel 4.2.3-200.fc22.x86_64 on an x86_64 (tty1)
localhost login: HH
Password:
Last login: Mon Oct 19 16:34:06 on tty1
[ 43.408151] systemd-journald[817]: File /var/log/journal/3fc5d1d91d984743bf1b76a97f3f1246/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
After that if I try to startx it just hangs, no Ctrl+Alt+Fsomething works (to open other session and check).
I thought it was Selinux acting up again so I turned it off and tried, but no dice, and with the radeon driver I can login into X.
Before you ask, yes I’ve got my disks encrypted. It’s like not going all the way in the booting process and doesn’t let the graphical interface come up that’s why I thought the patch was missing something (with kernel 4.2.3 there where a few other updates specially for NetworkManager, and yes I did downgrade NetworkManager to see if that fixed the issue, but no dice).
Hope this helps …
HH:-\
“I’m capable of getting to runlevel 3 with “telinit 3” in the grub entry, but to get the Xorg.0.log I must do a startx and that’s when it hangs.”
No . Why would you have to startx to get the Xorg.0.log file ? It is written at every startx. So when you boot into level 3, you can look at the result of the preceding try of startx, just typing a
cd /etc/X11 then the command I told you.
If you think that what you have posted is all this command returns, so execute a
ls -l /etc/X11/ Xorg.*
to see if there are files of this type, and their date anf length.
Hmmm. The current status on my machine (Fedora 22, AMD Radeon HD 5450, xorg-x11 1.17.2-2) is that all works fine with kernel 4.1.10. I am not installing any updates after that, because I know it will break it. I can see that kernel 4.2.5 and xorg-x11 1.17.3-1 are available in my “dnf update” already (and then some).
Is there going to be a working patch for kernel 4.2.x any time soon?
I’d love to help out keeping my system current, along with many other users with a fedora/amd combo.
Maybe someone could give a few pointers as to how to go about it…
Maybe i should just use the generic drivers in fedora…
Maybe i should save some money to buy a different videocard…
So far i enjoyed the updates and wish to say: thanks.
Hi,
Just installed the 15.201 driver on Fedora 21 with 4.1.8-100.fc21.i686+PAE.
Worked fine at the first time.
Thanjs again !
Hi There
My system details :
Fedora 22 with kernel version as 4.1.10-200.fc22.x86_64
I have also received the error:
echo -ne ‘/amd_xversion’ | dd conv=notrunc of=libglx.so bs=1 count=13 seek=$offset
dd: invalid number ‘’
Any resolution for the said error ?
As stated above… with the kernel version with kernel version as 4.1.10-200… even though with the above mentioned error It worked like a Charm… perfect!!!
Lot of Kudos!!!!!
I still have to do the activation of GDM in accordance with SELINUX as someone mentioned… will update on that part also once done…. right now it’s doing with lightdm…
cheers!!!
4.2.3 not work ((
I’ll get to this as soon as I can.
Hi there,
I got the same problems with Korora 22 with 4.2.3-200.fc22.x86_64 . Actually i just need the features to monitor the GPU temperature. Is there any way just to get the temp? thanks.
PS: excellent tutorial. Also is there any way to automatically update/reinstall Catalyst after new kernel installed?
Hey, thanks – I’m going to work on the kernel version issue soon. I have not devised a method to automatically reinstall the Catalyst driver in conjunction with kernel updates. I would like to, but I need to put more research and time into it.
Could anybody summarize all still open issues in the list ( prefferably with links to bugzilla )?
Just did a clean install of Fedora via the netinstall iso, I noticed that it’s come with the 4.2.3 kernel – has anyone managed to successfully get fglrx working under this?
This patch
http://cvs.rpmfusion.org/viewvc/rpms/catalyst-kmod/devel/kernel_4.2_FPU.patch?revision=1.2&root=nonfree&view=markup
Plus the original in this blog post, the drivers compile but I get a black screen on boot.
I am also in black screen limbo. After tinkering with kcl_ioctl.c and kcl_str.c I got the drivers to compile. The computer boots and leads to a “black” screen (no output from the card). My Xorg.0.log doesn’t reveal anything to me but I am no expert in decoding the output
Filed a bug report here to at least have someplace to store some descriptive files http://ati.cchtml.com/show_bug.cgi?id=1206
I can’t even revert to mesa drivers at this point ( I get the Oh no! something has gone wrong ).
Did you try with Xfce desktop and lioghtdm ? It seems that fglrx has issues with gdm.
I wasn’t having any luck with the patch applying it to firegl public.c file I think it was called. Anyway you can post the file as you copied it. “@@ -6440,21 +6455,36 @@ static int KCL_fpu_save_init(struct task_struct *tsk)” this is the part of the patch that fails for me. Not sure why.
Unfortunately I don’t have a system that I can afford to tank. But I have been looking for several days for a solution to this and I think I may have found something if someone would be willing to test?
This patch here looks like it might solve these issues:
https://github.com/kolasa/fglrx-core-15.201/commit/9271cb89b7e02d4f30a208eed8cbb1afe4038be0
Hi Dominic, first of all if I apply your patch, it gets rejected:
— common/lib/modules/fglrx/build_mod/firegl_public.c
+++ common/lib/modules/fglrx/build_mod/firegl_public.c
@@ -6516,7 +6516,7 @@ void ATI_API_CALL KCL_fpu_begin(void)
KCL_fpu_save_init(cur_task);
#else
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
– fpu_save_init(&cur_task->thread.fpu);
+ copy_fpregs_to_fpstate(&cur_task->thread.fpu);
#else
__save_init_fpu(cur_task);
#endif
@@ -6547,7 +6547,7 @@ void ATI_API_CALL KCL_fpu_begin(void)
KCL_fpu_save_init(cur_task);
#else
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
– fpu_save_init(&cur_task->thread.fpu);
+ copy_fpregs_to_fpstate(&cur_task->thread.fpu);
#else
__save_init_fpu(cur_task);
#endif
If I apply ViOLO’s version, the diver installs with errors:
Supported adapter detected.
Check if system has the tools required for installation.
Uninstalling any previously installed drivers.
Creating symlink /var/lib/dkms/fglrx/15.201.1151/source ->
/usr/src/fglrx-15.201.1151
DKMS: add completed.
Kernel preparation unnecessary for this kernel. Skipping…
Building module:
cleaning build area…
cd /var/lib/dkms/fglrx/15.201.1151/build; sh make.sh –nohints –uname_r=4.2.3-200.fc22.x86_64 –norootcheck….(bad exit status: 1)
[Error] Kernel Module : Failed to build fglrx-15.201.1151 with DKMS
[Error] Kernel Module : Removing fglrx-15.201.1151 from DKMS
——————————
Deleting module version: 15.201.1151
completely from the DKMS tree.
——————————
Done.
[Reboot] Kernel Module : dracut
Sorry …
If also noticed that when using kerrnel 4.2.3 things don’t run the same, right now I’m having trouble typing this comment. It jumps as I type (bad kernel?) …
HH:-(
I’ve tried both but to no avail. I found the error with applying 4.2.X Kernel patch that I was having. Seems like you have to install IRQ patch Leigh has up as well. I wouldn’t be surprised if all the previous patch files have to be redone for kernel 4.2.X so, that the Radeon drivers build correctly. If you install the drivers and it fails look up on how to boot into multi-user.target. May be to involved for some but those who want to tinker around with drivers and aren’t afraid of rendering there system useless for a few minutes 😉 go for it. It’s not to bad. I’m currently studying for Sys Admin cert so this is good experience for me :D. If anyone has any updates please update and share maybe we can crack this or maybe AMD will post updated drivers soon 🙄 ^_^
Are there any updates on this? Arch users appear to have it working with the driver in their AUR…
Hi all!
http://ati.cchtml.com/show_bug.cgi?id=1189#c11
# ln -sf /usr/bin/gcc-4.9 /usr/bin/gcc
is actually gcc compatibility issue,
use gcc-4.9 would make it working.
gcc on fc21 is already 4.9.2-6 and on fc22 5.1.1-4 Is the reason it does not work with kernel 4.2.3 because of the new gcc version?
Not sure how this relates – but I have been getting random blank screens and system freezes this week in KDE with fedora 21 kernel 4.1.8. I initially thought it was the driver so upgraded to the Catalyst 15.9 with the patch you posted. That did not resolve the problem. When this happens the screen blanks – either black or off-white with faint stripe and no input possible via keyboard or mouse. I also cannot ssh from another machine. (Curiously, this also happened during a Skype session and the correspondent was able to see me and audio continued to work both ways – so not all networking was suspended). Today I opened up the session using the previous kernel 4.1.7. Amazingly, so far no crashes – so it must be something in the 4.1.8 kernel that affects either the video card or something else in the system. I am reinstalling the Mesa Radeon driver on another machine I upgraded to fc22 with the 4.2.3 kernel to see how the performance compares. There does not appear to be another option at this time.
The problem I had with the blank screens and system freezes was because the video card was failing and not the driver.
Just installed the open source mesa radeon drivers on fc22 kernel 4.2.3. after jumping a few hurdles I have to say I am impressed. Works well and so far no glitches.
To verify – the mesa radeon open source drivers work very well with the fcc22 kernel 4.2.3 and Plasma 5.4.2 – with the card I am currently using: Radeon HD 7570.
I am upgrading the card to a Radeon R9 380 4GB 256-Bit GDDR5 this week and will let you know how the open source drivers fare with that one.
As AMD appear to have compiled their Catalyst 15.9 driver with an earlier version of gcc their does not seem much point in pursuing the proprietary route at this time – particularly as the current mesa drivers perform so well.
Do someone successfully installed this on AMD APU ?
I use A8-7650k and after install fglrx , i cant get gdm running. Xorg log shows that fglrx can’t recognize the adapter and throws and unspoported bios error..
Not yet. I’ve only done a little work on the matter, but sadly it seems unfortunately complex in comparison to previous issues.
Isn’t the only outstanding issue now, that fglrx needs to be compiled under a different version of gcc?
“Compiling the fglrx-installer with gcc 4.9 fixed this problem, but it’s a workaround and not the fix. (I guess).
You can get the patch here: https://launchpadlibrarian.net/219738583/fglrx-installer-15.201_force-gcc_4.9.patch” …from Sergey Kislyakov (defman21) in https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1493888
Hello SPython, do you have any site or instructions, on how I can install the mesa radeon drivers ? Also do you know if they will help on the CrossFire setup ? Thank you ….
The following is what I recommend – and forgive me if I miss anything. It is best to check everything against others’ experience, too.
1. Uninstall fglrx
sudo aticonfig –uninstall
2. Permanently remove “nomodeset” from /boot/grub2/grub.cfg
3. Check that Radeon is not blacklisted in /etc/modprobe.d
4. dnf reinstall xorg-x11-drv-*
5. dnf install mesa-debuginfo mesa-demos mesa-dri-drivers mesa-filesystem mesa-lib3d mesa-libEGL mesa-lib-EGL-devel mesa-libgbm mesa-libGL mesa-libGL-devel mesa-libglapi mesa-libGLES mesa-libGLES-devel mesa-libGLU mesa-libGLU-devel mesa-libGLw mesa-libGLw-devel mesa-libOSMesa mesa-libwayland-egl mesa-libwayland-devel mesa-libxatracker
[NOTE: You may have many of these already install and some may be unecessary – but they cover many bases]
6. dnf install llvm-libs
7. Reboot and may the gods be with you!
Caveat: I cannot guarantee that this will work flawlessly – but I believe these were the steps I followed. I do not know the extent to which CrossFire is supported. I have just purchased a Radeon R9 380 4GB card which I hope to receive and install tomorrow. I believe the R9 380 has mesa support but the 390 may not have. I will report back my experience once I have installed the new card.
More info here: http://www.x.org/wiki/RadeonFeature/
Thank you, I have check the link and it does not support CrossFire at the moment, so I guess I will stick with the 4.1 kernel until the update the driver ….
My experience installing the Radeon R9 380 4GB card with the existing mesa drivers (10.6.9) in Fedora 22 with kernel 4.2.5 has not been a good one. The current mesa drivers will only provide xrender compositing for the card (any attempt to choose GLX reverts to xrender). After installation the plymouth boot screen no longer showed the fuse graphic but the horizontal phase loader(not sure what you call that) you get with proprietary drivers. I then managed to break the kde login (just a black screen) by loading the version 11 mesa drivers and other libraries in the hope they would have more support for the new video card. I was able to recover by first backing up the config, cache and .kde directories and then reinstalling with “dnf install @kde-desktop” which allowed me to login to plasma and then recover my configuration by restoring the saved directories.
It is said that AMD is now lending code support to the mesa development and kernel 4.3 may, hopefully, have open source support for cards like the R9 380. Not sure if that will be part of fc23 – probably fc24. In the interim can one have any slim hope that AMD will get it together to support the current kernel versions with their proprietary driver?
Does anyone else here have a similar graphics card and what success have you had, if any?
Of interest:
https://bugzilla.redhat.com/show_bug.cgi?id=1259542
In the process of upgrading to fc23 Will let you know how that handles the R9 380.
I am happy to report that after upgrading to Fedora 23 my r9 380 can now access OpenGl 3.1 and so full desktop effects are enabled. The upgrade was not easy. Anyone who had installed kernel-devel packages or other drivers will not have an easy transition with dnf system-upgrade. The problem being that the upgrade does not identify conflicts before it downloads the packages but later. If you do the upgrade – remove kernel-devel packages first and lesstif-devel. Then do a distro-sync and a clean all. AMD have contributed code to the amd-gpu driver that is now included in the fc22 kernel and the fc23 kernel. You need to upgrade to fc23 so that with the combination of the mesa 11 and new xorg drivers you can access openGL3.1. Upcoming kernels should make OpenGL 4.2 available. Cheers!
Hi
You mean tjat it will not be necessary to install the proprietary driver in the future ?
Thx
I’ve upgraded as well and have not yet gotten OpenGL 3.1 support. Could you post more detailed instructions?
Installing the proprietary driver has also failed for me.
Yeah, I’m sorry – I’m trying to get to this. It seems to be a bit of a doozie.
It would seem that way. With FC23 I have full compositing with OpenGL 3.1. It has the AMDGPU driver in the kernel and the mesa 11 libraries. I do not think Crossfire is implemented. It is not something I need and I have no way of testing it. Nor do I know the clock speeds with the current Open Source drivers. If someone could recommend a good Linux program to test the card I would be happy to provide the benchmarks. I refer you to the discussion in this link
and the reports in other links below:
http://blogs.s-osg.org/wayland-atomics-ahead/
http://wccftech.com/amd-announces-amdgpu-kernel-driver-linux/
http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/813041-the-new-amd-gpu-open-source-driver-on-linux-4-2-works-but-still-a-lot-of-work-ahead
http://www.mesa3d.org/
Thomas, did you remove the proprietary driver and reinstall xorg drivers before you did the upgrade? (See notes above.) Make sure you have removed “nomodeset” from the kernel boot line. If you had reverted to the radeon open source drivers before upgrading to fc23 then the upgrade would install the relevant mesa v11 drivers. Also ensure that you have selected OpenGL 3.1 in Compositor. If it was automatically set to xrender before the upgrade (because OpenGL was unsupported for your card in fc22) it will retain the previous setting. Which video card do you have?
Is it possible to install driver on Fedora 22 with 4.2.6-200.fc22.x86_64 kernel?
So the new AMD Crimson driver for Linux was released today, early reports suggest that it has 4.2 Kernel support out of the box (even though the release notes say differently). I managed to successfully compile the driver under 4.2.6 on F23, but got a black screen on reboot. I’m thinking that maybe the gcc5 problem is still there.
Can anyone confirm?
Using Kernel 4.2.6 on FC22. The Crimson driver compiled clean, and booted up fine. I was able to run fgl_glxgears.
I can’t as much confirm that but I can say there is high chance that’s the cause.
Officially AMD is still at about Kernel 3.19 which is old as…very old…
Thus they are prepared for environment about that “age” and GCC 5 is deffinitelly NOT part of that circle.
It’s sad that AMD is so much late with Kernel and stuff…nVidia can keep up with all that just fine AND have packages in repository…what makes AMD different in that matter?
The new driver compiled clean, and ran fine under FC22 and kernel 4.2.6. I was able to run fgl_glxgears after the restart.
AMD Crimson Drivers work without any patching to the install. I just followed the install up until the point of adding the custom patch for kernels. Then, I ran the installer for Crimson completed successfully. Once that was done I changed setenforce=0 to put selinux in permissive mode. Adjust the selinux permissions so that you can put it back to enforcing and you should be all set. Try using selinux troubleshooter or go up to one of my previous posts about gdm and selinux. Using gnome and finally back with AMD Drivers so happy right now. Thank you AMD for easing our fustration.
Hmm it seems that gcc5 isn’t broken then – however I get a segfault on Fedora 23 with my Radeon R7 APU (Kaveri). It could just be broken on F23 then – how are you guys installing the driver – rpm or compiling it via the installer?
Compiled it using the installer. It was really nice not having to apply a bunch of patches first 🙂
I am using a HD7700 card.
I upgraded (clean install) to FC23, and now I get a segfault also. The driver doesn’t like something in FC23. I thought it might be selinux. But disabling it didn’t make any difference. 😦
The new driver does not work with HD 6000 series card 😦
Looks like my video card doesn’t support anymore Radeon HD 7640G
It seems that unlike indicated on their compatibility list page at
http://support.amd.com/fr-fr/download/desktop?os=Linux+x86
this Crimson driver does not support HD5000 series cards.
If I’m wrong, just tell me.
Thx
FC22 has Xorg 1.17.4 while FC23 has Xorg 1.18. That may cause the core dumps on
FC23. I have the new Crimson driver running on FC22, 4.2.6 kernel, and R7 240 card.
Hello, this is akward. I have a problem with the line:
$ mv ~/Downloads/Catalyst159-Kernel416.patch ./ #this is not necessary, but I do it for sanity’s sake, to keep the patch file with the patched code as a reminder
$ patch -p0 < Catalyst159-Kernel416.patch
i got from bash: the order patch is not found!
I'm a new fedora user, i just got fedora 23 with kde. I will appreciate your help through this. Thanks
Try “dnf install patch” – looks like you may not have the package installed.
On Fedora 22 it may be “yum” install patch 😉
@Gil:
Fedora 22 uses already dnf, where “yum” is deprecated and a kindofalias yo dnf.
Afaik, reading @Enrique Betancourt we can find that he’s using Fedora23…
So, Enrique, with Fedora23, please install patch as @bitwiseoperator said and then you will need a few of things… I sugest you to read that page, specially the comentaries from people:
Thanks for theadress, I didn’t know it.
sir bitwiseoperator master.. how do I install fglrx version 15.201 / 15.9 on fc23 w/ kernel 4.3.3-300? unless the crimson driver will work with my hardware.. does a patch / instruction exist for 4.3.3 or will I need to revert to kernel 4.1.6 as that was the last patch posted for 15.201 / 15.9? I have done this installation many times on different kernels / older fedora versions but proceed based on the last patch developed for a specific kernel. thank you for the maintenance of this feed.
and as Gil said, the Crimson driver will not work with 5000 series cards so I will need 15.9 / 15.201.
Hey guys, all good running Fedora 22 with kernel 4.3.4 and crimson drivers running kdm and kde plasma needed to use Suren’s 4.3 patch which worked great! Thanks Suren!
As for fglrx-15.302, the second hunk in the patch isn’t need anymore and therefore was removed
https://gist.github.com/onreachable/d91fb3e62c72f461b0bd
Thank you so much bitwise!!
Hey man, thank you! This wouldn’t be happening without all of us.