Language Selection

English French German Italian Portuguese Spanish

Nvidia driver hack for Xen kernel - SUSE 10.1

Filed under
SUSE
HowTos

I've been wrestling with Xen for a week or so now but before I post some articles about Xen itself I'd like to share this quick hack to get the Nvidia binary driver working with the SUSE 10.1 Xen kernel.

While the 'nv' driver is excellent it's nice to have all the features of my hardware available, even if unfortunately it means using a blob driver from Nvidia. Also the nv driver doesn't seem to probe my monitor using EDID and seems to use more generic modes. This means that while overall image quality is excellent, the DPI is wrong for my hardware and so I have to tweak font sizes and such things. It may be possible to fix this by using custom modelines in my xorg.conf, or to force the nv to probe my screen using EDID but for that amount of effort I may as well get the Nvidia driver working.

Anyway, here's the hack to get the latest Nvidia driver ( 8762 as I write this ) working with the Xen kernel. It should work for x86_64 also but I only tested it for x86. Props to JaXXon on the nvnews.net forums for the original FC patch.

Instructions

HAck to Nvidia driver for Xen kernel - SUSE 10.1

Hi
How can i get your files for work nvidia on xen?

best regards
pascal Sommer

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Graphics: Mesa and More

Red Hat Leftovers

Kernel: CH341 and LWN Articles (Just Freed)

  • Linux Adds CH341 GPIO
    There was a time when USB to serial hardware meant one company: FTDI. But today there are quite a few to choose from and one of the most common ones is the WCH CH341. There’s been support for these chips in Linux for a while, but only for use as a communication port. The device actually has RS232, I2C, SPI, and 8 general purpose I/O (GPIO) pins. [ZooBaB] took an out-of-tree driver that exposes the GPIO, and got it working with some frightening-looking CH341 boards.
  • Shrinking the kernel with an axe
    This is the third article of a series discussing various methods of reducing the size of the Linux kernel to make it suitable for small environments. The first article provided a short rationale for this topic, and covered link-time garbage collection. The second article covered link-time optimization (LTO) and compared its results to link-time garbage collection. In this article we'll explore ways to make LTO more effective at optimizing kernel code away, as well as more assertive strategies to achieve our goal.
  • The rest of the 4.16 merge window
    At the close of the 4.16 merge window, 11,746 non-merge changesets had been merged; that is 5,000 since last week's summary. This merge window is thus a busy one, though not out of line with its predecessors — 4.14 had 11,500 changesets during its merge window, while 4.15 had 12,599. Quite a bit of that work is of the boring internal variety; over 600 of those changesets were device-tree updates, for example. But there was still a fair amount of interesting work merged in the second half of the 4.16 merge window; read on for the highlights.

Wine-Staging and Games