[SOLVED] Failed installing ati proprietary driver

vaenby · 12-23-2015, 11:55 PM

After reading slackware docs about installing proprietary drivers, I decided to give it a try.

I downloaded the necessary file (based on my laptop's graphic card this is the drivers), unzip it, and run the amd-driver-installer-*.run file and followed the steps as stated in slackware docs, but it failed.

Below is the content of fglrx-install.log:

Code:

Check if system has the tools required for Packages Generation.
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.15/build SUBDIRS=/home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x modules
make[1]: Entering directory '/usr/src/linux-4.1.15'
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
/home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:6448:12: warning: ‘KCL_fpu_save_init’ defined but not used [-Wunused-function]
 static int KCL_fpu_save_init(struct task_struct *tsk)
            ^
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.o
/home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.c:839:20: warning: ‘KCL_ACPI_Slot_No_Hotplug’ 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]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_agp.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_debug.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_io.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_pci.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_iommu.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl.o
  CC [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/kcl_wait.o
  LD [M]  /home/jal/Downloads/fglrx-15.302/fglrx-install.oSq7RY/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.o
  Building modules, stage 2.
  MODPOST 1 modules
FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol 'cpu_tlbstate'
scripts/Makefile.modpost:90: recipe for target '__modpost' failed
make[2]: *** [__modpost] Error 1
Makefile:1387: recipe for target 'modules' failed
make[1]: *** [modules] Error 2
make[1]: Leaving directory '/usr/src/linux-4.1.15'
Makefile:88: recipe for target 'kmod_build' failed
make: *** [kmod_build] Error 2
build failed with return value 2
ERROR: I didn't make module
[Error] Generate Package - error generating package : Slackware/Slackware

timsoft · 12-24-2015, 05:33 AM

you should find this post may help you http://www.linuxquestions.org/questi...nt-4175552235/

vaenby · 12-24-2015, 08:38 PM

Quote:

Originally Posted by timsoft

you should find this post may help you http://www.linuxquestions.org/questi...nt-4175552235/

Hi, timsoft. Thanks for the suggestion. After reading that post, I managed to create fglrx package successfully and continue the steps in slackware docs. But when I rebooted, and do startx, it failed. Is there any configuration to do outside of what's stated in slackware docs?

Sylvester Ink · 12-24-2015, 09:39 PM

Are you running slackware-current? It's using xorg 1.18, which the AMD drivers don't yet support. Another user was able to install it by building an older version of xorg and installing that.

I'm in the same boat as you, and I'm trying to figure out how to create an older xorg package.

Nille_kungen · 12-24-2015, 10:22 PM

If you got pre-GCN AMD hardware and running current then you shouldn't bother with catalyst at all.
Pre-GCN hardware support has been dropped in current/14.2 for catalyst driver and you should then use the open source radeon instead.
If you got GCN hardware on current and wants catalyst then you need to wait until AMD releases an updated driver that supports the software stack used by slackware-current/14.2 (which ever comes first catalyst supported drivers or new slackware release).

vaenby · 12-24-2015, 10:40 PM

Quote:

Originally Posted by Nille_kungen

If you got pre-GCN AMD hardware and running current then you shouldn't bother with catalyst at all.
Pre-GCN hardware support has been dropped in current/14.2 for catalyst driver and you should then use the open source radeon instead.
If you got GCN hardware on current and wants catalyst then you need to wait until AMD releases an updated driver that supports the software stack used by slackware-current/14.2 (which ever comes first catalyst supported drivers or new slackware release).

Mine is not pre-GCN AMD hardware I think. It's Radeon R5-M230.

vaenby · 12-24-2015, 10:45 PM

Quote:

Originally Posted by Sylvester Ink

Are you running slackware-current? It's using xorg 1.18, which the AMD drivers don't yet support. Another user was able to install it by building an older version of xorg and installing that.

I'm in the same boat as you, and I'm trying to figure out how to create an older xorg package.

Yes, I am running current

Well, thanks for the information. Hope that they can release drivers that support xorg 1.18 soon.

1337_powerslacker · 12-25-2015, 07:34 AM

Quote:

Originally Posted by Sylvester Ink

Are you running slackware-current? It's using xorg 1.18, which the AMD drivers don't yet support. Another user was able to install it by building an older version of xorg and installing that.

I'm in the same boat as you, and I'm trying to figure out how to create an older xorg package.

Use the following command to download the x11 SlackBuilds and its associated files from slackware.osuosl.org:

Code:

 lftp -c mirror http://slackware.osuosl.org/slackware64-current/source/x/x11/

Download the xorg-1.17.4 package, available from here, and save it to /your/download/path/x11/src/xserver. Delete the xorg-server-1.18.0.tar.xz file already in that directory.

A couple of caveats: in the x11.SlackBuild, make sure to tell the SlackBuild you do not want it to automatically upgrade your packages after it gets through building them

Quote:

# To not upgrade, pass UPGRADE_PACKAGES=no
UPGRADE_PACKAGES=${UPGRADE_PACKAGES:-yes}

unless, of course, you want it to.

Repackage the downloaded xorg-server package to .tar.xz as follows:

Code:

 tar xvf xorg-server-1.17.4.tar.bz2 && tar czf xorg-server-1.17.4.tar.xz xorg-server-1.17.4/ && rm -R xorg-server-1.17.4.tar.bz2 xorg-server.1.17.4/

After having done the preceding, issue the following commmand in the x11/ directory:

Code:

 chmod +x x11.SlackBuild
./x11.SlackBuild xserver

You should have the following 4 packages in /tmp:

Code:

 xorg-server*, xorg-server-xephyr*, xorg-server-xnest*, and xorg-server-xvfb*

Assuming you told the SlackBuild you didn't want the packages upgraded at time of build, issue the following command to upgrade the packages (cd to /tmp first):

Code:

 upgradepkg xorg-server-*

Now you can use the Catalyst/Crimson Edition driver. Hope this helps!

Regards,

Matt

vaenby · 12-25-2015, 10:14 PM

Quote:

Originally Posted by mattallmill

You should have the following 4 packages in /tmp:

Code:

 xorg-server*, xorg-server-xephyr*, xorg-server-xnest*, and xorg-server-xvfb*

Assuming you told the SlackBuild you didn't want the packages upgraded at time of build, issue the following command to upgrade the packages (cd to /tmp first):

Code:

 upgradepkg xorg-server-*

Now you can use the Catalyst/Crimson Edition driver. Hope this helps!

Regards,

Matt

Hi matt, thanks for a very detailed guide. A question though. Actually what I get after executing the slackbuild is those 4 packages in /tmp/x11-build (not /tmp) along with many other packages. Do I need to install only those 4, or others as well? Thanks.

Sylvester Ink · 12-26-2015, 03:00 AM

Quote:

Originally Posted by vaenby

Hi matt, thanks for a very detailed guide. A question though. Actually what I get after executing the slackbuild is those 4 packages in /tmp/x11-build (not /tmp) along with many other packages. Do I need to install only those 4, or others as well? Thanks.

That directory in /tmp is correct. You only need to install the packages found in there. (The other packages are previous builds/upgrades. Do an ls -ltr, which will show you the packages sorted to most recent, along with the date/time of the build. You'll see the xorg folder was created when you ran the slackbuild.)

I installed the resulting xorg packages, then reinstalled and configured the proprietary drivers. However, when trying to start xorg, it freezes up and I'm forced to reboot. The xorg log seems to indicate that evdev is built for xorg 1.18, and is conflicting with 1.17. Are we going to need to rebuild evdev as well? (That may be a mess since so many packages depend on it.)
I'll try to post a copy of the xorg log tomorrow.

1337_powerslacker · 12-26-2015, 05:11 AM

Quote:

Originally Posted by vaenby

Hi matt, thanks for a very detailed guide. A question though. Actually what I get after executing the slackbuild is those 4 packages in /tmp/x11-build (not /tmp) along with many other packages. Do I need to install only those 4, or others as well? Thanks.

What Sylvester Ink said was correct; I'd forgotten the packages were in a subdirectory of /tmp. My apologies.

1337_powerslacker · 12-26-2015, 05:17 AM

Quote:

Originally Posted by Sylvester Ink

That directory in /tmp is correct. You only need to install the packages found in there. (The other packages are previous builds/upgrades. Do an ls -ltr, which will show you the packages sorted to most recent, along with the date/time of the build. You'll see the xorg folder was created when you ran the slackbuild.)

I installed the resulting xorg packages, then reinstalled and configured the proprietary drivers. However, when trying to start xorg, it freezes up and I'm forced to reboot. The xorg log seems to indicate that evdev is built for xorg 1.18, and is conflicting with 1.17. Are we going to need to rebuild evdev as well? (That may be a mess since so many packages depend on it.)
I'll try to post a copy of the xorg log tomorrow.

Unfortunately, you've reached the limits of my knowledge on that subject. When I built those packages, I very well may have still been running the old udev package. It probably would be wise at this point to start a new thread to ask about the possibility of rebuilding eudev for the older xorg-server.

As I see it, you have 4 possibilities (listed in decreasing order of likelihood):

- Install 14.1, which has udev in it (timsoft's suggestion)
- Remove eudev/libgudev, and reinstall udev from 14.1 for -current
- Rebuild eudev to work with xorg-server 1.17.4
- Buy new hardware to work with xorg-server 1.18.0

This may not help any, but at least it might help you decide what to do at this point. Best of luck to you!

timsoft · 12-26-2015, 05:30 AM

of course, if you use slack14.1 instead of current, then it just works :-) But the more people that iron out the bugs the better.

Sylvester Ink · 12-27-2015, 03:08 AM

Quote:

Originally Posted by mattallmill

Unfortunately, you've reached the limits of my knowledge on that subject. When I built those packages, I very well may have still been running the old udev package. It probably would be wise at this point to start a new thread to ask about the possibility of rebuilding eudev for the older xorg-server.

As I see it, you have 4 possibilities (listed in decreasing order of likelihood):

- Install 14.1, which has udev in it (timsoft's suggestion)
- Remove eudev/libgudev, and reinstall udev from 14.1 for -current
- Rebuild eudev to work with xorg-server 1.17.4
- Buy new hardware to work with xorg-server 1.18.0

This may not help any, but at least it might help you decide what to do at this point. Best of luck to you!

Aww, I was getting my hopes up. (Made the mistake of buying a too-new videocard to replace one that died. Been running in terminal mode since then, waiting for a driver solution.

)

I moved to current because 14.1 didn't seem to support my card at the time, even with proprietary drivers. I could go back to 14.1 and try again, but at this point, I suspect it's just more expedient to stick around until Pat releases 14.2.
Rolling back to udev will likely cause issues, since there are a ton of packages that were rebuilt for eudev. Easier to reinstall 14.1.
I'll look into rebuilding eudev for xorg 1.17.4 and let you know what happens. Otherwise I'll continue waiting for the drivers I need. I'll also keep an eye out here if anyone else has a better idea. :P

Drakeo · 12-27-2015, 03:28 AM

I think the guys at fedora patched this in September. it is worth a look.
https://bluehatrecord.wordpress.com/...-kernel-4-1-6/