"NVidia is great!" - Umm, no?

Fri Aug 31 18:42:13 UTC 2007

I've always tended to roll my own kernels since I'm not a huge fan of
the stock ones (they tend to be either "too little" or "too much", and
I prefer to support "everything that's in this machine." Therefore,
I'm not entirely sure how this works with the Debian stock kernels,
but on two of my machines running Debian /w Nvidia cards I haven't had
any issues getting 2.6.21 compiled and/or working. I haven't done
dual-DVI mind you, but it seems your issues with the "nvidia" module
are more in getting it compiled?

Let me know if you need some help. If all else fails perhaps I could
SSH into your desktop, roll a nice custom kernel (and step through the
process as necessary), and help you get those Nvidia drivers working.

Oh, and for the record, Intel's drivers usually work pretty nicely,
and they're probably the best out-of-the-box FOSS drivers due to, I'm
assuming, Intel supposedly being great at supplying specs for their
hardware. They tend to not be as high-end cards hardware-wise as
NVidia or ATI, but the i915 series was pretty good on some of the
machines at work (ran Beryl, played games such as Nexius nicely, etc).

ATI's drivers on Linux were nightmarish up until recently. I could
never get one to work without a lot of third-party patching. However,
since they've been bought up by AMD, I've noticed that the last ones
actually worked fine out of the box without much any patches. They do
have a GUI installer too. I have no comparison between driver
performance re ATI vs AMD though, as the one I use commonly is in my
laptop and I don't have a comparable NVidia card of that gen anyhow.

NVidia's drivers - with the exception of a few instances with recently
released kernels prior to an update coming out - have worked very
nicely for me. There was one other issue awhile back when Xorg started
modularizing their configuration rather heavily, but it didn't take
too long to be fix. But again, I roll my own kernels, and there's no
GUI interface if you're into that sorta thing. I've never run into any
GPL-only errors with 2.6.20+ (I think the latest I'm running on a
machine with NV is a 2.6.21 kernel, although I may be mistaken and the
laptop may have a .22), and I don't use CPU paravirtualization support
(the option in question), so maybe killing that off in your kernel
will make things happier. Another alternative would be to give me a
copy of these files

/proc/config.gz
/proc/cpuinfo
/proc/pci

(and let me know if you use IDE or SATA drives)
That should allow me or someone else with a bit of free time to build
a kernel that works for your machine, and then I can debianize for
your convenience as well.

Looking it up, it seems that either it's an issue specific to a few
kernels, or a certain kernel config. It's not an issue with NVidia,
but rather in fact with EXPORT_SYMBOL_GPL being set by some
overzealous kernel devs (even Linus doesn't agree with this), and
should be fixed in later kernels. Oh, and it's fixed in 2.6.22 as
well, see here :-)

http://www.nabble.com/Bug-432746:-nvidia-kernel-source:-module-build-fails-with-error-message-t4063733.html

I'm taking the liberty of closing this bug since the paravirt_ops symbol
is no longer marked as GPL-only in the 2.6.22 kernel.

Cheers,

Tyler

On 8/31/07, Giles Orr <gilesorr-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> This is a rant against the state of Linux video support.  Feel free to
> stop reading now.
>
> I recently purchased a NVidia video card, an XFX GeForce 6800 XTreme -
> AGP 8X, 256Mb DDR3 dual DVI.  Why isn't quite clear because I'm not a
> gamer, but it's a dual head card and I like things to run smoothly.  I
> bought it because fans of Open Source pretty much uniformly told me
> that NVidia products were really good, the way to go for high end
> video.  I beg to differ.
>
> NVidia users have to choose between two X drivers: the Open Source
> "nv" driver, and the binary-only "nvidia" driver.  As I said, I'm not
> much of a gamer so I figured the "nv" driver would be fine: with a
> card this powerful, even the relatively slow OS driver would produce
> good effect, right?  So I set the card up and everything went well
> until I started trying to run Xinerama.  X failed repeatedly, no
> matter how I massaged xorg.conf, telling me:
>
>    Fatal server error:
>    Requested Entity already in use!
>
> It took several days before I finally found a very small statement in
> someone's mailing list archive that the "nv" driver doesn't support
> dual head.  Sounds like it never has and possibly never will.  So here
> I am with two lovely LCD monitors I expected to run with my awesome
> new NVidia card, and unable to do so with the free driver.  I had
> avoided the "nvidia" driver not so much because I'm an OS fanatic
> (although I prefer to avoid proprietary software), but because
> installing it requires digging into the kernel.  There's a major
> problem here from my point of view: every time Debian upgrades the
> kernel I'm either going to have to stick with the old kernel or
> recompile a part of the support system for NVidia's proprietary
> driver, and quite possibly download a new version of the binary blob.
> Which is more likely to be kept up to date?  The OS "nv" driver -
> history has shown this.
>
> So I dug in and tried to get the "nvidia" driver working.  As of
> kernel version 2.6.20, the kernel developers are going out of their
> way to make it difficult to use proprietary binary blobs in the kernel
> to avoid "tainting."  The compile kept aborting with the message:
>
>    FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
>    'paravirt_ops'
>
> The general consensus online is that the best work-around for this
> problem (and it's acknowledged to not be very good) is to build a new
> kernel without paravirt_ops.  That's lovely: you completely break
> several forms of virtualization software if you do that, certainly
> qemu, probably others.  I don't often use this stuff, but I don't want
> to kill it!  And I HATE building kernels: I usually have to take three
> or four runs at it (not to mention the four to six hours of time it
> takes me to dig through all the kernel options) because the first few
> builds panic and die before I get the options right.
>
> But there's another method (thanks Jamon!):
> http://grizach.sc18.info/nvpatch/ .  This gentleman has patched
> NVidia's own build script to hack your kernel source to cut out checks
> for GPL violations.  It worked perfectly.  So in using this I've used
> obscure and untrustworthy software of dubious legality (he thinks
> NVidia's license allows him to do this, but I wonder) to subvert the
> enforcement of the GPL.  This is highly kernel-specific (Debian only,
> kernel 2.6.21-2 only) and will undoubtedly not work with the next
> Debian kernel release.
>
> All of this makes me remember my Matrox G400 with considerable
> fondness.  It was a good card.  Yes, it uses a binary blob, but no
> recompiles, just move the blob in with the modules every time you
> upgraded the kernel, and off you went.  <sigh>  Hell, even the ATI
> card I had prior to this was easier to get running.  If Torvalds is to
> be believed, Intel is the way to go (for non-gamers, anyway).  But ...
> do they even make add-on video cards?  I know them only for onboard
> video.  How about dual head?  I really love my dual head.
>
> This is definitely a place where Linux does NOT "just work."  I ain't
> defecting to Windows or anything like that, but I really, really, wish
> this all worked better.
>
> While I admit that I wrote this primarily so I could vent, I'd be
> pleased to hear anyone else on the subject - better choices, things I
> missed, even "you're an idiot" - so long as it's backed up by solid
> logic.  Thanks for "listening."
>
> --
> Giles
> http://www.gilesorr.com/
> gilesorr-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists