Linux install of CUDA toolkit for GT 430 card, maybe…

[xilman]

Originally Posted by ewmayer

Yes, one must vagilently guard against such embarrassing faux pas at all times.

I've been unreliably informed that Ernst hasn't been feeling himself recently.

Just as well, really. Disgusting habit IMAO.

[kladner]

Originally Posted by xilman

Oh weel. Spieling mistakes appen.

I strongly assumed that a typo was in play. However, the word play took precedence.

[ewmayer]

Originally Posted by kladner

I strongly assumed that a typo was in play. However, the word play took precedence.

As ever when hanging out with a bunch of cunning linguists.

[Batalov]

And master debaters...

[Mark Rose]

Originally Posted by ewmayer

Is that for the CUDA toolkit or mfaktc? If for CUDA, will that work across my hardcoded LAN setup? [My Haswell only talks to my macbook - no wireless, as I said this is a barebones system].

You'll actually need it in either case. I'm sure Mac OS X can do something with acting as a router. A proxy won't be enough because you still need to do things like resolve DNS.

[Ken_g6]

Originally Posted by Mark Rose

A proxy won't be enough because you still need to do things like resolve DNS.

Why? If everything's sent over HTTP, won't an HTTP proxy cause DNS resolving to happen on the proxy server?

[Mark Rose]

Originally Posted by Ken_g6

Why? If everything's sent over HTTP, won't an HTTP proxy cause DNS resolving to happen on the proxy server?

Depends on the type of proxy server. With an HTTP proxy server, you're correct. With a SOCKS proxy server, it depends.

[ewmayer]

Originally Posted by Mark Rose

You'll actually need it in either case. I'm sure Mac OS X can do something with acting as a router. A proxy won't be enough because you still need to do things like resolve DNS.

I am currently attempting to use the OS X network sharing facility (along with reconfiguring the Haswell system network config from static IP to DHCP) to allow the macbook (which uses WiFi to connect to my flatmate's router) to act as an internet portal for the Haswell. If I can get that working it seems the best option. First the internet, only then will I switch focus to the CUDA tools install/setup. But now, it's dinner time. More tomorrow.

[ewmayer]

OK, here the latest: I replaced the previous static-ip/netmask/gateway/broadcast entries for 'eth0' in my Debian system's /etc/network/interfaces file with

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

followed by '/etc/init.d/networking restart', which gave a bunch of expected-looking network-restart info messages, and as expected resulted in my being frozen out of the terminal I was using to ssh-to-haswell from my macbook.

Next dug out the flat-panel monitor and keyboard I had last used when setting up the then-new Haswell system, am logged in now via that, at the same time have LAN cable plugged into the macbook, which has WiFi (and the sharing-enabled setup to the LAN) enabled.

And ... looks good! 'ping www.google.com' shows 0% packet loss.

Next up ... CUDA toolkit (and any associated sw dependencies) install - may do some reading of nVidia 'how to' docs first, over the long July 4th weekend.

[Mark Rose]

Originally Posted by ewmayer

And ... looks good! 'ping www.google.com' shows 0% packet loss.

Excellent!

Next up ... CUDA toolkit (and any associated sw dependencies) install - may do some reading of nVidia 'how to' docs first, over the long July 4th weekend.

The only part you really need to pay attention to is blacklisting the nouveau and nv kernel modules, if the installer doesn't do that for you automatically. They'll prevent the nvidia module from loading. Otherwise it should basically work out of the box.

I may also suggest looking into dkms which will automatically rebuild the nvidia modules when you install a new kernel.

[ewmayer]

OK, with a BIOS tweak to force use of the onboard video on the mobo now holding the 430, the system recognizes the device, and the real fun (Mike's rough characterization of his past experiences with the CUDA tools install) can begin.

Since this is an older card, we agreed that the 5.5 version of the tools made sense - I grabbed the .run file for that here, specifically this file, which is shared across all Linux distros.

Here is what happened when I executed the .run file as root last night:

root@derek:/home/ewmayer# ./cuda_5.5.22_linux_64.run -extract=/root/
Logging to /tmp/cuda_install_6441.log
Extracting individual Driver, Toolkit and Samples installers to /root ...

That finished 5-10 seconds later - suspiciously fast, given the 810 MB size of the .run file. The tmp-logfile contains the last "Extracting" line verbatim, nothing else.

According to the post-install notes in the nVidia "getting started" PDF, there should now be an nvidia subdir in /dev, but I don't see that, nor anything that remotely looks cuda-related. Here is what ends up in /root afterward (leftmost file is older):

70-persistent-net.rules cuda-linux64-rel-5.5.22-16488124.run cuda-samples-linux-5.5.22-16488124.run NVIDIA-Linux-x86_64-319.37.run


Mike adds:

one way you will know that the install is working is there will be a
disclaimer you have to accept

if you didn't see that and accept it then something is wrong

at some point it will ask you what driver to use (the one in the
runfile is offered)

i think you want that driver

not sure what is going on

Any clues/diagnostics-to-try from our local experts welcomed.