Need More Help From The Linux Gurus...

[Dan]

How do I set the IGNORE_CC_MISMATCH? 😱

 

[n0cmonkey]

Originally posted by: Dan
How do I set the IGNORE_CC_MISMATCH? 😱

Not sure off hand, Id look through the Makefile to see if it mentions that at all.

 

[manly]

Originally posted by: cleverhandle

It's possible cleverhandle gave you a bad path.

I have the nvidia drivers installed from the tarball on my machine, and they live in the path I specified. Perhaps Mandrake has a different path specified in /etc/modules.conf? Or somewhere else? I always thought that /lib/modules/<version>/ was the standard location, since that's what the kernel install scripts use.

Yeah that's the correct beginning of the hierarchy, but my NVdriver file is located under a slightly different path than the one you listed. That's the only point I was trying to make, not that you were incorrect. That's why I suggested a different ls command to try out.

Speaking of GCC3 are you guys sure that Mandrake 9.0 (and Red Hat Linux 8.0, SuSE Linux 8.1) actually use GCC 3.2 to compile the kernel?

No, I'm not sure. But it seems unlikely that they would ship a distro with the kernel/libraries compiled under a different gcc than the default system gcc. It would be asking for all kinds of problems if someone decides to compile their own kernel or installs other modules.

Actually it's not unlikely at all. Previous Red Hat & Mandrake releases shipped GCC 2.96* as the default compiler. However, an older version was used to compile the kernel. The version was probably 2.95.3 and it was installed as kgcc. That's the compiler you'd use to compile kernel modules with. While Red Hat insisted GCC 2.96 was the best free C/C++ compiler available, it did come with its initial headaches. SuSE adopted a more conservative approach and stuck with 2.95.3 as the only compiler throughout (until 8.1 is released).

Since the kernel would have to be cleaned up before it would reliably be compiled with GCC3, I presume they are still doing a similar thing in the latest release.

To compile kernel modules, you basically need the build routine to use kgcc.

* The initial flap was because Red Hat took a beta GCC, forked it, and called it 2.96. Although GCC never officially released any compiler as 2.96, the cat was already out of the bag. Red Hat did this because they wanted to ship a more modern C++ compiler than 2.95.3 (and at the time, GCC3 was nowhere near ready).

 

[cleverhandle]

Originally posted by: Dan
How do I set the IGNORE_CC_MISMATCH? 😱

Usually, this sort of thing is done by

export IGNORE_CC_MISMATCH=1

I think it just needs to have any value, but 1 is the way I've seen it.

 

[cleverhandle]

Yeah that's the correct beginning of the hierarchy, but my NVdriver file is located under a slightly different path than the one you listed. That's the only point I was trying to make, not that you were incorrect. That's why I suggested a different ls command to try out.

Yeah, sorry if I sounded nasty - just meant to say that, since he was installing from the tarball, that's where the module should have ended up. It may be that it needs to be moved for Mandrake to find it, but if it was installed at all, that's where it should be. Unless there's some "behind-the-scenes" way for the install scripts to find the module directory, which is entirely possible.

Actually it's not unlikely at all. Previous Red Hat & Mandrake releases shipped GCC 2.96* as the default compiler. However, an older version was used to compile the kernel. The version was probably 2.95.3 and it was installed as kgcc. That's the compiler you'd use to compile kernel modules with. While Red Hat insisted GCC 2.96 was the best free C/C++ compiler available, it did come with its initial headaches. SuSE adopted a more conservative approach and stuck with 2.95.3 as the only compiler throughout (until 8.1 is released).

You're correct, of course. I guess I was hoping that distros would never repeat that fiasco, and leave multiple compiler issues for the programmers who actually understand what they're doing. But it seems that it's still more important to shout impressive version numbers on the box despite the complications that may arise from it.

 

[Dan]

Once I'm in the NVIDIA-kernel directory (from root) I type:

export IGNORE_CC_MISMATHC=1.
make install

I get a listing of things cc might stand for, followed by:

make: cc: Command not found
make: ***[nv0] Error 127

 

[cleverhandle]

cc is usually a link to the default system C compiler - it looks like Mandrake doesn't include that link, so make it with:

cd /usr/bin
ln -s gcc cc

I'm assuming that /usr/bin/gcc is present in some way, though maybe it, too, is a link to something else. You might want to make sure that gcc is there first by doing

ls /usr/bin/gcc

which should confirm that gcc is present.

 

[Dan]

At [root@localhost root]# I type:

ls /usr/bin/gcc

and I get:

"no such directory or file found."

You know, I like to think that (when it comes to PC's) I'm smarter than the average bear. Unfortunately, this whole exercise certainly isn't reinforcing that notion.

 

[cleverhandle]

You know, I like to think that (when it comes to PC's) I'm smarter than the average bear. Unfortunately, this whole exercise certainly isn't reinforcing that notion.

Why? You're trying to solve a problem in an unfamiliar environment, and dealing with some technical difficulties that are not really documented anywhere. This kind of problem is not supposed to be easy. Hopefully, you're learning a bit about modules, symbolic linking, and compilers while you're at it. That's a Good Thing.

We want to figure out what gcc we want to link to, and where it is. So try this (as root):

updatedb (this updates the system database that keeps track of where your files - it may take some time)
locate gcc

This will return a list of every file with gcc in it's name - probably very many of them. Since we're only interested in the executables, let's limit it to files found in a /bin/ directory using grep:

locate gcc | grep bin

That should output considerably fewer files. Write them down and list them here for us.

 

[manly]

I haven't compiled the Nvidia modules from scratch but I would try:

• Editing the Makefile to set which compiler to use if it's relatively simple
• Setting the environment variable CC=kgcc

 

[Dan]

I'm still not there yet but I am making progess. 😉

For the first time I'm able to get to the KDE desktop in Mandrake 9.0, using Nvidia's drivers. (I downloaded and untarred NVIDIA_kernel-1.0-3123.tar.gz and NVIDIA_GLX-1.0-3123.tar.gz.)

My hang-up now is that I can't change the resolution or color depth. (I'm still at 640x400x8-bit.)

When I go into the graphics configurator I can see that the video card is identified as GeForce (fbdev), using the aforementioned resolution on an unidentified monitor. I select "GeForce 4 - Generic" as the card, choose XFree 4.2.1 as the server I want, change the resolution to 1024x768x24-bit and try to test the settings.

The message I get back:

failed to load module "bitmap" (0)
module does not exist
failed to load module "pcidata" (0)
module does not exist

For what it's worth, somewhere else I saw these settingsL

XFree86 Server: SVGA
XFree86 driver: nv

 

[cleverhandle]

From what those messages say, you're not using Nvidia's driver ("nvidia"), instead you're using the XFree86 NVidia driver ("nv") which doesn't officially support GF4's. I don't think it's possible to run the desktop at a reasonable setting using those drivers.

 

[Dan]

Damn! So, I'm not as close as I thought. What do I need to edit now?

 

[cleverhandle]

Well, did the nvidia tarballs compile cleanly? If so, follow their README to choose the "nv" driver and change the modules loaded.

 

[Dan]

I thought they (tarballs) compiled cleanly but perhaps not. What am I supposed to do to ensure that thay compile cleanly? I have both tar.gz files in root/tmp. I use the commands:

tar /zvxf NVIDIA_kernel-1.0-3123.tar.gz and
tar /zvxf NVIDIA_GLX-1.0-3123.tar.gz

after that I use:

cd NVIDIA_kernel-1.0-3123
make install

cd NVIDIA_GLX-1.0-3123
make install

Then I edit the XF86Config-4 file and /etc/modules.conf file.

 

[cleverhandle]

I was referring to the error messages from before - did the tarball compile without errors or other complaints? (The kernel module warns that it's not GPL code, but other than that...) Can you do a "modprobe NVdriver" to successfully load the nvidia driver?

 

[Dan]

No success with modprobe NVdriver. In fact, in all my attempts to get this right, I've never been able to do a modprobe that finds NVdriver.

 

[cleverhandle]

You said that the tarballs compiled without errors (no complaints about gcc version, etc.), so the module should be around somewhere - do an

updatedb
locate NVdriver

Where does it say the module is at?

 

[Dan]

locate NVdriver (after updatedb) doesn't find anything. I guess that confirms your suspician that the tarballs (NVIDIA_kernel) didn't compile cleanly.

I thought they (tarballs) compiled cleanly but perhaps not. What am I supposed to do to ensure that thay compile cleanly?

 

[manly]

Originally posted by: Dan
locate NVdriver (after updatedb) doesn't find anything. I guess that confirms your suspician that the tarballs (NVIDIA_kernel) didn't compile cleanly.

I thought they (tarballs) compiled cleanly but perhaps not. What am I supposed to do to ensure that thay compile cleanly?

Instead of make install, run make to compile the kernel module. If it's successful, the final lines of output look like this:
ld -r -o NVdriver Module-linux Module-nvkernel
size NVdriver
text data bss dec hex filename
895776 55508 52396 1003680 f50a0 NVdriver
Please run "make install" as root.

Then you can run make install.

As for Nvidia GLX, you don't actually compile anything as it isn't open source. They ship binaries within the tarball, and you're just installing those files into your system.

Here's the command to check if NVdriver was installed into your modules directory:
find /lib/modules/`uname -r` -name NVdriver

Since you don't have /usr/bin/gcc I suspect you didn't install the development packages?

This is one of the major hassles of running a Linux desktop; the whole loadable modules system isn't easy enough to use. I'm used to it by now, but it's clearly an inflexible system for the typical home user.

Regarding the open-source nv XFree86 driver, there's nothing wrong with it except it doesn't do 3D hardware acceleration. I know you've had poor results with it, but I usually setup the nv driver first as a fallback case before switching to the nvidia closed-source driver. For 2D, both drivers run the same modes for me (resolution and color depth). If there is a 2D performance discrepancy, it's not meaningful for day-to-day work.

As an aside, if I were installing the Nvidia software on an RPM-based system, I would build from RPM instead of using the tarballs. According to the Makefile, you probably should set the environment variable CC=kgcc. It sounds like you're doing most things right, but keep banging on it until you succeed.

 

[Dan]

I've spent way too much time on this so, for now at least, I'm throwing in the towel. I really appreciate the time and help you guys (especially cleverhandle and manly) gave me.

I'll wait a day or two for the frenzy to die down and then I'll download a copy of RedHat 8.0. With any luck, that will do a better job of recongnizing a GeForce4.

 

[manly]

Originally posted by: Dan


In the Module section, under DBE I have the following:

Load "/usr/X11R6/lib/modules/extensions/libglx.so"

Where did this syntax come from? According to Nvidia's documentation, in the Module section, you would add:
load "glx"

Notes:

1. When I do a clean install of the OS it has to start with Mandrake 8.2. I have to choose an "unlisted" video card and use VGA16 for the server. I can then upgrade to 9.0 by choosing the option to install upgrade packages only.

2. In all my attempts at editting the XF86Config-4 file, I've never seen anything referring to Load "dri" and/or Load "GLcore." (Which is probably not a big deal. I'm just trying to be as comprehensive as possible.)

DRI refers to the open-source 3D accelerated XF86 drivers for various other chipsets. Since Nvidia hardware does not have an open-source 3D accelerated driver, you can completely ignore any documentation mentioning DRI.

I went back and read this thread a little more carefully to understand what's going on. Apparently, only the VGA16 server is installed. Like I suggested previously, you really should first setup the open-source nv driver (aka XF86 server) as a baseline. Then switching to the nvidia driver is as easy as changing two lines in the XF86Config file.

I can send you (what should be) a functional XF86Config file but you might have to tweak the monitor settings a bit as I have a relatively high-end monitor. Just to be clear, the nv driver ships w/ XF86 so it's an excellent baseline & fallback case.

Also, it's rather unclear why you have to first install Mandrake 8.2, but in and of itself, that isn't a problem (it might be masking some other issue though).

I'm having my own problems with Nvidia's drivers this morning. Unsuccessfully upgraded from the 2960 to the newest 3213 drivers ("if it ain't broke..."). Tried to downgrade to the 2960 drivers by RPM, and got the same runtime error. I remember I spent a lot of time fussing with Nvidia's drivers last time (in June) but that was for a slightly different reason (mixing & matching different kernels). Can't remember what workarounds I may have employed, but I'll probably try compiling the kernel drivers to see if it makes any difference.

In the meantime, I switched back to the nv driver as a temporary workaround. FWIW in my experience, SuSE's custom-developed SaX graphics configurator is better than whatever the other vendors are using.

 

[Dan]

I'm up and running with RedHat 8.0. The installation could not have been any easier or smoother.

It definitely has a different "feel" after Mandrake. I'm sure that's in part due to the fact that I'm using the GNOME desktop instead of KDE. My initial impressions are very favorable. (After all, it works.)

Thanks again everyone, for the help trying to get Mandrake to recognize my video card. It was a valuable exercise for me and I learned a lot. For obvious reasons, I'll be sticking with RedHat. In fact, I plan to pick up a book or two this weekend and get up to speed as quickly as possible.