Bugzilla Bug 212290

169.09-r1 is necessary to work with kernel 2.6.24. For day to day usage, I
still recommend 100.14.23 but 169.09 does have improved OpenGL performance. 

Option "UseCompositeWrapper" "true" is recommended for the 169.xx series to
work around some color distortion issues.

*** Bug 210321 has been marked as a duplicate of this bug. ***

169.09 is required for my card and has been working well for quite some time,
amd64ing

Hi,

I just wanted mention that 100.14.19 (and maybe 100.14.23 as well but I didn't
test it) _does_ work with kernel-2.6.24.x
I cannot switch to the 169.xx series of the drivers as these won't let me use a
second X-server on my machine without crashing the already running first
X-server instance. This bug is known by nvidia at least since 169.07[1] but
they seem to be unable to fix this problem :-(

Cheers
Poly-C

[1] http://www.nvnews.net/vbulletin/showthread.php?t=81256&page=9

(In reply to comment #3)
> I just wanted mention that 100.14.19 (and maybe 100.14.23 as well but I didn't
> test it) _does_ work with kernel-2.6.24.x

 You use x86?

(In reply to comment #3)
recently switched to x11-drivers/nvidia-drivers-169.12 and 2 X-servers (via
gdm) works for me. 

2.6.24-zen3 and ~x86

(In reply to comment #4)
> (In reply to comment #3)
> > I just wanted mention that 100.14.19 (and maybe 100.14.23 as well but I didn't
> > test it) _does_ work with kernel-2.6.24.x
> 
>  You use x86?
> 
One machine is completely x86, the other one is ~x86 with some exceptions in
the toolchain (also x86).

(In reply to comment #3)
> I just wanted mention that 100.14.19 (and maybe 100.14.23 as well but I didn't
> test it) _does_ work with kernel-2.6.24.x

 Cardoe, so why should we stable the hard-masked 100.14.23 then?

I dunno. I guess I forgot that I had masked them and just went off of timeline.

(In reply to comment #8)
> I dunno. I guess I forgot that I had masked them and just went off of timeline.

 Ok, I take tests from users on this bug as sufficient testing (no Nvidia
hardware here), emerge goes smooth anyway.  Stable x86 and closing.

Wish I had seen this bug earlier. The 169.x series drivers have fairly serious
regressions on my card, GeForce 6600 GT, including corruption of some textures
(affecting ut2k4 among others) [1], and bad refresh rate selection at some
resolutions [2].

I just confirmed both problems are still present in 169.12 as well.

[1] http://www.nvnews.net/vbulletin/showthread.php?t=108491 and
http://www.nvnews.net/vbulletin/showthread.php?t=104363
[2] http://www.nvnews.net/vbulletin/showthread.php?t=106808

Well then all I can recommend is to not upgrade to kernel 2.6.24

(In reply to comment #11)
> Well then all I can recommend is to not upgrade to kernel 2.6.24

This seems like a non sequitur, as well as non-constructive. I'm pretty sure
the bugs I mentioned have nothing to do with kernel 2.6.24. Also, it's a bit
late. I've had 2.6.24 installed for a while now.

(In reply to comment #12)
> (In reply to comment #11)
> > Well then all I can recommend is to not upgrade to kernel 2.6.24
> 
> This seems like a non sequitur, as well as non-constructive. I'm pretty sure
> the bugs I mentioned have nothing to do with kernel 2.6.24. Also, it's a bit
> late. I've had 2.6.24 installed for a while now.
> 

nvidia-drivers are binary only. There is nothing Gentoo can do to control them,
to fix them or to control their reliability. All we can do is simply provide
what NVIDIA provides. Certain people experience regressions between driver
versions and as such those people are told to avoid the current release.
However NVIDIA only supports the current release and only the current release
works with kernel 2.6.24 officially.

If Gentoo masked or removed every driver version that one person experienced
regressions with, we'd never have a single nvidia-drivers package in the tree.

So, mask the current driver that doesn't work for you and wait for the next one
since NVIDIA is aware of the situation and has fixed it for future releases.

This is NOT stable. This just cost me ~3hrs, and a client even more. DO NOT
mark ebuild stable for hardware you do not have. I am going to de-stabilize
this ebuild immediately.

Please DO NOT stabilize again unless it's confirmed to be stable. And FYI I am
running a .24 kernel with x11-drivers/nvidia-drivers-100.14.19.

Thanks for the massive headache. Please advise who I send the bill to and lose
of revenue.

NVIDIA only provides their X11 drivers in a binary fashion, as such there is
not much debugging or troubleshooting Gentoo can do with issues reported about
them.

You can use nvidia-bug-report.sh to generate some information to e-mail over to
NVIDIA @ linux-bugs@nvidia.com and you may also wish to consider exploring
NVIDIA's Linux driver forum @
http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14

To further assist in debugging the issue and to have more information to
provide NVIDIA (and have a better chance that your issue will get fixed in the
future), you can attempt to debug your X server. To debug your server properly,
please follow the documentation outline here,
http://www.x.org/wiki/Development/Documentation/ServerDebugging

The above link does not contain references to how to perform this properly on
Gentoo. In a nutshell, you must rebuild X and it's libraries with USE=debug,
add -ggdb to your CFLAGS, and add splitdebug to FEATURES. More information
about this can be found at http://www.gentoo.org/proj/en/qa/backtraces.xml

Since this bug is with nvidia-drivers, which is a package that Gentoo has
minimal control over, this bug will be marked as UPSTREAM. However, in the
event that you debug your X server and can produce a backtrace, please feel
free to post it here and if it is unrelated to nvidia-drivers you or a Gentoo
developer can re-open this bug and address the issue where it truly lies.