Building NVIDIA_kernel for RedHat 8.0

When I first upgraded to RedHat 8.0, I went to the NVIDIA driver page to look for the latest drivers and since there was no RedHat 8.0 version, I downloaded the NVIDIA_kernel-1.0-3123.src.rpm. Like any other SRPM, I ran

rpmbuild --rebuild NVIDIA_kernel-1.0-3123.src.rpm

to generate the binary RPM. Then I ran

rpm -i NVIDIA_kernel-1.0-3123.i386.rpm

to install it.

You may have noticed the use of rpmbuild. RedHat made a change in 8.0 that moved all of the build functionality out of rpm, so rpmbuild is now the program to use for this.

I made the usual changes to the XF86Config file, which by the way is now /etc/X11/XF86Config instead of /etc/X11/XF86Config-4. I'm not going to go into the changes because the configuration in this file should be identical to the one under RedHat 7.3, 7.2, etc.

When I ran X, the screen went black (like it usually does) but then the monitor gave the 'No Signal' message. Before I knew it I was looking at the BIOS POST screen. I did this several times and got the same effect.

After several days of fighting with this and digging in the NVIDIA_kernel Makefile and spec file I found an answer.

The real problem was that the source files in NVIDIA_kernel include kernel headers that ultimately include linux/autoconf.h. This is not a bug on NVIDIA's part, just something that I did not find obvious. The NVIDIA_kernel headers have #ifdef's in them that conditionally include other kernel headers based on the #define's in linux/autoconf.h. The problem is that by default, linux/autoconf.h does not accurately reflect the configuration of the current kernel. linux/autoconf.h is generated in the [old|menu|x]config target of the kernel makefile.

The solution to this problem is to configure the kernel in /usr/src/linux-2.4.18-14. The way this is done depends on the kernel you are running, but this should give the general idea. I was running the athlon-smp kernel.

cd /usr/src/linux-2.4.18-14
cp configs/kernel-2.4.18-athlon-smp.config .config
make oldconfig
make dep

This will update linux/autoconf.h and set up some symbolic links to the arch directory so that NVIDIA_kernel includes the right headers and has its macros set properly (SMP configs change spinlock macros I believe).

I was then able to rebuild the NVIDIA_kernel SRPM again, but when I tried to install it, I got an error that the module did not match the current kernel version. I managed to track down how the NVdriver module picked up a kernel version and it came from linux/version.h. This header is generated by the kernel makefile in the 'dep' target.

The kernel makefile supplied by RedHat has a variable in it called EXTRAVERSION which was set to -14custom. Obviously -14custom did not match -14smp. I just had to change this variable to -14smp, reconfigure the kernel again, and rebuild NVdriver and I finally had a working NVIDIA_kernel.

I would recommend rebuilding NVIDIA_GLX from the SRPM as well since the gcc version changed so radically. I had no problems with this part so I won't cover it here.

To summarize, the way to build the NVIDIA_kernel SRPM for Redhat 8.0 involves the following steps. Again this assumes you are using the athlon-smp configuration.

kernel configuration
--------------------
cd /usr/src/linux-2.4.18-14
make mrproper
cp configs/kernel-2.4.18-athlon-smp.config .config
<in Makefile, change the line EXTRAVERSION=-14custom to EXTRAVERSION=-14smp>
make oldconfig
make dep

SRPM build
-----------
rpmbuild --rebuild NVIDIA_kernel-1.0-3123.src.rpm
rpm -i NVIDIA_kernel-1.0-3123.src.rpm


It may be that the problems I had are peculiar to the SMP kernel configuration and that most folks using a UP kernel can sail through this without the kernel config. It seems that the kernel EXTRAVERSION string '-14custom' shouldn't work for anyone though.

This stuff seems obvious to me in hindsight, but I hope this information helps someone avoid the headache I went through figuring it out. Hopefully NVIDIA will build some binary RPMS for RedHat 8.0 soon so most people can avoid this.

-Jeff

Here is some system configuration information in case anyone is interested.

The system is a dual AthlonMP 2000+ on an ASUS A7M with the AMD 760MPX chipset.
The video board is a Gainward GeForce4 Ti 4600.

uname -srvmp
Linux 2.4.18-14smp #1 SMP Wed Sep 4 11:55:37 EDT 2002 i686 athlon

lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 04)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 04)
00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 03)
00:09.0 Ethernet controller: Intel Corp. 82543GC Gigabit Ethernet Controller (rev 02)
00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 04)
01:05.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti4600] (rev a3)
02:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
02:05.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07)
02:06.0 USB Controller: NEC Corporation USB (rev 41)
02:06.1 USB Controller: NEC Corporation USB (rev 41)
02:06.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
02:08.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c)

[bwkaz]

I'm glad you got it working finally. But I just have to say (I know, I know, I shouldn't, but I'm going to anyway ) that if you don't rely on RedHat's kernel's (or, for that matter, any nonstandard, patched, binary, not-from-www.kernel.org ones), you won't have a lot of these problems. The first thing I generally do whenever I install a binary distro (which is less and less now, but that's not the point) is build whatever the most recent standard kernel off www.kernel.org is. Boot into it, and a lot of the problems that you're describing seem to go away.

Maybe not acceptable for everyone (esp. if some other piece of hardware is supported by whatever RH's latest kernel is and not by 2.4.19), but it's worked for me since like Mandrake 7.1.

Since your kernel will have been compiled and installed, it will obviously have been configured. The configuration will also match what you're running, so that circumvents the linux/autoconf.h and linux/version.h problems. And the EXTRAVERSION problem as well, because the Makefiles off kernel.org don't have any EXTRAVERSION at all.

BTW, my guess at why the default RH kernel source has EXTRAVERSION not the same as the running kernel, is so that people that build their source right away and boot right to it don't shoot themselves in the foot by overwriting their current module setup. The modules get put into /lib/modules/<full kernel version, incl. EXTRAVERSION>/..., so if you select different options for a module (for example), you don't overwrite the RH choices.

Just something to be aware of if you do change EXTRAVERSION and then try to rebuild the kernel all the way. You shouldn't have problems if you change EXTRAVERSION and then only build up to the "dep" stage.