Radeon R9 290X not detected by BOINC

Message boards : BOINC client : Radeon R9 290X not detected by BOINC
Message board moderation

To post messages, you must log in.

Previous · 1 · 2

AuthorMessage
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14998
Netherlands
Message 65825 - Posted: 5 Dec 2015, 11:52:53 UTC - in response to Message 65824.  

Anything else you come up with that could show where things go wrong, just let me know and I'll forward it to behind the scenes.
ID: 65825 · Report as offensive
Profile Agentb
Avatar

Send message
Joined: 30 May 15
Posts: 265
United Kingdom
Message 65834 - Posted: 5 Dec 2015, 17:49:42 UTC - in response to Message 65825.  

Anything else you come up with that could show where things go wrong, just let me know and I'll forward it to behind the scenes.


The init.d scripts which start boinc (boinc-client) do not appear to log their output, this would be helpful.

#! /bin/sh
### BEGIN INIT INFO
# Provides:          boinc boinc-client
# Required-Start:    $all
# Required-Stop:     $local_fs $remote_fs
# Should-Start:      x11-common network-manager gdm kdm dbus lightdm
# Should-Stop:       x11-common
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: BOINC core client
# Description:       core client for the BOINC distributed computing
#                    infrastructure
### END INIT INFO

# Debian init.d script for the BOINC core client
# Copyright © 2005, 2006, 2007, 2008
# Debian BOINC Maintainers <pkg-boinc-devel@lists.alioth.debian.org>


Do they visit this forum?

<snip>
In particular this
       # grant the boinc client to perform GPU computing
       xhost local:boinc || echo -n "xhost error ignored, GPU computing may not be possible"
<snip>

does not look right.

According to xhost

local contains only one name, the empty string

I would suggest this should be xhost +SI:localuser:$BOINC_USER

Even if corrected - i suspect this xhost line may produce an error, and it needs to be seen.
ID: 65834 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14998
Netherlands
Message 65835 - Posted: 5 Dec 2015, 18:06:18 UTC - in response to Message 65834.  
Last modified: 5 Dec 2015, 18:19:18 UTC

Do they visit this forum?

Depends on who you mean with 'they'. :)

If in this case the
# Debian init.d script for the BOINC core client
# Copyright © 2005, 2006, 2007, 2008
# Debian BOINC Maintainers <pkg-boinc-devel@lists.alioth.debian.org>

I doubt it.

And it's been a while since I ran the Berkeley BOINC installer on a Linux-derivate, but does the Berkeley installer use init.d? I think those are only used by the BOINC maintained by package maintainers, started as a daemon.

So, in this case you'll have to find the package maintainer for Debian and tell him or her that. Sorry, I know it sounds very easy to point to others, but there is really no sense in asking the developers about something they didn't add to the package in the first place.

By default the Berkeley installer unpacks everything in the home folder, and you start the client and manager by hand.

Edit.. I think Gianfranco Costamagna is also the Debian maintainer these days.
ID: 65835 · Report as offensive
Juha
Volunteer developer
Volunteer tester
Help desk expert

Send message
Joined: 20 Nov 12
Posts: 801
Finland
Message 65838 - Posted: 5 Dec 2015, 22:02:08 UTC - in response to Message 65815.  

client (Unix): if libOpenCL.so isn't there, try libOpenCL.so.1

That what you wanted, Juha?

YEEEEESSSSSSSSSSSSS!!!!!!!

client (Unix): use dlerror() for GPU library failures; shows the filename


05-Dec-2015 23:55:22 [---] [coproc] launching child process at ./boinc
05-Dec-2015 23:55:22 [---] [coproc] relative to directory /tmp/b/BOINC
05-Dec-2015 23:55:22 [---] [coproc] with data directory /tmp/b/BOINC
05-Dec-2015 23:55:22 [---] NVIDIA: libcuda.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] ATI: libaticalrt.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] clGetPlatformIDs() failed to return any OpenCL platforms
05-Dec-2015 23:55:22 [---] No usable GPUs found


Thanks. You are a hero!
ID: 65838 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14998
Netherlands
Message 65840 - Posted: 5 Dec 2015, 23:07:31 UTC - in response to Message 65838.  
Last modified: 6 Dec 2015, 3:21:08 UTC

Glad you like it. On the hero stuff though, all I did was gather some of your comments from three different threads and send those off to the developers, pointing out the validity of those points. After which they nodded, agreed and added the new code. So you're as much a hero as anyone else. :)

I then saw Agentb post his post and thought, yep let's forward that part of dlerror(), and although I asked for it to be part of coproc_debug, David made it show always. Probably just as well.

Now, if only I knew what the errors meant and how to solve them. ;-)
ID: 65840 · Report as offensive
Profile Agentb
Avatar

Send message
Joined: 30 May 15
Posts: 265
United Kingdom
Message 65841 - Posted: 6 Dec 2015, 2:52:08 UTC - in response to Message 65840.  

Now, if only I knew what the errors meant and how to solve them. ;-)


I tried (and failed) to find a list of dlerrors, but seeing them is half way to solving them. I'm sure the dlopen of "libOpenCL.so.1" will make for more working GPUs by default (and less errors!) - that will help - a lot.

Regarding the install scripts, i'll have a look at the Berkeley installer tomorrow... but if the package installers are introducing problems we should not turn a blind eye to it, especially when we promote their use in the boinc documentation. There are a number of very good healthy reasons to run as user=boinc, and this functionality should be part of BOINC imho.
ID: 65841 · Report as offensive
floyd
Help desk expert

Send message
Joined: 23 Apr 12
Posts: 77
Message 65842 - Posted: 6 Dec 2015, 6:28:10 UTC - in response to Message 65838.  

05-Dec-2015 23:55:22 [---] NVIDIA: libcuda.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] ATI: libaticalrt.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] clGetPlatformIDs() failed to return any OpenCL platforms

Those messages need not, and should not, be part of the standard startup output. That information is usually not needed and is likely to cause confusion because it will be misinterpreted as errors. Instead make it debug output and perhaps add a hint to the list of detected GPUs to turn on debugging if the list is not correct.
ID: 65842 · Report as offensive
Profile Agentb
Avatar

Send message
Joined: 30 May 15
Posts: 265
United Kingdom
Message 65845 - Posted: 6 Dec 2015, 12:36:47 UTC - in response to Message 65842.  
Last modified: 6 Dec 2015, 12:37:46 UTC

05-Dec-2015 23:55:22 [---] NVIDIA: libcuda.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] ATI: libaticalrt.so: cannot open shared object file: No such file or directory
05-Dec-2015 23:55:22 [---] clGetPlatformIDs() failed to return any OpenCL platforms

Those messages need not, and should not, be part of the standard startup output. That information is usually not needed and is likely to cause confusion because it will be misinterpreted as errors. Instead make it debug output and perhaps add a hint to the list of detected GPUs to turn on debugging if the list is not correct.


Good point, I guess you mean we needed a summary log entry for each component saying "ok / not ok" and then another log entry to say "for more detail set the coprocessor debug flag"?

Would it be better leaving them in but make more user friendly (to the few people looking at it). We are logging now the linked library versions and details of other required components such as CPU capabilities at start.

Perhaps start with
"GPU and driver search phase - expect 'Not found' if no GPU installed" 


And instead of just

NVIDIA: libcuda.so.1: cannot open shared object file: No such file or directory


use a clearer

NVIDIA: CUDA library: Not found : (libcuda.so.1: cannot open shared object file: No such file or directory)


and (in a perfect world) if dlopen returns no error

NVIDIA: CUDA library: Found. (libcuda.so.1)


I would expect a debug flag if set for example to to show dladdr() information - which reports the full library path etc. That would help with symbolic and version issues (different .so and .so.1 for example)

If all this detail is deemed too much (three or four lines) then we need to put a very good hint about how to set the debug flags.
ID: 65845 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14998
Netherlands
Message 65848 - Posted: 6 Dec 2015, 16:33:31 UTC - in response to Message 65842.  

I agree, and I asked originally they be put under the coproc_debug flag, will re-ask that once more.
ID: 65848 · Report as offensive
floyd
Help desk expert

Send message
Joined: 23 Apr 12
Posts: 77
Message 65850 - Posted: 6 Dec 2015, 18:52:43 UTC - in response to Message 65845.  

I guess you mean we needed a summary log entry for each component saying "ok / not ok" and then another log entry to say "for more detail set the coprocessor debug flag"?

Not exactly, I'd basically keep it the way it is. Just list the detected GPUs and don't mention any others unless specificially asked, i.e. coproc_debug. We don't want to confront the user with everything that could be a problem, they just need to know what to do if there really is one. And there I can't think of anything better than a message in this place, though it doesn't really belong here in my opinion. Nobody seems to think of debug mode even if they know there's something wrong.

We are logging now the linked library versions and details of other required components such as CPU capabilities at start.

We are logging what we know about the system, not how we found out or what we don't know. I think we should stick with that scheme.

NVIDIA: CUDA library: Found. (libcuda.so.1)

If we find a GPU the user doesn't need to know how we did it. If we don't find a specific type we should only mention it if we know that something went wrong. But we can't know, only the user can.
ID: 65850 · Report as offensive
Profile Agentb
Avatar

Send message
Joined: 30 May 15
Posts: 265
United Kingdom
Message 65851 - Posted: 6 Dec 2015, 19:11:14 UTC - in response to Message 65835.  


So, in this case you'll have to find the package maintainer for Debian and tell him or her that. Sorry, I know it sounds very easy to point to others, but there is really no sense in asking the developers about something they didn't add to the package in the first place.

By default the Berkeley installer unpacks everything in the home folder, and you start the client and manager by hand.

Edit.. I think Gianfranco Costamagna is also the Debian maintainer these days.


BOINC Wiki says BOINC: compute for science Page "if available, we recommend that you install a distribution-specific package instead."

I think BOINC - Debian wiki is close to answers and especially associated git

It would be helpful to have a paragraph at the end of each http://boinc.berkeley.edu/wiki/Installing_BOINC_on_<distro> labelled Package Maintainer with the Debian or similar URL.

I'll drop them a line about xhosts

I looked at the installer provided as the Berkeley. It did not provide any daemon or start-up functionality, other than change directory and start the boinc executable.
ID: 65851 · Report as offensive
Juha
Volunteer developer
Volunteer tester
Help desk expert

Send message
Joined: 20 Nov 12
Posts: 801
Finland
Message 65852 - Posted: 6 Dec 2015, 21:48:16 UTC

Guys, even though the messages were lacking the [coproc] prefix they were debug log messages.


I'll do a bit more research on the xhost stuff later. I think it's going to be a bit harder nut to crack.
ID: 65852 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14998
Netherlands
Message 65862 - Posted: 7 Dec 2015, 18:41:28 UTC - in response to Message 65852.  

ID: 65862 · Report as offensive
Previous · 1 · 2

Message boards : BOINC client : Radeon R9 290X not detected by BOINC

Copyright © 2022 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.