for the third time in a row now, I keep having to reinstall the CUDA driver. Otherwise, after a reboot I get:
cudaSafeCall() Runtime API error in file <cbct_init.cpp>, line 97 : no CUDA-capable device is available.
what the hell am I missing here?
I’ve installed every cuda package I can find for 2.3
Hi mfarrell,
I don’t have an answer for you, but after reading your post and rebooting my machine (on which CUDA was working) I TOO
HAVE THE SAME ISSUE, e.g. deviceQuery no longer finds a CUDA enabled device.
Reinstalling, in my case the 2.3.1 driver, fixed the problem.
I agree that a reboot should not cause such a problem.
Best, Hans
I haven’t tried 2.3.1 yet, I’m assuming it still exists. will try it next time around. looks like we’ve found a bug nonetheless.
step one: can you give me the output of “kextstat | grep CUDA” when this isn’t working?
step two: what’s the output of ls -Fal /System/Library/StartupItems/CUDA?
Hi tmurray,
After a reboot the “kextstat | grep CUDA” returns nothing. I’ve listed my output below.
CUDA WORKING:
boussinesq:release johnston$ ./deviceQuery
CUDA Device Query (Runtime API) version (CUDART static linking)
There is 1 device supporting CUDA
Device 0: “GeForce GTX 285”
CUDA Driver Version: 2.30
CUDA Runtime Version: 2.30
CUDA Capability Major revision number: 1
CUDA Capability Minor revision number: 3
Total amount of global memory: 1073414144 bytes
Number of multiprocessors: 30
Number of cores: 240
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 16384 bytes
Total number of registers available per block: 16384
Warp size: 32
Maximum number of threads per block: 512
Maximum sizes of each dimension of a block: 512 x 512 x 64
Maximum sizes of each dimension of a grid: 65535 x 65535 x 1
Maximum memory pitch: 262144 bytes
Texture alignment: 256 bytes
Clock rate: 0.80 GHz
Concurrent copy and execution: Yes
Run time limit on kernels: Yes
Integrated: No
Support host page-locked memory mapping: Yes
Compute mode: Default (multiple host threads can use this device simultaneously)
Test PASSED
Press ENTER to exit…
boussinesq:release johnston$ kextstat | grep CUDA
107 0 0x8d41d000 0x2000 0x1000 com.nvidia.CUDA (1.1.0) <5 2>
boussinesq:release johnston$
boussinesq:release johnston$ ls -Fal /System/Library/StartupItems/CUDA
total 16
drwxr-xr-x 4 root wheel 136 Aug 10 16:43 ./
drwxr-xr-x 3 root wheel 102 Sep 17 2008 …/
-rwxrwxr-x 1 root wheel 498 May 22 09:35 CUDA*
-rw-rw-r-- 1 root wheel 438 May 22 09:35 StartupParameters.plist
AFTER REBOOT; CUDA NOT WORKING:
boussinesq:release johnston$ ./deviceQuery
CUDA Device Query (Runtime API) version (CUDART static linking)
There is no device supporting CUDA.
Device 0: “Device Emulation (CPU)”
CUDA Driver Version: 2.30
CUDA Runtime Version: 2.30
CUDA Capability Major revision number: 9999
CUDA Capability Minor revision number: 9999
Total amount of global memory: 4294967295 bytes
Number of multiprocessors: 16
Number of cores: 128
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 16384 bytes
Total number of registers available per block: 8192
Warp size: 1
Maximum number of threads per block: 512
Maximum sizes of each dimension of a block: 512 x 512 x 64
Maximum sizes of each dimension of a grid: 65535 x 65535 x 1
Maximum memory pitch: 262144 bytes
Texture alignment: 256 bytes
Clock rate: 1.35 GHz
Concurrent copy and execution: No
Run time limit on kernels: No
Integrated: Yes
Support host page-locked memory mapping: Yes
Compute mode: Default (multiple host threads can use this device simultaneously)
Test PASSED
Press ENTER to exit…
boussinesq:release johnston$
boussinesq:release johnston$ kextstat | grep CUDA
boussinesq:release johnston$
boussinesq:release johnston$ ls -Fal /System/Library/StartupItems/CUDA
total 16
drwxr-xr-x 4 root wheel 136 Aug 10 16:43 ./
drwxr-xr-x 3 root wheel 102 Sep 17 2008 …/
-rwxrwxr-x 1 root wheel 498 May 22 09:35 CUDA*
-rw-rw-r-- 1 root wheel 438 May 22 09:35 StartupParameters.plist
step three: does /usr/local/cuda/lib/libcuda.dylib exist in both cases?
step four: does /System/Library/Extensions/CUDA.kext exist in both cases?
Hi tmurray,
Until I’m back in the office when I reinstall the 2.3.1 driver I can only report on the issue when CUDA is
not working after a reboot:
boussinesq:~ johnston$ ls /usr/local/cuda/lib/libcuda.dylib
/usr/local/cuda/lib/libcuda.dylib
boussinesq:~ johnston$ ls /System/Library/Extensions/CUDA.kext
Contents
boussinesq:~ johnston$ ls /System/Library/Extensions/CUDA.kext/Contents/
Info.plist MacOS Resources
boussinesq:~ johnston$ ls /System/Library/Extensions/CUDA.kext/Contents/*
/System/Library/Extensions/CUDA.kext/Contents/Info.plist
/System/Library/Extensions/CUDA.kext/Contents/MacOS:
CUDA
/System/Library/Extensions/CUDA.kext/Contents/Resources:
English.lproj
Hope this helps …
so obvious problem: the kext doesn’t get loaded. thanks, that gives us something to track down…
any terminal commands to load it manually? so I don’t need to run the whole graphical installer
sudo kextload /System/Library/Extensions/CUDA.kext
This worked for me … I will mention that on trying to reinstall the 2.3.1 driver I got the grey screen "you need to restart your
computer" … not good … hope it does not happen again …
Seems to do the job thanks.
However I’ve experienced some problems with OS X locking-up. The only way to resolve this is to hard-reboot.
I’ve seen that on 2.2 - I haven’t used 2.3 enough yet to tell if it does the same thing. In my case it would happen sometimes when I tried to launch a buggy kernel (sometimes I would get “unspecified failure to launch” and sometimes OS X would lock up). Once the bug was fixed, I saw no more lock-ups.
Is there a way to have the .kext loaded at boot (login) time? To have this command used in the start of a session? Without the need to type the root password…
Aha! There’s a CUDA directory in /System/Library/StartupItems with a CUDA script in it that would appear to do just that. But I checked my system.log and found an error message complaining that the CUDA script had failed a security check because it had group write enabled. Either this is a new check with Mac OS X 10.5.8, or the permissions are different in CUDA 2.3. (Unfortunately, I did both the Mac OS and CUDA upgrades at almost the same time, so I can’t tell easily.)
But I removed the group write permission on both the CUDA script and the plist file in the same directory, and now when I reboot, the CUDA driver is loaded! SUCCESS!
Thanks for prompting me to do a little extra work on this and saving me the manual loads.
(I knew I could force a load by fiddling with the startup scripts myself, but I didn’t really want to take a chance on messing up the boot process - removing a write permission that was probably wrong to begin with is an acceptably safe alternative.)
I am also running CUDA 2.3 and OS X 10.5.8 and can confirm that it no longer fails to load at startup after changing group permissions to read only for both files. I updated to 10.5.8 AFTER having this problem so I’m pretty sure the problem is with the new version of CUDA. Thanks for finding this Don.
Solved here too!
Just turned the group permissions from both files in /System/Library/StartupItems/CUDA to “Read Only” and magically kext is initialized at startup.
:D
I’ll try this as well. Commandline fix for those who want it, paste into terminal
sudo chmod g-w /System/Library/StartupItems/CUDA/*
I’ve the same problem. Don’t forget to fix the CUDA folder too.
So we need to execute both commandlines.
sudo chmod g-w /System/Library/StartupItems/CUDA/*
sudo chmod g-w /System/Library/StartupItems/CUDA/