core 2 test 2 nvidia

[Gary]

Hello all, I sure hope someone can help me here. I just installed Fedora core 2 test 2 on my AMD 2400 machine, with a GeForceFX card. After overcoming the initial problem of have to boot from the test 1 cd, the install went fine and I have applied all available updates. The problem is after installing the Nvidia driver, updating etc/X11/XF86Config, and removing rhg from GRUB (I read where that might help) the screen freezes (black) where the first Nvidia splash screen should be. I was able to use the Nvidia driver with test 1 without a problem. Has anyone else had this problem, and discovered a fix? Thanks in advance for any advice. - Gary

[LordMorgul]

If you are using a test kernel newer than (I think) 2.6.4-1.25x then there will be a default kernel config option selected that breaks compatibility with the driver. This option is:
CONFIG_4KSTACKS

The current kernel config should be present in /boot so you can grep it to look for that kernel option. Your only choice at present to run the nvidia driver is to rebuild the kernel-source with that option disabled.

(the make rpm target of the kernel-source makefile is your best bet, after copying the correct config and editing)

CONFIG_4KSTACKS=y
should become
# CONFIG_4KSTACKS is not set

[Gary]

Thanks for your reply, I'll give it a try. Do you happen to know if this will be changed in the final release of Fedora core 2? Thanks again. - Gary

[LordMorgul]

I believe both the kernel maintainers stated (in IRC) that this will be used: Dave Jones would be the authoritative source if you want to ask on mailing list.

This is a patch applied during kernel RPM build, so it is not part of the kernel.org release yet -- it may be part of Andrew Morton's patchset (-mm) tho I haven't checked yet.

[Dragoran]

what does this patch?

[LordMorgul]

The 4K stack patch changes the physical size of the stack frame created by the kernel when it needs to do so. These are created very often, so reducing the size offers increased performance.. but is really targetted at systems that need to scale well (the docs mention thread creation performance). The average user probably will never know it was used or not... at least right now, future apps may be able to take advantage of the improvement for workstations.

Andrew Morton's patchset (-mm) is available from kernel.org and is the testbed of highly experimental ideas in the kernel.

[Gary]

After updating to the latest kernel, and reading a few other threads on this subject, I've discovered CONFIG_4KSTACKS has been removed from the latest kernels. Thinking this may have solved the Nvidia driver issue I once again installed the 5336 Nvidia driver and edited /etc/X11/XF86Config. After reboot though, the changes revert back. Am I doing something wrong or is this a bug? For now I'm happy enough with the video (I'm averaging 1080 at 5 secs), I'm just plain curious as to what's going on. I have SUSE 9.0 on the same box, and everything is fine, so I know it's not a hardware issue. In fact, as stated, everything worked when running core 2 test 1. Thanks in advance for any and all enlightenment. - Gary

[Varkk]

Apparently the newest kernel has the
CONFIG_4KSTACKS=y removed but a new problem is introduced
CONFIG_REGPARMS = y is set and this creates more problems.
Some info here:
http://www.nvnews.net/vbulletin/showthread.php?t=26745

[LordMorgul]

Originally posted by Gary
Thinking this may have solved the Nvidia driver issue I once again installed the 5336 Nvidia driver and edited /etc/X11/XF86Config. After reboot though, the changes revert back. Am I doing something wrong or is this a bug?
The changes you make to the config file revert? Is that simply the 'Driver' change from nv to nvidia?

How did you install the driver, from an RPM source or from the official nVIDIA driver installer script? If you used the rpm.livna.org RPM then it installs an init script to set or unset the driver at boot time (which helps to make sure you do not boot into a kernel without the driver module available and get stuck)... this script may be failing to find the driver module for your kernel and changes back to nv. Did you run depmod yet after installing?

[Finalzone]

Where can I find rpm Nvidia? I looked to rpm.livna.org website and failed to find any.

[LordMorgul]

The livna.org server blew a gasket.. or something, so its down temporarily.

There is no RPM available there for 1.91, but the SRPM they have can be modified and rebuilt for 1.91 kernels. This does not require an extensive knowledge of RPM or packaging.. the changes are simple in nature.

The specfile installed by the SRPM contains a requires for XFree86 which no longer works (with xorg-x11). So, removing that requires completely was the way I have dealt with the problem. Know that it should not just be removed if you are going to distribute the package to anyone... you're testing so you should know whether xorg is installed right and not require the package dependency.

Install the SRPM. Edit the specfile in the SPECS directory of your rpmbuild (if you have not created a user specific rpmbuild directory it will be found in /usr/src/redhat/SPECS). Once the change is made (removal of dependency on XFree86) rebuild the package using:
rpmbuild -ba nvidia.spec

The requires that must be removed looks like:
Requires: XFree86

[Finalzone]

LordMorgul: I use the kernel-source 2.6.5-1.322 for building the new nvidia rpm. Unfortunately it provide this error:

CC [M] /usr/src/redhat/BUILD/nvidia-driver-1.0.5336/NVIDIA-Linux-x86-1.0-5336-pkg0/usr/src/nv/os-registry.o
In file included from include/linux/list.h:7,
from include/linux/wait.h:14,
from include/asm/semaphore.h:41,
from include/linux/sched.h:18,
from include/linux/module.h:10,
from /usr/src/redhat/BUILD/nvidia-driver-1.0.5336/NVIDIA-Linux-x86-1.0-5336-pkg0/usr/src/nv/nv-linux.h:52,
from /usr/src/redhat/BUILD/nvidia-driver-1.0.5336/NVIDIA-Linux-x86-1.0-5336-pkg0/usr/src/nv/os-registry.c:14:
include/linux/prefetch.h: In function `prefetch_range':
include/linux/prefetch.h:62: warning: pointer of type `void *' used in arithmetic
LD [M] /usr/src/redhat/BUILD/nvidia-driver-1.0.5336/NVIDIA-Linux-x86-1.0-5336-pkg0/usr/src/nv/nvidia.o
Building modules, stage 2.
MODPOST
/usr/src/redhat/BUILD/nvidia-driver-1.0.5336/linux-2.6.5-1.332/Module.symvers: No such file or directory
make[3]: *** [__modpost] Error 134
make[2]: *** [modules] Error 2
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.50633 (%build)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.50633 (%build)


Does it have something to do with the kernel source?

[LordMorgul]

Building modules, stage 2.
MODPOST
/usr/src/redhat/BUILD/nvidia-driver-1.0.5336/linux-2.6.5-1.332/Module.symvers: No such file or directory

Yes, this is caused by a bug in the Makefile process for the driver. The kernel packaging does not supply what is required for rebuilding modules in the source tree, which is what the driver is trying to do... so it still does not correctly work with the livna.org rpms. Search bugzilla for Module.symvers for some background, this is a change made in the kernel build process that effects external modules (changes the suggested build process slightly). Module.symvers is now included in the binary kernel RPMs, as /lib/modules/<vers>/build/Module.symvers. Kernel -1.327 has Module.symvers, earlier kernels do not.. if you need it for an earlier kernel you must do a full kernel re-compile in the source tree (which creates this file when the modules are compiled). Make sure to use the appropriate config file for the kernel.

The workaround I have currently has two steps.
Step 1: The Modules.symvers file must be copied from the kernel's build directory (/lib/modules/<vers>/build into the kernel's source directory. This is because the livna rpm spec requires recursively copying the source tree which does not contain Module.symvers (it is ONLY distributed with the binary kernel package, this will not change [per Arjanv's comments]).

Step 2: Change the kernel-source directory's Makefile to ignore removal of the Module.symvers file during make mrproper. Remove the red text.

MRPROPER_FILES += .config .config.old include/asm .version \
include/linux/autoconf.h include/linux/version.h \
Module.symvers tags TAGS cscope*


Now when the installer accesses the kernel-source it will find Module.symvers during MODPOST. The kernel source tree should NOT be used to compile a new kernel or build modules inside unless Module.symvers is manually removed (as it would have been removed during mrproper before...).

This is a dirty workaround and not intended as best practice. The livna.org spec file should be reworked to build from the files present in /lib/modules/<vers>/build instead, which is now a directory containing the necessary files and no longer just a symlink to /usr/src/linux-<vers>. So far my tweaks to it have not worked, but if I get this going it'll be posted to livna bugzilla.
http://bugzilla.livna.org/show_bug.cgi?id=83

[Finalzone]

Following your method, nvidia rpm is succesfully built and comes with kernel-modules-<uname -r> and nvidia-glx. Unfortunately, after installing it there is no graphical mode no matter the driver (nv or nvidia). I guess I should wait for Nvidia release or Livna to rewrite their specs or rpm for Fedora Core 2.

Thank you, LordMorgul, I have learn to twikle some specs.

[LordMorgul]

The -1.332 kernel has 4KSTACKS built in without the option to disable them, the driver will not work with this... a kernel recompile is required, it appears you are using the default version. I'll post soon the steps to rebuild the latest kernels without the nostack patch -- need to study for a quiz right now. :)

[Finalzone]

Hard to believe there is no CONFIG_4STACKS in kernel .config. I installed Fedora Core 2 Test 3 and repeat the method. Alas, kernel_nvidia_modules crashed after rebooting.


I installed the latest kernel 2.6.5 (349) but there is no way to disable 4 stacks. It seems the new Nvidia driver will come after the release of FX 6800....