cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

yurtesen
Miniboss

Ubuntu 11.10 SDK 2.6 giving segmentation faults

Hello,

I just installed AMD Catalyst 12.2 and SDK 2.6 on a fresh Ubuntu 11.10 installation and I am getting segmentation faults when running any OpenCL program, including samples and even clinfo when I run them from the terminal within X... They all give "Segmentation fault"

However when I connect to machine with ssh and set DISPLAY=:0 then they work fine. I tried to set the DISPLAY from the terminal also but it has no effect (besides it was probably set by default anyway). I also tried COMPUTE:=0 from terminal in X and I still get segmentation faults...

The kernel is:

Linux extremum-desktop 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Does anybody know why this is happening? or any hints on what to look for?

Thanks,

Evren

0 Likes
1 Solution

Yes, login was working because the clinfo was not able to find GPU. (therefore no segmentation fault with CPU only).

I found my problem could have been a mixture of stuff..

First of all, after installing app sdk, maybe I should have re-installed catalyst to avoid segmentation fault?

http://devgurus.amd.com/message/1278575#1278575

When I installed catalyst, it installed libraries to /usr/lib64 for some reason and X stopped working altogether. I found out that the libraries were installed to /usr/lib64 which is wrong. I went ahead and removed everything.

Then I found this hint which suggests linking /usr/lib to /usr/lib64 in ubuntu

http://ubuntucomputing.blogspot.com/2012/01/amd-catalyst-121-driver-on-hp-pavilion.html

I have done the link and re-installed everything. It works!

View solution in original post

0 Likes
11 Replies
yurtesen
Miniboss

oh well, in ssh, it does not find GPU at all so.. perhaps thats why it works... (because I wasnt logged in as the same user)

When I login properly, result is same... GPU is causing segmentation faults.:

$ fglrxinfo

display:   screen: 0

OpenGL vendor string: Advanced Micro Devices, Inc.

OpenGL renderer string: ATI Radeon HD 5800 Series

OpenGL version string: 4.2.11554 Compatibility Profile Context

$ clinfo

Segmentation fault

0 Likes

I also get this behaviour with Catalyst 12.2 under OpenSUSE 12.1:

~> clinfo

Segmentation fault

I have a HD5850 card.

As this is my first OpenCL attempt I have no idea how to proceed...

0 Likes
notzed
Challenger

If ssh login works, then it's probably something to do with your environmental variables, LD_LIBRARY_PATH most likely, try comparing those.

Use 'strace -e open testprogram' to see what libraries are actually being opened: since you have it working in one case this gives you an easy way to compare what's different.

0 Likes

Ah, yes: my problem was an older version of AMD APP sdk under /opt/AMDAPP. The installation script from that old installation had created lines in /etc/profile setting LD_LIBRARY_PATH, and also files in /etc/ld.so.conf.d. The result: the newer version of clinfo tried to use the older version of libOpenCL.so.

Removing the LD_LIBRARY_PATH lines in /etc/profile and the two files /etc/ld.so.conf.d/amd* and then running ldconfig solved the problem.

0 Likes

Yes, login was working because the clinfo was not able to find GPU. (therefore no segmentation fault with CPU only).

I found my problem could have been a mixture of stuff..

First of all, after installing app sdk, maybe I should have re-installed catalyst to avoid segmentation fault?

http://devgurus.amd.com/message/1278575#1278575

When I installed catalyst, it installed libraries to /usr/lib64 for some reason and X stopped working altogether. I found out that the libraries were installed to /usr/lib64 which is wrong. I went ahead and removed everything.

Then I found this hint which suggests linking /usr/lib to /usr/lib64 in ubuntu

http://ubuntucomputing.blogspot.com/2012/01/amd-catalyst-121-driver-on-hp-pavilion.html

I have done the link and re-installed everything. It works!

0 Likes

->Please install SDK 2.6 then install catalyst 12.2

->startx

->run clinfo

0 Likes

That was not enough, I also had to link /usr/lib to /usr/lib64

See the link:

http://ubuntucomputing.blogspot.com/2012/01/amd-catalyst-121-driver-on-hp-pavilion.html

0 Likes

you should really not do that.

all you need to do is add it to /etc/ld.so.conf or LD_LIBRARY_PATH, softlinking directories around in /usr could lead to problems down the track - there's a reason /usr/lib64 exists and is distinct from /usr/lib

This sort of system-dir splatting is what the AMD installer is doing, and causing all these problems in the first place.

0 Likes

No, actually /usr/lib64 does not exist on 64bit Ubuntu (I dont know about the 32bit Ubuntu for sure, I think they have /usr/lib64). There is only /usr/lib on 64bit Ubuntu.

Even using LD_LIBRARY_PATH would not be enough, because then X wouldnt be able to find the fglrx driver which is installed to /usr/lib64/xorg/modules* anyway.

What AMD installer is doing is wrong. It should install those stuff to to /usr/lib on 64bit Ubuntu. (thats what I figured)

I blame Linux, there are too many distributions which does not agree on even simple things like where the libraries should go.... This is what happens when everybody make their own Linux distribution...

0 Likes

yurtesen wrote:

No, actually /usr/lib64 does not exist on 64bit Ubuntu (I dont know about the 32bit Ubuntu for sure, I think they have /usr/lib64). There is only /usr/lib on 64bit Ubuntu.

Oddly enough, I was confused by your language: "also had to link /usr/lib to /usr/lib64" which clearly states the exact opposite.  In any event the comment stands.

There would be no point for /usr/lib64 on a 32-bit os.

Even using LD_LIBRARY_PATH would not be enough, because then X wouldnt be able to find the fglrx driver which is installed to /usr/lib64/xorg/modules* anyway.

Well I said use ld.so.conf or LD_LIBRARY_PATH, the first is system-wide naturally ...  X uses it's own path as well.

It's not ubuntu's fault per-se, even the AMD script is broken on every other system as well.

0 Likes

notzed wrote:

yurtesen wrote:

No, actually /usr/lib64 does not exist on 64bit Ubuntu (I dont know about the 32bit Ubuntu for sure, I think they have /usr/lib64). There is only /usr/lib on 64bit Ubuntu.

Oddly enough, I was confused by your language: "also had to link /usr/lib to /usr/lib64" which clearly states the exact opposite.  In any event the comment stands.

There would be no point for /usr/lib64 on a 32-bit os.

Well, perhaps natural language is ambiguous (and it appears I made a mistake ) I meant 'ln -s /usr/lib /usr/lib64' and there was no /usr/lib64 (besides one which looked like AMD installer created)

Well, there might be a /usr/lib64 on Ubuntu 32bit (according to some post I found through google) but I checked on a netbook running ubuntu 32bit and there is no such thing there, only /usr/lib... in any case, not very relevant...

notzed wrote:

Even using LD_LIBRARY_PATH would not be enough, because then X wouldnt be able to find the fglrx driver which is installed to /usr/lib64/xorg/modules* anyway.

Well I said use ld.so.conf or LD_LIBRARY_PATH, the first is system-wide naturally ...  X uses it's own path as well.

Well, I see, I can eventually get it working from any directory obviously. But my point was that I shouldn need to edit the configurations of everything else when AMD installer can install the files to right place

It's not ubuntu's fault per-se, even the AMD script is broken on every other system as well.

Can be argued, because the script has to support every other ever slightly different system. If I now make a different Linux distribution which puts the 64bit libraries to /usr/amd64lib then script would get broken again for my new system even if it worked in all other systems.

Just last week Fedora 16 upgraded to kernel 3.3 and I had to edit kernel headers to be able to install the AMD driver. Not only AMD, the Nvidia drivers needed some editing in some kernel files too.

Although, you are right, the installer should at least know how to install files on Ubuntu at least (since it is rather popular). But then, if there was only 1 Linux distribution, we wouldnt be having so many different problems perhaps.

0 Likes