Royal mess-up - Nvidia drivers.

English Hardware
#1

I recently decided to give GPU2 and CUDA folding@home a go on my OpenSuSE 11.1 machine.
However, something went horribly wrong.
Turns out I had nvidia driver RPMs installed (I thought I did not) and as such, using the CLI nvidia installer caused some problems. I think I’ve sorted out most of the mess and conflicting files.
The nvidia drivers (185.18.08) are loading and working, (“driver nvidia” in xorg.conf, fan goes quiet on X startup like normal when nvidia driver in use) but 3Ddiag reports tha I’m using Mesa and FreeGlut.

3Ddiag version 0.742
Verifying 3D configuration:
Using 3dinfo

================================================================
No 3D capable graphic chipset found!

Checking GL/GLU/glut runtime configuration:
GL/GLU … done (package Mesa)
glut … done (package freeglut)

This leaves me with two problems:
a) I can’t fold- I get an exception thrown.
b) no compositing, since KDE thinks I’m using GLUT.

Ideas/thoughts?

Thanks!

#2

Interesting, I had some similar problem yesterday. The 185.18.10 driver was installed - also presented in xorg.conf, but I get no compositing effects.
What was the problem? When I opened nvidia-settings everything was fine except one thing: Under the OpenGL/GLX Information was nothing! There were some number in the Frame Buffer Configuration Table, but the text area was totally empty.
I’ve uninstalled the driver (in runlevel 3 manually) with nvidia-uninstall and installed the same driver again.
After it worked - of course the informations about OpenGL now are presented under OpenGL/GLX Information.
Hope that helps.

#3

Interesting.
I do get GLX information, but just that 3Ddiag says I’m using GLUT/Mesa.

I’ve tried various combinations of uninstalls/reinstalls to no avail…
What is the nvidia-unistall you mention? Is it a separate tool, or just the standard “sh NVIDIA-<driver version>.run --uninstall” which I’ve been using?

TIA.

#4

Check to make sure,

ls -la /usr/lib/libGL*
Point to the nvidia version and not mesa. Specifically libGL.so/.1 and core.

Also to really find out what is being used you need to grep out xorg log.
grep LoadModule /var/log/Xorg.0.log

Then from a bit of googling it seems that sometimes you can have stale files… The installer does not always find and remove them. This is probably better after a removal and before a re-install you can identify them with.
locate libnvidia-tls

#5

The nvidia-uninstall is an uninstaller script. Run with sudo. It uninstalls the nvidia driver. That’s all.

#6

I will give it a try and report back…
Hopefully its something like that, but I doubt it- I already tried a purge of the /usr/lib/libGL series of files before doing a clean install of the driver.

#7

I think I’ve found the cause.
Normally, executing an .so file results in version information being displayed.
However, running any of the associated NVIDIA GL files produces a segfault.

I have also noted that if I install the RPM packages from nvidia, then 3Ddiag DOES find the board, but still indicates I’m using MESA.

#8

On Wed, 2009-05-27 at 21:16 +0000, VintagePC wrote:
> I think I’ve found the cause.
> Normally, executing an .so file results in version information being
> displayed.

…so files normally DO NOT have an entry point defined. At least not on
Linux (from my experience). So if Nvidia’s .so files are designed to be
executable, that’s news to me… it may well be true. The only platform
where I saw this technique done was AIX, but they really didn’t
have .so’s is the same sense of the word.

> However, running any of the associated NVIDIA GL files produces a
> segfault.
>
> I have also noted that if I install the RPM packages from nvidia, then
> 3Ddiag DOES find the board, but still indicates I’m using MESA.

While it is very true that the best 3D acceleration is found using
Nvidia boards, it is equally true that they release often and often with
a TON of bugs… such is the beast when you operate as a rogue away from
the other kernel developers. Nvidia drivers are right/wrong/who knows?
Nvidia is NO different from Microsoft, well… that’s not true,
Microsoft actually has some open source stuff now… sigh. I like
Nvidia’s technology, but they’re hiding something that has to be HUGE
(in a bad way) for them to not do what AMD is trying to do.

Long term, we’ll all switch to AMD for the best quality and
performance… but it may still be a couple of years off. And that
assumes that AMD can stay alive, which doesn’t look promising from here.

Intel’s got some surprises up its sleeve for this year… they could be
the sleeper hit that puts them all to shame… we’ll see.

So… I guess, we’ll all likely move to Intel… but that’s banking on
some unreleased surprises… will know more in a year or so. Intel is
holding a LOT of “cards”, so they aren’t compelled to release to much
too soon.

Back to Nvidia drivers. I usually do try the ones that openSUSE
packages at first, but because Nvidia is notoriously buggy, sometimes
you NEED to go backward in order to get something that works right… so
I usually end up pulling drivers straight from Nvidia eventually.

#9

I have some more info… If I use nvidia RPMs, I get the following output:

DualP4-2400:/usr/share/doc/packages # 3Ddiag
3Ddiag version 0.742
Verifying 3D configuration:
Using 3dinfo

Verifying 3D configuration for 3D board “nVidia Corporation GeForce 8600 GT (10de@0402)”:

Verifying driver installation:
nvidia … done.

Tests for X.Org configuration:
Config File /etc/X11/xorg.conf … done.
Driver … done.
Extensions … done.
Options … done.

Checking GL/GLU/glut runtime configuration:
GL/GLU … done (package Mesa)
glut … done (package freeglut)
DualP4-2400:/usr/share/doc/packages # 3Ddiag --nvidia_glx
3Ddiag version 0.742
Verifying nVidia-GLX/X.Org configuration
Using 3Ddiag.nvidia_glx

================================================================
No 3D capable graphic chipset found!

Checking GL/GLU/glut runtime configuration:
GL/GLU … done (package Mesa)
glut … done (package freeglut)
DualP4-2400:/usr/share/doc/packages #

The second half of that is particularly interesting… Does it yield a clue for anyone?

#10

I’ve verified there aren’t any stale libGL and variant links anywhere, all point to the current versions provided by nvidia.

Another useful piece of info is that xdriinfo reports “libGL is too old”. I don’t know what to make of that… thoughts?

#11

Using a beta driver yeah only one NV forums and/or bug report it.

#12

I’m not using a beta driver though…
Currently its the latest from the nvidia OpenSuSE repository.

#13

Err where ftp://download.nvidia.com/opensuse/11.1/i586/
Unix Drivers Portal Page

So I can’t see it… I run a so called bleeding edge distro, and guess what they’re on the same one 180.51 no cuda
Linux Display Driver - x86
Note beta right at the top…

#14

Hmmm… yes, i’ll need to use that for CUDA.

Found part of the problem- 3Ddiag returns mesa for GL configuration any time you have mesa installed… even if the libGL file was replaced.

Seems then, that there are other issues at hand.

I’ll look in to it and report more as I find it.

#15

TBH I’m not sure what provides 3Ddiag or what it is doing.

I would of thought if glxinfo is returning the correct bits then this would be correct. OpenGL string, more so as, as far as I can see mesa is providing glxinfo.

#16

Well after actually finding out what you’re attempting I presume you read this bit…

Folding@home - FAQ-ATI2

The client runs on Windows XP and Vista for now. (Linux and OSX may be a possibility in the future.)

#17

3Ddiag is a set of shell scripts specific to openSuSE, apparently, in a separate rpm called 3ddiag.

I did see the part about Windows… but I’m running through wine and following the steps here:
Linux - GPU2 Linux

The core CUDA code is identical regardless of platform, so as long as the windows portion of the code is supported, there aren’t any problems.
(The site recommends the console client, but I’ve had no problems running the GUI client at all!)

which worked well until I found out that Xv was giving only a black screen instead of video… Hence my attempts to re-install the drivers, and the ensuing mess.

#18

So the real question is what errors are you getting (Lets ignore 3Ddiag for the moment) trying to do it?

You seem to be saying in the OP that it works but 3Ddiag is wrong.

Though this is really over complicated, you’re trying a beta driver to run a windows only app to process on your gpu(Do you really want to be the one troubleshooting this, do you have the skills?).

So you have 2 problems, but as I said earlier it is beta…
I can’t fold- I get an exception thrown
So lets presume that is related to…
no compositing, since KDE thinks I’m using GLUT.

What are you getting in xorg log? Do you have compositing else where i.e sensible fps in a game, semi sense from glxgears, direct rendering yes in glxinfo?

Confirm that compositing is working though tbh I’m only helping you troubleshoot. I have no reason or wish to use a beta graphics driver.

I still think your best place is NV and even then they’ll expect you to troubleshoot it. I would say go over there give them the nvidia diagnostic output.

#19

Yes, it turns out that the GL is working. The issue seems to be within the SuSE specific software package 3Ddiag not detecting the driver install correctly.

I think the compositing issue may be unrelated. I have a feeling it might be time for an rm ~/.kde4, since I’ve recently done an update of KDE4 in the online repo. I just tested a new user account (created just for this) and compositing does come on…

Any idea which specific kde config files I should wipe for this?

#20

I haven’t got a clue, not used kde4 since 0 full time.

I’m still waiting for a stable version around about 4.4 it might be ready. Though since finding a compromise I maybe another one that they lost.

I wouldn’t of suspected .kde but if you reckon it is, the easiest maybe to just rename it and slowly copy it back in until you get to it.