see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419943
related to a kernel change
The 1.3 series of the X.org server has a bug where the version reported changed from 7.2.* to 1.*. This confuses nvidia-installer into thinking that your X server is very old and it installs the X modules in the wrong place. To work around this problem, use the following options:
# sh NVIDIA-Linux-version.run --x-module-path=`X -showDefaultModulePath 2>&1 | cut -d, -f1` --x-library-path=`X -showDefaultLibPath 2>&1`32-bit distributions with 64-bit kernels
Some distributions have the option of installing a 64-bit kernel for use with all 32-bit userspace programs. This configuration is not supported by the NVIDIA Linux Graphics Driver. If you try to install the 64-bit driver package on such a system, you will receive an error like the following:
./nvidia-installer: No such file or directoryIf you have this configuration, use your distribution's package manager to install a 32-bit kernel and then install the 32-bit version of the NVIDIA Linux Graphics Driver.
Using the NVidia driver on a Linux Kernel 2.6.2x with paravirtualization turned on
With this page I'd like to make a short introduction to how to get the NVidia driver running on a Linux Kernel version 2.6.20 or newer compiled with paravirtualization turned on.
Skip to the easy solution
I just added a new version of the NVidia driver that is tuned to work on a 2.6.21 kernel. That proves that the solution is compatible with newer kernel versions. If there are problem with installing the driver on a 2.6.20 kernel please let me know and I'll publish one assembled for that version.
This description is based on the post from Hugo in the Debian Users mailing list. It can be found here but below is the complete content of this post once again.
HOWTO:2.6.20-1-k7 + nvidia Click to flag this post 3 stars [3 stars] [3 stars] by Hugo Vanwoerkom May 02, 2007; 12:36pm :: Rate this Message: - Use ratings to moderate (?) Reply | Reply to Author | View Threaded | Show Only this Message Hi, If you get this message with a nvidia closed driver install: FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol ‘paravirt_ops’ and you are running Sid's latest Debian stock kernel, then there is a workaround that was published in the nvidia linux forum: http://www.nvnews.net/vbulletin/showthread.php?t=87541 I have reworked the solution for Debian based upon another forum thread: http://www.nvnews.net/vbulletin/showthread.php?t=89844 1. Rebuild the linux-kbuild-2.6.20 .deb: a. apt-get update b. apt-get build-dep linux-kbuild-2.6.20 As user: c. mkdir linux-kbuild-2.6.20-build d. cd linux-kbuild-2.6.20-build e. apt-get source linux-kbuild-2.6.20 The linux-kbuild-2.6.20 sources will be downloaded and unpacked into a folder. Cd to that folder, then: f. change linux-kbuild-2.6.20-build/linux-kbuild-2.6-2.6.20/scripts/mod/mod.c and delete lines 1197+1198. Please take care this is ONLY for 2.6.20. In 2.6.21 there is a case statement starting at approx the same location with two cases that have fatal() function calls in them. You can just delete the two-lined each fatal function call and that will do the same trick. g. dpkg-buildpackage -uc -us -rfakeroot (the .deb is created) 2. Install the rebuilt linux-kbuild-2.6.20_2.6.20-1_i386.deb 3. apt-get install linux-image-2.6.20-1-
I will try to give some hints about how to install the driver a bit easier manually and will present one patched version of this driver that can be installed automatically on most Debian systems and hopefully other distros based on Debian (like Ubuntu, Kubunto, Knoppix etc.).
First of all the steps needed to patch the kbuild system can not be avoided and IMHO are pretty well documented in the article. What a friend of mine noticed is that if you do this like the description suggests you are prompted again to update the package the next time you do apt-get upgrade/dist-upgrade. This can be avoid if you make a little trick. Instead of repackaging your fixed version do the following: [This practically means, do steps 1a - 1f and afterwards continue with the steps below]
1g. cd linux-kbuild-2.6.20-build/linux-kbuild-2.6-2.6.20/scripts/mod make 1h. apt-get install linux-kbuild-2.6.20 1i. cp -r linux-kbuild-2.6.20-build/linux-kbuild-2.6-2.6.20/scripts/mod \ /usr/src/linux-kbuild-2.6.20/scripts/ 2. Just skip this step and continue ahead.
I know this is a bit more unsafe but works well and will keep your fixed version as long as kbuild package stays the save version. I have seen the version is still ending with -1 this means they haven't changed it for the time the 2.6.20 kernel is out.
Next tip is a bit more tricky but actually helps you run nvidia-installer as it should be run without any further options or errors whatsoever.
1. Go to the directory where you have your unpacked driver (the one with nvidia-installer file) 2. cd usr/src/nv/ 3. open with your favourite editor Makefile.kbuild and just after line 77 that should read something like this : EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type....bla bla bla.... add the following two lines: PARAVIRT_OPS := $(shell grep "D paravirt_ops" /boot/System.map-$(shell uname -r) | colrm 9) EXTRA_LDFLAGS := --defsym paravirt_ops=0x$(PARAVIRT_OPS) 4. change back to the directory of nvidia-installer ( cd ../../../ ) and run it ( ./nvidia-installer )
After your fix the installer should run without problems and the driver should be up and running as it always was. I think this steps should work for the 2.6.21 kernel as well because as you see we do use uname -r to get the kernel version up there.
Before I describe the easy way to accomplish this let me spill some words about why this problem occurs.
THE PROBLEM WITH THE 2.6.20 KERNEL WITH PARAVIRTUALIZATION
It is a long ongoing discussion about ways for the kernel developers to distinguish between drivers written under GPL(&Co.) and proprietary drivers (Like NVidia's and ATI's). The reason why they do this is because they can't and don't want to give support to people with problems running such drivers because they can not legally debug (and moreover fix) problems occuring in or around the closed-source drivers. That is why when the kernel encounters such driver it sets a so called tainted flag in the kernel. Which means this kernel has been marked once and forever (well until next reboot) as not-supported one. This is the first thing the kernel support team will look for when you post bug-report and will just delete it from their lists. So now back to the problem. Some functions are marked in the 2.6.20 kernel as gpl usage only because maybe they are somewhat related to tainting the kernel and the developers want to prevent bad driver use them at all (this last sentence is however my personal opinion it is not based on facts). What happens is that when paravirtualization support is turned on many functions in the kernel call implicitly paravirt_ops - function marked as gpl only. One of these functions is udelay - function that makes a program stay idle for some period of time. And the nvidia driver uses udelay (I can't imagine a driver that won't use udelay somehow) and therefore you can not compile the driver normally. What one can do however is first fix the tool from the kernel driver building utilities that checks for drivers not marked as GPL and still using the GPL only functions and secondly because of the kbuild package still not linking such function automatically to bad drivers give the appropriate options to the linker to circumvent this and make the driver know of paravirt_ops function. Luckily all kernel functions are listed in the System map found under /boot/System.map-[kernel_version]. That is what enables us to get the driver back running when we perform the described steps.
THE SOLUTION
Now for these of you that read these lines and think of linux being f***ing difficult and only for nuclear scientists I collected these steps in an easy script that checks if your system resembles well enough mine to be relatively sure that you can apply these steps and have the same result. Afterwards it just copies a fixed precompiled version of modpost (the program you actually mess with in steps 1 through 5 from Hugo's manual (replaced partially by steps 1g - 2 maybe :-) ). It then uses the already modified Makefile to start the nvidia installer and conclude the install. Of course as I stat ein the script too you can not hold me responsible for any damage or psycological problems you might receive by using this script. It is without any guarantee and with no obligations whatsoever from my side to help you (although I will gladly try to help you if i can and have time for).
PS. Well a lot of people have already tested and reported these packages to work so I guess they should be pretty safe but this doesn't invalidate my previous statement :).
The package can be downloaded from here
http://grizach.servebeer.com/nvpatch/NVIDIA-Linux-x86-100.14.06-pkg1-patched.run - tuned for 2.6.21
http://grizach.servebeer.com/nvpatch/NVIDIA-Linux-x86-100.14.03-pkg1-patched.run - tuned for 2.6.20
http://grizach.servebeer.com/nvpatch/NVIDIA-Linux-x86-1.0-9631-pkg1-patched.run - tuned for 2.6.20
Last but not least some credits: First of all thanks to Hugo for describing this easy way to fix the NVidia drivers problem. To close transitively the thanks here I'd like to thank to the people from the mentioned nvnews threads. Last but not least I'd like to thank Peter Velichkov for finding this tutorial and actually testing it before I'd risk changing my kernel. Hell yes! This problem was the only reason I was sticking with a 2.6.18 kernel all the time till now (well the 2.6.19 was miserable mistake IMO [what can you expect from kernel with first message in the changelog - "please post BEFORE you go to parties and not AFTER" from Linus Torvalds :-P ]). Moreover it was his computer that first suffered the wrath of the script after I wrote it.
And just at the bottom the copy once again of the DISCLAIMER to be sure no one got me wrong and thinks I am violation something with this work. (Well in some sense we do overcome some kernel mechanisms to distinguish good from bad drivers, but come on, udelay not usable by any commercial drivers that is redicilous!)
DISCLAIMER: First of all this is our very own solution and we can not guaranteeThanks for using my script!
that it will work on your computer. Although I don"t think so it might
even blow your computer, more possibly just wipe something important ;-)
NVidia has also nothing to do with this modified version of the driver
so I guess no official support can be expected from them either
last but not least this binary driver taints the kernel so no support
is to be expected from Linus too :). The only ones that can help you
are either we or other users that are capable of understanding what is
going on in here.
According to the NVidia license this version of the driver should be legally ok:
"...Linux/FreeBSD Exception. Notwithstanding the foregoing terms
of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or
FreeBSD operating systems, or other operating systems derived from the
source code to these operating systems, may be copied and redistributed,
provided that the binary files thereof are not modified in any way
(except for unzipping of compressed files)."
No binary files have been modified only Makefile.kbuild have been changed
The fixed version of modpost is under GPL and that is why source code is included
in the archive too.
Julian
Useful links
http://www.nvnews.net/vbulletin/showthread.php?t=89844
http://www.nvnews.net/vbulletin/showthread.php?t=87541
http://www.nvnews.net/vbulletin/showthread.php?t=90214
in particular
For those of you Fedora Core 6 users who like to try out realtime preemption,
but are not willing to patch, compile and install a kernel from scratch, Ingo Molnar
is now maintaining approptiate kernel RPM packages. However, if you like to
use the nvidia linux graphics driver, with the most recent precompiled -rt kernel,
then you need to get around a few obstacles. Here is a step-by-step installation
instruction:
0. Make sure your installation does 3D acceleration with a standard kernel
(i.e. 2.6.19-1.2911.fc6)
1. Install the RT kernel:
wget http://people.redhat.com/mingo/realt...9.rt8.i686.rpm
wget http://people.redhat.com/mingo/realt...9.rt8.i686.rpm
rpm -i kernel-rt-2.6.20-0119.rt8.i686.rpm
rpm -i kernel-rt-devel-2.6.20-0119.rt8.i686.rpm
2. Modifiy "modpost" in order to accept non-GPL modules:
2a. Goto to the modpost directory
cd /usr/src/kernels/2.6.20-0119.rt8-i686/scripts/mod
2b. Delete the following two lines (1197-1198) in file modpost.c:
if (!mod->gpl_compatible)
check_for_gpl_usage(exp->export, basename, exp->name);
2c. Recompile modpost
gcc -o modpost modpost.c file2alias.c sumversion.c
3. Unpack, patch and compile the nvidia driver module
cd $PATH_TO_NVIDIA_DRIVER_PACKAGE
wget "http://www.nvnews.net/vbulletin/attachment.php?attachmentid=23993&d=1171124108"
sh NVIDIA-Linux-x86-1.0-9746-pkg1.run --extract-only
cd NVIDIA-Linux-x86-1.0-9746-pkg1/usr/src/nv
patch -p1 < ../../../../patch-nv-1.0-9746_realtime-preempt.txt make SYSSRC=/usr/src/kernels/2.6.20-0119.rt8-i686 module
Where $PATH_TO_NVIDIA_DRIVER_PACKAGE is the directory where you have
saved the nvidia driver package.
4. Manually define the missing symbol entry for "paravirt_ops"
PARAVIRT_OPS=`grep "D paravirt_ops" /boot/System.map-2.6.20-0119.rt8 | colrm 9`
ld -m elf_i386 --defsym paravirt_ops=0x$PARAVIRT_OPS -r -o nvidia.ko nvidia.o nvidia.mod.o
5. Install the nvidia kernel module
cp nvidia.ko /lib/modules/2.6.20-0119.rt8/kernel/drivers/video/
depmod -a 2.6.20-0119.rt8
Limitations
This instruction has only beed tested with 32-bit FC6. It may work for 64-bit,
but make sure to use "colrm 17" instead of "colrm 9" in step 4.
Feedback appreciated
Bernhard
Just to let you know, it is not anymore necessary to patch the nvidia
kernel driver for version 1.0-9755 along with kernel 2.6.20-0119.rt8!
The situation is that nvidia replaced the problematic semaphore
synchronization method by "completions" some times ago, and the
high latency causing "wbinvd" instruction (when PAT support is
enabled) has been replaced in 2.6.19 by a fast and interruptible
sequence of "clflush" instructions.
However, you may still need to manually define missing symbols
for pre-compiled kernels (see earlier post for an example).
regards
Bernhard
hallo,
howto use this with Kernel 2.6.21 ?
modpost.c looks different:
if (!mod->gpl_compatible)
check_for_gpl_usage(exp->export, basename, exp->name);
check_for_unused(exp->export, basename, exp->name); '
what shall i remove - all 3 lines ?
i tested one time and i get this error during compile :
scripts/mod/modpost.c:1172: Warning: »check_for_gpl_usage« defined, but not used
scripts/mod/modpost.c:1197: Warning: »check_for_unused« defined, but not used
Thanks
CooSee ' Ya
i did these steps (v1.0.9755):
2. Modifiy "modpost" in order to accept non-GPL modules (slightly different however: i recompiled the linux-kbuild-2.6.20 debian package)
unpack nvidia-driver (using "-x"), run ./nvidia-installer -K
4. Manually define the missing symbol entry for "paravirt_ops"
5. Install the nvidia kernel module
works.
debian statement on the issue, btw:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419943
Linux: KVM Paravirtualization
A new feature that will first be availble in the upcoming 2.6.20 kernel is KVM, a Kernel-based Virtual Machine. The project's webpage describes KVM as, "a full virtualization solution for Linux on x86 hardware. It consists of a loadable kernel module (kvm.ko) and a userspace component. Using KVM, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc." The project's FAQ explains that the functionality requires "an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V)." The userland aspect of KVM is a slighlty modified version of qemu, used to instantiate the virtual machine.
Ingo Molnar [interview] announced a new patch introducing paravirtualization support for KVM, outdating the KVM FAQ which in comparing KVM to Xen notes, "Xen supports both full virtualization and a technique called paravirtualization, which allows better performance for modified guests. kvm does not at present support paravirtualization." In describing his patch which is against the 2.6.20-rc3 + KVM trunk kernel, Ingo said it, "includes support for the hardware cr3-cache feature of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)". He went on to add, "some aspects of the code are still a bit ad-hoc and incomplete, but the code is stable enough in my testing and i'd like to have some feedback." In a series of benchmarks, he found 2-task context switch performance to be improved by a factor of four, while "hackbench 1" showed twice as good performance, and "hackbench 5" showed a 30% improvement. His email goes on to detail how the paravirtualization works.
2 comments:
Nice collection of information on the problem. I appreciate that you considered my small contribution for Debian too ;) Thanks. I hope you won't mind if I put a link to this post on my page too.
Cheers, Julian
32-bit distributions with 64-bit kernels
extract 32bit nvidia installer
extract 64bit nvidia installer
just copy ./usr/src/nv/nv-kernel.o
from 64bit to 32bit and run nvidia-installer from 32bit package. you may need to add -m64 flag to makefiles CCFLAGS
Post a Comment