XEN - NVIDIA - STEP BY STEP

[archie18]

Same thing here for RHEL5 with Nvidia drivers 173.08 and 177.82 and Red Hat kernels 2.6.18-92.el5xen, 2.6.18-92.1.22.el5xen and 2.6.18-120.el5xen (all x86_64).

Once I start the X server the screen turns black and the system becomes unresponsive. Only a hard reset helps.

Andy

[andreim]

.. In the end, I had to abandon the idea to use Xen+Nvidia su SUSE SLES10 SP2.

I have however was able to successfully build the 177.82 driver on OpenSuse 11.1 /64 bit!
It uses the far more recent kernel (2.6.27+), and apparently this helps.

Right after it started to work, my Dell XPS M1330 began running with the fan always on.
After some digging on the web, I discovered that that could be a BIOS problem. Indeed,
this new issue was gone after I migrated from A10 to A14.

[Felix.K]

Firstly, I want to thank muchologo for his tutorial, because it was the only solution I found that made the nvidia driver working in my XEN Dom0 Kernel. But I also discovered the problem that I am no longer able to see (or switch back to) any TTYs after I startet X.

My Hardware is an Intel QuadCore @ 2.8 GHz, 4 GB DDR2 RAM and a GeForce 8800 GT.
I used the newest official XEN Hypervisor (3.3.1) and the newest Dom0 Kernel that is published by XenSource (2.6.27.5). My NVIDIA driver is 180.22 and everything is 64-Bit.

Secondly, I have done some further investigations on this problem:
The problem happens, when an X server starts with the nvidia driver, but not when the module is loaded without any X system. So it only occurs after starting X.
It disallows me to switch back to any TTY on the screen, no matter how I try to do it (stopping X, Ctrl + Alt + F1, rebooting, executing chvt 1). But the TTYs are still running without problems (except that I can't see anything on the screen), because I can still type in commands and they are actually executed. I can also switch back to X.
In addition, there is no problem with running multiple X servers and switching between them. I can even stop the second one and return to the first without problems by pressing Ctrl + Alt + F7. But still there are no normal TTYs visible after I startet the first X.
After that, I tried accessing the system with a serial console and without any normal TTYs at all. That worked fine and the serial console is still running without any problems after I started X.
Now I tried to use serial and normal TTYs and removed the NVIDIA driver module after stopping X. My displays remained black and were in power saving mode (probably this is important: The displays are actually disabled).
Finally, I startet a new getty after I shut down X and removed the kernel module, but I couldn't see the new TTY either (but I could log in and execute commands without seeing anything).

I am now not able to test it again with acpi=off or pci=noacpi kernel parameters, because my HDDs are no longer detected when I use those options. Is there a way to specify a noacpi option only to the nvidia driver module?

[Deaddreamer]

Short version is:

IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM" ./NVIDIA-Linux-x86_64-###.##-pkg2.run

While booted into Xen, all on 1 line and it will install, too.

[Morbid Angel]

cool it works for debian lenny to... but how stable is it?

[Felix.K]

@Deaddreamer:
This short version didn't work for me, because I had my kernel source not in /usr/src.
But I see if you got them there, it works fine.

@Morbid Angel:
Except the bugs I've already told here, I could not see any stability issues. I've started SDL HVMs using OpenGL more then ten times (using them for some minutes or even up to an hour) without any problems. The driver really improved the SDL performance and I was able to play 3D Games native and with wine without any problems. I haven't done some 3D benchmarks, so I can't tell you wether this solution impacts performance. I didn't feel any difference during the playing.
But this Problem with TTY1-6 is quite annoying...

[badguitar]

If anyone knows of a workaround to Felix.K's problem, I'd love to hear it-- I seem to be having the exact same issue. I can boot into X and Compiz in Gnome even works fine, but when I log out of X, or hit ctrl+alt+backspace, or hit ctrl+alt+f1, the display goes blank and never recovers. (It actually says it is going into power saving mode, but I don't know if the power saving note is significant-- the monitor gives the same message if I turn on the monitor without plugging the monitor into a video card, so I just associate that message with the screen receiving no input). If I open gnome-terminal and do a "sudo shutdown -r now", instead of just logging out of X, the screen stops reporting output, but the machine successfully reboots, so it looks like the issue is not a kernel panic or anything-- output just stops being sent to the monitor (just as Felix.K says). I don't have this screen-dying problem if I use the non-xen kernel.

I'm running Debian stable (Lenny) with the Xen kernel on AMD 64 (2.6.26-1-xen-amd64). I have a GeForce 8800 GTS, and I'm using NVidia's 180.29 driver. I have some kind of NForce motherboard (I can find out exactly what kind if anyone thinks it's relevant), and an Optiquest Q22wb monitor.

I didn't use the -DNV_SIGNAL_STRUCT_RLIM or -DNV_VMAP_4_PRESENT flags when I installed the NVidia driver (because I installed the driver before reading this thread), but I assume that's not what is causing my problem, since Felix.K has the same problem when using those flags. (What does passing those preprocessor definitions do, by the way?) If anyone thinks the absence of those flags could be the problem, perhaps I should see if adding them make a difference.

[Felix.K]

Hello badguitar, thank you for reporting this issue, too.

I've tried the installation with and without those preprocessor definitions, and it seems that they are no longer needed since 180.xx (I don't know the exact version it worked without those flags, but 177.xx needed them).
But this flags didn't change anything with this problem...

In addition I found a workaround for my problem with having the kernel source in another path (it's interesting that this workaround is only needed with XEN Kernels...):
IGNORE_XEN_PRESENCE=y ./NVIDIA....run --kernel-source-path="$(readlink /lib/modules/$kernel_version/source)" --kernel-output-path="$(readlink /lib/modules/$kernel_version/build)"

BTW, with this command line, I only rebuild the kernel module for any (even not-running) XEN- or non-XEN-Kernel (I think I don't need to explain $kernel_version):
IGNORE_XEN_PRESENCE=y ./NVIDIA....run -qanK --no-x-check --kernel-source-path="$(readlink /lib/modules/$kernel_version/source)" --kernel-output-path="$(readlink /lib/modules/$kernel_version/build)" -k "$kernel_version"