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.
