Meanwhile, the best thing you can do is it to set the Einstein project prefferences to not use Nvidia GPU (in fact this will not stop the usage of the GPU, it will just stop sending new GPU tasks), then go to the Boinc Manager, and in advanced view, in the tasks tab, sort them by application, select all the BRP tasks and suspend them all. This way you can keep the host crunching with the CPU while waiting for somebody that gives you something more usefull to solve the GPU issue...
Done. Good idea, more useful than what I was about to do. :-)
Quote:
And also, in this way you will be able to resume just one at a time after doing changes to see if it's working...
I think that means I need to create a symlink to a file named libcuda.so.1 whose location I now know from grep, but where does the symlink to it need to go so that Einstein can find & use it? Thanks.
You have two options, either install teh NVIDIA drivers (incl. the libcuda) from a Linux repository with a package manager or download the driver from the nvidia site and use the NVIDIA installer.
But I understand you already installed a libcuda1-ia32 package by now and it still can't find the libcuda.so.1 file? That is strange. Instead of manually creating symlinks, I suggest to first check where (if at all) the libcuda.so.1 file got installed (e.g. use "find / -name libcuda.so.1" as user root). If for some reasons it is installed in a PATH that is not in the usual list of paths where the system looks for shared libraries, you can always set the LD_LIBRARY_PATH environment variable to include the path where the library is actually installed, and then BOINC and BRP4 will find this lib.
Attention to all Debian 64bit users on the Testing branch. Just recently the libcuda1-ia32 package was moved to libcuda1:i386 but the user doesn't get a good error message. If you are using a Debian 64bit version that is based on the Testing branch you should execute (as root):
Or try to use your prefered package manager to install the i386 version of the libcuda1 package. After this you will be able to run the 32bit CUDA Einstein@home app. You can also safely uninstall the libcuda1-ia32 package as it is not needed anymore.
At the moment this only applies to the testing branch of Debian linux!
Btw, I have only one libcudart candidate and cannot install it because it has a dependency on a higher version of libstdc++, so probably I just cannot do Einstein WUs for Cuda at this time. But thanks for the help.
Thanks, Bikeman. I've set the LD_LIBRARY_PATH environment variable to include the path where libcuda.so.1 is actually installed, and I will post here whether my next Einstein Cuda tasks complete, or error out again.
Btw, I have only one libcudart candidate and cannot install it because it has a dependency on a higher version of libstdc++, so probably I just cannot do Einstein WUs for Cuda at this time. But thanks for the help.
Let's see if the LD_LIBRARY_PATH fixes your issue. But keep in mind that the lincuda.so.1 you're pointing to can be the 64bit Version and therefor produce errors as well.
As I just checked with Debian package repo. The libcuda1-ia32 package for Squeeze still provides the 32bit CUDA library for 64bit systems. The one for Wheezy does not and states: please switch to multiarch libcuda1:i386. In order to switch you need the Wheezy version of libcuda1 that is depending upon the multiarch-support package that is needed to run # dpkg --add-architecture
For this package you wont need a newer libstc++
For libcudart4 (only available for Wheezy and Sid) it is roughly same. You have to install the multiarch-support to install the i386 version of it but also need a higher libstc++.
RE: Meanwhile, the best
)
Done. Good idea, more useful than what I was about to do. :-)
Good point.
August 2012 marks the 36th consecutive August and 330th consecutive month with a global temperature above the 20th century average.
RE: I think that means I
)
You have two options, either install teh NVIDIA drivers (incl. the libcuda) from a Linux repository with a package manager or download the driver from the nvidia site and use the NVIDIA installer.
But I understand you already installed a libcuda1-ia32 package by now and it still can't find the libcuda.so.1 file? That is strange. Instead of manually creating symlinks, I suggest to first check where (if at all) the libcuda.so.1 file got installed (e.g. use "find / -name libcuda.so.1" as user root). If for some reasons it is installed in a PATH that is not in the usual list of paths where the system looks for shared libraries, you can always set the LD_LIBRARY_PATH environment variable to include the path where the library is actually installed, and then BOINC and BRP4 will find this lib.
Cheers
HBE
Attention to all Debian 64bit
)
Attention to all Debian 64bit users on the Testing branch. Just recently the libcuda1-ia32 package was moved to libcuda1:i386 but the user doesn't get a good error message. If you are using a Debian 64bit version that is based on the Testing branch you should execute (as root):
Or try to use your prefered package manager to install the i386 version of the libcuda1 package. After this you will be able to run the 32bit CUDA Einstein@home app. You can also safely uninstall the libcuda1-ia32 package as it is not needed anymore.
At the moment this only applies to the testing branch of Debian linux!
I'm using Debian Stable, and
)
I'm using Debian Stable, and only pulling nVidia drivers & Cuda libraries from Testing. (As a result?) I get
Btw, I have only one libcudart candidate and cannot install it because it has a dependency on a higher version of libstdc++, so probably I just cannot do Einstein WUs for Cuda at this time. But thanks for the help.
August 2012 marks the 36th consecutive August and 330th consecutive month with a global temperature above the 20th century average.
Thanks, Bikeman. I've set
)
Thanks, Bikeman. I've set the LD_LIBRARY_PATH environment variable to include the path where libcuda.so.1 is actually installed, and I will post here whether my next Einstein Cuda tasks complete, or error out again.
August 2012 marks the 36th consecutive August and 330th consecutive month with a global temperature above the 20th century average.
RE: I'm using Debian
)
Let's see if the LD_LIBRARY_PATH fixes your issue. But keep in mind that the lincuda.so.1 you're pointing to can be the 64bit Version and therefor produce errors as well.
As I just checked with Debian package repo. The libcuda1-ia32 package for Squeeze still provides the 32bit CUDA library for 64bit systems. The one for Wheezy does not and states: please switch to multiarch libcuda1:i386. In order to switch you need the Wheezy version of libcuda1 that is depending upon the multiarch-support package that is needed to run # dpkg --add-architecture
For this package you wont need a newer libstc++
For libcudart4 (only available for Wheezy and Sid) it is roughly same. You have to install the multiarch-support to install the i386 version of it but also need a higher libstc++.