[PATCH] nv-1.0-8756 with Xen-3.0.1 on Fedora Core 5

[JaXXoN]

Hi!

I figured out how to get the nvidia linux graphics driver
working with the latest Fedora Core 5 stock xen0 kernel
(means, without the need to patch and recompile the kernel).

The patch for the nvidia glue sources (patch-nv-1.0-8756-xen-3.0.2-2)
can be found at: http://www.nvnews.net/vbulletin/showthread.php?t=68648


1. Install the xen kernels:

yum install kernel-xen0 kernel-xen0-devel
yum install kernel-xenU kernel-xenU-devel

This will also install the xen tool package and create an appropriate
boot menu option for the bootloader in /boot/grub/menu.lst.

2. Patch and compile the nvidia kernel module:

cd /usr/local/src
cp -r <nvidia glue sources> nv-1.0-8756-xen-3.0.2-2
cd nv-1.0-8756-xen-3.0.2-2
patch -p1 < <path to patch>/patch-nv-1.0-8756-xen-3.0.2-2
make clean
make SYSSRC=/usr/src/kernels/2.6.16-1.2080_FC5xen0-i686 module

3. Manually define the missing symbol entry for xen_tlb_flush():

cd /usr/local/src/nv-1.0-8756-xen-3.0.2-2
XEN_TLB_FLUSH=`grep xen_tlb_flush$ /boot/System.map-2.6.16-1.2080_FC5xen0 | colrm 9`
ld -m elf_i386 --defsym xen_tlb_flush=0x$XEN_TLB_FLUSH -r -o nvidia.ko nvidia.o nvidia.mod.o

4. Install the nvidia kernel module:

cd /usr/local/src/nv-1.0-8756-xen-3.0.2-2
cp nvidia.ko lib/modules/2.6.16-1.2080_FC5xen0/kernel/drivers/video
depmod -a 2.6.16-1.2080_FC5xen0

Reboot your system and select the "Fedora Core (2.6.16-1.2080_FC5xen0)"
in the grub bootloader menu.

Feedback appreciated

regards

Bernhard

[metagroboliser]

I can verify that this works flawlessly. Brilliant work JAXXON. Thanks for your effort! I urge you to forward this to both nvidia and the livna folks for inclusion into their standard packages.

cheers.

[vogon1]

Awesome! I will try tonight and report back.

Sietse

[Edit]
Confirmed, works flawlessly!

Sietse

[nodens2099]

mhmm... almost worked here

On a debian sid with 2.6.16 kernel and 3.0.2 xen, no step failed, the driver loads, but the system crashes when xorg is started.

Well, I guess I'll have to wait until nvidia release a driver with official xen support.

[JaXXoN]

Originally Posted by nodens2099

On a debian sid with 2.6.16 kernel and 3.0.2 xen, no step failed, the driver loads, but the system crashes when xorg is started.

Is the system completly dead or can you still do a remote login?
Do you have a chance to capture the kernel log through serial console?
Is the kernel you are using a pre-compiled one (i.e. installed with apt-get)?

You may try to build the kernel from source running through these
advanced instructions:
http://www.nvnews.net/vbulletin/showthread.php?t=68648

regards

Bernhard

[nodens2099]

Hi Bernhard,

First, sorry for the late anwer. I completely forgot that the thread notifications where on my gmail address, as my free.fr one is banned

The system is not dead. I can use the sysRQ keys to send a SaK to the X and then change VT.

Here are the relevant kernel logs and my kernel config.

nvidia_kernel.log

config-xen0-2.6.16-1-xen-amd64-k8.txt

I am not willing to compile a vanilla kernel. I need a debian one for consistency...
However, this is not a precompiled one, but a debian one + xen patches.

Regards, and thanks for working on the xen + nvidia issue

--
Clément Hermann (nodens)

[JaXXoN]

Originally Posted by nodens2099

Here are the relevant kernel logs and my kernel config.

Apr 29 15:59:34 haven kernel: NVRM: loading NVIDIA Linux x86_64 Kernel Module  1.0-8756  Wed Mar 29 15:12:41 PST 2006
Apr 29 15:59:35 haven kernel: NVRM: builtin PAT support disabled, falling back to MTRRs.
Apr 29 15:59:35 haven kernel: Unable to handle kernel NULL pointer dereference at 0000000000000001 RIP: 
Apr 29 15:59:35 haven kernel: <ffffffff8858f9cf>{:nvidia:nv_vm_malloc_pages+473}

Obviously there is a problem in nv_vm_malloc_pages().

You may sprinkle that function (in nv-vm.c) with printks to figure
out and report where exactly the memory access fault happens.
Maybe that gives is some clues what's the problem.

BTW.: please note that i only tested the patch on 32-bit FC5.

regards

Bernhard

[nodens2099]

D'oh. Forgot to mention that I had more unknown symbols that juste xen_tlb_flush.
force_evtchn_callback and xen_features are unknown as well to the nvidia driver, so I used the same method than with xen_tlb_flush to add them in the module.

I'm not familiar with kernel development, and have only little knowledge of C, but I'll try to add printk() where it makes sense as you suggests.

[JaXXoN]

Originally Posted by nodens2099

force_evtchn_callback and xen_features are unknown as well

This is also true for a vanilla kernel. If you compile a (debian) kernel
from scratch anyway, you may consider applying the kernel patch
mentioned in the other post (see link above): it will export all three
symbols. Then you can omit the manual linking stage.

Originally Posted by nodens2099

I'm not familiar with kernel development, and have only little knowledge of C, but I'll try to add printk() where it makes sense as you suggests.

No need to have deeper insights in this case: just open nv-vm.c
in a text editior, look for "nv_vm_malloc_pages" (line 398)
and add something like "printk("line number xxx\n");" i.e. in (all?)
empty lines between line 413 and 575. Then re-compile and report
the modprobe output.

regards

Bernhard

[nodens2099]

well, I defined a macro DBG printk(KERN_DEBUG "File : %s Line:%i\n", __FILE__, __LINE__); and put it on almost every line.

But I didn't use it. Please, someone, hit me. Shoot me in the head.

It just came to my mind that I was on a x86_64 arch, so the addresses are.. 2 times longers

So, blindly following your instructions when it came to the linking part was just *stupid* of me

On a 64bits arch, | colrm 9 when grepping the System.map will only output "ffffffff".
Every added symbol had a 0xfffffff address in the module, so no wonder it didn't work. I did it again with the full address, and it was much, much better

For the debian users out here, here is how I added the symbols :

for sym in xen_tlb_flush force_evtchn_callback xen_features; do
    export $sym=$(egrep " $sym\$" /boot/System.map-xen0-2.6.16-1-xen-amd64-k8 | colrm 17)
done
ld -m elf_x86_64 --defsym xen_tlb_flush=0x$xen_tlb_flush --defsym force_evtchn_callback=0x$force_evtchn_callback --defsym xen_features=0x$xen_features -r -o nvidia.ko nvidia.o nvidia.mod.o

Don't forget to change the colrm 17 to colrm 9 if you're on x86 !

Thanks for your help, Bernhard, it works perfectly now. Great work !

[JaXXoN]

Originally Posted by nodens2099

On a 64bits arch, | colrm 9 when grepping the System.map will only output "ffffffff".

Ooops, right! :-)

I guess your spell should work for 64bit FC5 as well
(except that only xen_tlb_flush need to be handled).

Originally Posted by nodens2099

it works perfectly now

Cool!

regards

Bernhard

[nodens2099]

mhmm... I was wrong when I said there was no problem anymore. It seems like GLX fails.

glxinfo gives the following : "Error: couldn't find RGB GLX visual" and then some values.
glxgears gives : ""Error: couldn't get an RGB, Double-buffered visual"

any gl app fails. also, nvidia-settings segfaults when you try to see GLX information.

But, twinview is working and that was what I needed
Still, I need to reboot into a non-xen kernel If I want to play a GL game.