343.22, "No OpenCL Compatible Devices Found" [Linux]

[ChristianVirtual]

Just a quick update:
Downloading the drivers from nvidia does render a working system including opencl support.

That one is what I did ; together with the reinstall of CUDA6.5 for Maxwell under 14.04. Mostly all the times I run via original driver from nV and chose the GRUB way forcing the system in text mode to not get X in my way.

[Jesse_V]

Ok, so bollix47 and ChristianVirtual, what exactly did you do to get the .run installed properly and fully functional?

[ChristianVirtual]

worked on Ubuntu 14.04 and CentOS 7: Blacklisted nouveau in grub and config file, started in text mode via grub, no splash, no quite mode. Login via console, copied over the .run file from nV site (have a copy on a different box); installed whatever dev packages nV asked for and sudo the .run file. I let it update the xorg.conf. And reapply changes like coolbits afterwards.
It installed all stuff it needs; I also let it install the 32bit libs; just in case.
What drove me crazy wih ubuntu last time was some hiccup with Plymouth ; whatever I tried it made my box unresponsive.

To be fair: the approach described above works well for fresh installed OS; with my folding box I'm not sentimental: if it wants a refresh it gets one.

This way I got 343.22 installed and folding; meanwhile I moved the 970 and I've 780 together to maximize the PPD/watt on my 24/7 system.

With 14.04 I also got CUDA 6.5 for maxwell installed with same driver. 343.22. CUDA ocore v20 was running ok for some frames. On CentOS 7 not yet tried as no official CUDA package is around.

Update from my current CentOS 7: additional blacklist via file (copy&paste from the file the NV installer creates)

Code: Select all

[cl@Linuxpowered modprobe.d]$ pwd
/etc/modprobe.d
[cl@Linuxpowered modprobe.d]$ more blacklist.conf 
# generated by nvidia-installer
blacklist nouveau
options nouveau modeset=0

and the default setting for grub

Code: Select all

[cl@Linuxpowered default]$ pwd
/etc/default
[cl@Linuxpowered default]$ more grub 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto  vconsole.font=latarcyrheb-sun16 rhgb rdblacklist=nouveau "
GRUB_DISABLE_RECOVERY="true"

[billford]

As Jesse mentioned earlier you can avoid a bunch of instant failures by first testing for opencl. Download ocore_601_OpenCL_v20 from http://stanford.edu/~yutongz/ocores/ and run:

Code: Select all

chmod +x ocore_601_OpenCL_v20
./ocore_601_OpenCL_v20 --devices

Sorry if this is a noob question, but can that be run in a normal Terminal window or does it have to be from a command console?

(I'm a Linux tyro and very cautious at a command prompt of any sort!)

BTW, many thanks for the details of getting to a root prompt from the grub menu, ctrl-alt-f1 stops working for me after I've installed an NVidia driver

[ChristianVirtual]

Terminal window is perfectly fine for oCore. Did that all the time for CUDA and OpenCL variant

[billford]

Thanks Christian.

[bollix47]

Ok, so bollix47 and ChristianVirtual, what exactly did you do to get the .run installed properly and fully functional?

I just used the steps from my post on page 1 of this thread:

• Install the prerequisites
  Follow the steps starting with 2a

I'll separate the method out of that post later to try and make it a bit clearer (I'm expecting delivery of another Maxwell in the next week or two and will use that opportunity to test the method before posting it).
I did not have to blacklist anything. The source link also shows a step where they install nvidia-331-updates-dev but I did not perform that step and I've seen no ill effects.

I have had times in the past where previous failed attempts have resulted in a system that simply won't work with this or any other method and have resulted in re-installing the o/s but if the previous attempts didn't involve too much fiddling with various o/s settings etc. it should work. Don't forget to purge xorg-edgers ppa prior to attempting this method:

*only if you installed the xorg-edgers ppa:

Code: Select all

sudo apt-get install ppa-purge
sudo ppa-purge xorg-edgers

Doing so should return things to their previous defaults. Don't panic if X is unusable afterwards since the first step of installing the drivers is to get out of X ... just use the advanced grub menu routine.

[Jesse_V]

Really good advice guys! To anyone reading this, now or in the far future, I still recommend installing drivers with the Driver tool or though a PPA like xorg-edgers. This will save much headaches and a bit of your hair. However, since xorg-edgers derped and didn't include OpenCL somehow, installing via the Nvidia .run is necessary, and that's where the frustration begins. That being said, follow the steps below and you should be rewarded with a working OpenCL and Maxwell-supporting system!

I compiled the guides together and did the following. Not that this does not required blacklisting or unreliable tricky Linux hacks, it should be straightforward (well, at least for a manual installation of a Linux driver)

1. Installed Mint, updated everything with "sudo apt-get update" and "sudo apt-get dist-upgrade", restarted. Note that open-source drivers are in use here.
2. Used Firefox to fetch the latest driver. Downloaded it, then copied it into /root.
3. Restarted. Chose Recovery Mode in GRUB menu, then chose "update grub" to mount the filesystem as read/write.
4. Chose the root shell option from the recovery mode dialog. Provide the root password.
5. "export IGNORE_CC_MISMATCH=1"
6. "./NVIDIA-" Tab completed to get the full name.
7. Installed everything it needed. Step 5 is necessary to avoid a dkms error.
8. Let it create an X config file, as non existed previously.
9. "sudo reboot"
10. Start in regular mode, X will likely crash. Don't worry about this. You can look at the output you'll likely see a "No screens found" error. There's no need to look at the detailed output. Mint should drop you into the command-line, simply log in.
11. "sudo -s". Gains root.
12. "cd /etc/X11/". Navigates to X11's configuration directory.
13. "mkdir old_X11". Prepare backup folder.
14. "cp xorg.conf old_X11/". Backs up existing X11 configuration.
15. "Xorg -configure". Generate a new X11 configuration in the user directory.
16. "exit". Back out of root.
17. "cd". Navigates to user's home directory.
18. "sudo mv xorg.conf.new /etc/X11/xorg.conf". Applies new X11 configuration.
19. "sudo reboot". Restarts computer to load the X11 changes.

If you get an X11 crash at this point, fear not. Either login to the command-line and issue "sudo reboot" or hold down the computer's power button and then start the machine again. Choose Recovery Mode from the GRUB menu, and choose Resume Boot from the recovery menu. This should allow Cinnamon/Mint to boot normally. Open a terminal and run "sudo nvidia-settings". Adjust your screens if you like, and click the button to save to /etc/X11/xorg.conf. Then reboot and X should start properly with a normal boot.

Unfortunately, the last sentence of the previous paragraph is not true for me. If I boot normally, X crashes. If I boot into recovery, then resume normal boot, everything works. I don't get it, but Cinnamon is up and running, the Drivers tool shows a manually installed driver, nvidia-settings shows 343.22 and lists both cards, and the "--devices" flag on the ocore lists both cards! I am a happy camper!

Now all I have to do is figure out why X hates normal boot but is ok with recovery mode. I'll probably be blacklisting something or fiddling with xorg.conf, which always makes me happy. \s



Oh, I can't wait for Wayland...

[Jesse_V]

There's a bug that confused me for a bit:

The ocores list the 480 and the 970 as both having OpenCL support. However, "FAHClient --lspci" shows a list, and only the 480 has its name printed. The 970 has the ID of 0x13c2 according to https://fah-web.stanford.edu/file-relea ... c/GPUs.txt, and that is listed, but it's not named. Consequently, FAHClient won't allow me to add a second GPU slot since it only thinks the 480 is available. I guessed that it's knowledge of supported GPUs was out of date.

1. "cd /var/lib/fahclient"
2. "sudo wget https://fah-web.stanford.edu/file-relea ... c/GPUs.txt"
3. "sudo chown fahclient GPUs.txt"
4. "sudo /etc/init.d/fahclient stop". I then waited until FAHControl lost connection after all the cores died.
5. "sudo /etc/init.d/fahclient start"

I then added another GPU slot, which attached to the 970 nicely, so the above manual update fixed the issue. FAHClient is supposed to do this, but it didn't apparently.

[ChristianVirtual]

Thanks for the write-up and congrats for a working 970.

I have the same "unnamed" 970 sympton but could still add the 970 mixed with 780. Without touching GPUs.txt.
But I had to adjust the index for each card as adding the slot didn't figured out the right assignment.

viewtopic.php?nomobile=1&f=96&t=26890&p=270819#p270819

[Jesse_V]

I have the same "unnamed" 970 sympton but could still add the 970 mixed with 780. Without touching GPUs.txt.
But I had to adjust the index for each card as adding the slot didn't figured out the right assignment.

viewtopic.php?nomobile=1&f=96&t=26890&p=270819#p270819

I have the same problem. I'll finish these WUs and then fiddle with removing/adding the GPU slots, or changing indexes if I have to. The WUs run fine, but FAHControl shows the 480 with 121k PPD and the 970 with 28k PPD, so it's just a bit confused. Both are running units from project 9201.

The 970 is about 4.5 times faster than the 480!

[EXT64]

hmm, 121k seems really low for that 970. Has it stabilized at that? Does the TPF seem to match the predicted PPD?

[Jesse_V]

hmm, 121k seems really low for that 970. Has it stabilized at that? Does the TPF seem to match the predicted PPD?

Nope, I guess I was seeing early reports. It's now stabilizing at 265k PPD.

[EXT64]

Ah, good. That sounds more like it!

[Jesse_V]

Ah, good. That sounds more like it!

This is awesome: http://kakaostats.com/pop_up_chart.php? ... art=ddaily