HOWTO: CUDA 2.0 Beta on 64-bit Ubuntu Hardy (8.04) It works!

Well, after feeling the pain for a few days I have Cuda 2.0 Beta up and running on:

  • Dell Latitude D630 (laptop)
  • Quadro NVS135m with 256 megs of ram
  • Ubuntu Hardy (8.04) w/ latest updates
  • Kernel is 2.6.24-18-generic for x86_64

I won’t take you through the ups and downs of my trials, but I will try to mention some of the pitfalls…

== Cleanup ==
First, get rid of everything nvidia on your machine. No envyng, no nvidia related packages at all. They just mess with your setup, and in order to get Cuda2b working you need to have the latest kernel and glx drivers from Nvidia anyway. I had old drivers that kept getting loaded, so I even recommend going into your /lib/modules/… directories and getting rid of any nvidia.ko files you find in kernel/drivers/video.

== Preparations ==

Bios:
I recommend doing a BIOS upgrade before starting in with CUDA. It did change some behavior on my machine and in the forums it is discussed often, so save yourself the pain and upgrade first.

Compilers:
For Cuda1.1 you needed to use older compilers (gcc-4.1), but this is no longer the case. You should get gcc and g++ 4.2 in Hardy by default, and they will work fine.

Download:

You need 3 packages, all found here:
[url=“CUDA Toolkit 11.7 Update 1 Downloads | NVIDIA Developer”]CUDA Toolkit 11.7 Update 1 Downloads | NVIDIA Developer

  • Kernel and GLX drivers (174.55), which are listed as Redhat Enterprise, but they work fine in Ubuntu Hardy. (Many very solid developers are on Ubuntu these days so Nvidia should really get rid of this RedHat focused crap…)

  • Cuda Toolkit 2 (Also falsely listed for RedHat…)

  • CUDA SDK 2.0

Kill X and install the driver from the terminal.

sudo /etc/init.d/gdm stop
sudo sh NVIDIA-Linux-x86_64-174.55-pkg2.run

You will want to compile a kernel driver and probably just let it configure your xorg.conf. These days they auto-configure most everything anyway. If you are 64-bit you probably want to install the 32-bit compat libraries also. I did, and stuff works.

Alright, startx or reboot and login. (Reboot is safest in case you had leftover modules already loaded. Otherwise you can modprobe -r nvidia too)

Now you can install the toolkit and then the sdk. (I did it in a directory in my home directory because I don’t like polluting the system.)

Read the release notes. Seriously, all of them. I missed the fact that I needed the latest driver and it caused me about a weekend of banging my head on the wall. Read the notes, follow the directions.

Setup your PATH and LD_LIBRARY_PATH to point into your toolkit’s bin and lib directories. Go into the sdk directory and run:

make -k

That -k will tell it to keep going after errors. This is beta software, so it might not all build yet.

Anyway, it works. I can run fluids, particles, nbody, the works. Almost all of the demos that compute values pass their tests, although a few do still fail. I don´t remember which. Good luck everyone, and happy hacking!

Hi, I also got CUDA beta 2.0 running – under Debian – except for the kernel driver. 174.55 fails to compile for a linux kernel version 2.6.25.x, see also this topic http://forums.nvidia.com/index.php?showtopic=65356 . Hope this gets fixed in the latest driver soon (it is fixed for the version 173.14, though External Media )

@rosejn,
The CUDA packages that you’ve referenced are the 2.0-beta packages, which were only extensively tested against RHEL4 and RHEL5, which is why only those packages were listed. The 2.0-final release will include support for Ubuntu-7.04 and Ubuntu-7.10. This has been discussed elsewhere on this forum already.

@mmetz_nv,
The CUDA_2.0-final driver will work with a 2.6.25.x kernel.

Excellent post, rosejn. Thanks for the collected info.

[quote name=‘netllama’ date=‘Jun 9 2008, 04:23 PM’]

@rosejn,

The CUDA packages that you’ve referenced are the 2.0-beta packages, which were only extensively tested against RHEL4 and RHEL5, which is why only those packages were listed. The 2.0-final release will include support for Ubuntu-7.04 and Ubuntu-7.10. This has been discussed elsewhere on this forum already.

Thanks for responding netlama. My guess is that you could save yourselves from having to discuss this on the forum if you just changed the download page. The packages can be listed as linux packages without mentioning Redhat, and you can put a note above the linux section that specifies the systems that have been tested as well as the systems that are reported to work. You can consider this your first report. If someone makes a little form that lets you click on the demos that passed tests I’d click too. I’m not anti-RH, but this is just frustrating for those of us trying to jump into CUDA. If it’s setup right, like maybe just a wiki, the community will probably do some of this work for you guys.

One thing that I should clarify is that the CUDA toolkit packages are self-hosted (built) on the OS in which they’re listed under. We do this for a number of reasons, the least of which is to ensure that they are fully compatible with the host. Thus, the RHEL4 package is built & tested exclusively on RHEL4, and the RHEL5 toolkit package is built & tested exclusively on RHEL5 (all from the same source).

OK, so I got through these instructions (on the second try) but I am still running in to a problem. Whenever I try to make the SDK, I get this error:

make[1]: Entering directory `/home/rhewett2/software/cuda_sdk/common'

src/cutil.cpp:46:27: error: builtin_types.h: No such file or directory

make[1]: *** [obj/release/cutil.cpp_o] Error 1

make[1]: Leaving directory `/home/rhewett2/software/cuda_sdk/common'

make: *** [lib/libcutil.so] Error 2

I’ve made sure the Toolkit is installed, and the INCLUDES variable in common.mk points to `/home/rhewett2/software/cuda/include’, where the “missing” file lives.

Any hints/ideas/kicks in the right direction?

Cheers,

Russ

edit: I tried specifying the include directory to make, which got me through this particular error. something still seems broken though, because I shouldn’t have to do that, especially when common.mk has the correct path

edit2: turns out common.mk wouldn’t work with the path ~/, i had to change it to /home/rhewett2/

I got that one at one point. I think it means you don’t have the toolkit and path information setup correctly. If I remember right, that builtin_types.h is a header in the toolkit…

-Jeff