It would seem that the 185.19 drivers are necessary in certain cases to run the 2.6.29 kernel and compiz-fusion. Reproducible: Always
Created attachment 187515 [details] Ebuild for overlay
(In reply to comment #1) > Created an attachment (id=187515) [edit] > Ebuild for overlay > And here's where you actually get those drivers to download: x86: ftp://download.nvidia.com/XFree86/Linux-x86/185.19/ x86_64: ftp://download.nvidia.com/XFree86/Linux-x86_64/185.19/
That doesn't fix it for me though, nvidia-drivers still fail with git-sources-2.6.29. Some excerpts: test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \ echo; \ echo " ERROR: Kernel configuration is invalid."; \ echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \ echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo; \ /bin/false) *snip* /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:591: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:592: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:593: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:613: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:627: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:638: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:648: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:658: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:669: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:676: error: ‘struct proc_dir_entry’ has no member named ‘owner’ /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c: In function ‘nvos_proc_add_warning_file’: /var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.c:703: error: ‘struct proc_dir_entry’ has no member named ‘owner’ make[3]: *** [/var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv/nv.o] Error 1 make[2]: *** [_module_/var/tmp/portage/x11-drivers/nvidia-drivers-185.19/work/NVIDIA-Linux-x86_64-185.19-pkg2/usr/src/nv] Error 2 NVIDIA: left KBUILD. nvidia.ko failed to build! make[1]: *** [module] Error 1 make: *** [module] Error 2
(In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=187515) [edit] > > Ebuild for overlay > > > > And here's where you actually get those drivers to download: > x86: ftp://download.nvidia.com/XFree86/Linux-x86/185.19/ > x86_64: ftp://download.nvidia.com/XFree86/Linux-x86_64/185.19/ > I have actually tested this version, there are still issues that are not resolved in libGL as far as timing goes. You will notice general protection faults in various programs.
Created attachment 189541 [details] nvidia-bug-report Here is the nvidia-bug-report file that has already been sent to nvidia maybe they will review it and finish addressing the issues.
(In reply to comment #0) > It would seem that the 185.19 drivers are necessary in certain cases to run the > 2.6.29 kernel and compiz-fusion. > > Reproducible: Always > Actually 185.16.04 is newer then 185.19 both have the same issues at this point it seems nvidia is failing miserably.
*** Bug 270076 has been marked as a duplicate of this bug. ***
*** Bug 267594 has been marked as a duplicate of this bug. ***
The url should be concidered when talking about beta bugs. The 185.19 is not an official beta it is older then the official beta and pre-release that are avaliable at this time. http://www.nvnews.net/vbulletin/showthread.php?t=122606
I've also made it clear time and time again that the only NVIDIA driver releases that Gentoo will work with are the official releases and subsequently updated FTP releases, which are now called pre-releases. The last bug for some beta drivers I got NVIDIA involved in and as a result Aaron made a clarification for us on the status/quality of NVIDIA driver releases. Long story short, you may create bugs for beta drivers to share with fellow Gentoo-ers, but you won't find any official word from the maintainers on those driver versions.
according to http://www.nvnews.net/vbulletin/showthread.php?t=122606 current official release is 185.18.14
To install the 185.18.14 version, I've simply copied the ebuild from version 180.60 and renamed it to "nvidia-drivers-185.18.14.ebuild". Works fine with me on x86 (GeForce 8880 GTS, Quadro FX 3600M) and amd64 (Quadro FX 3600M). Tested with xorg 1.5.3, kde 3.5 and kde 4.2, and my CUDA 2.2 applications. Would be nice to see it in the portage tree. Clemens
Thanks for the suggestion - I copied and renamed the same ebuild and (after running 'ebuild digest') installed 185.18.14 and am running it now without any problems.
185.18.14 requires a patch to compile with =sys-kernel/vanilla-sources-2.6.31-rc1. http://www.nvnews.net/vbulletin/showthread.php?t=134779 patch: http://www.nvnews.net/vbulletin/attachment.php?attachmentid=37305&d=1245688007 Needs to be applied to .run file using: ./NVIDIA-Linux-x86_64-185.18.14-pkg[012].run --apply-patch nvidia-185.patch.txt (patch file has to be in same directory) The produced *-custom.run file can then be using instead.
Just discovered that this doesn't uninstall the old version properly. After installing it you must delete old OpenGL symlinks and libraries: cd /usr/lib64 rm libGL.so.1 && ln -s /usr/lib64/opengl/nvidia/lib/libGL.so libGL.so.1 rm libGLcore.so.1 && ln -s /usr/lib64/opengl/nvidia/lib/libGLcore.so libGLcore.so.1 rm libGLcore.so.180.27 rm libGL.so.180.27 I still get unresolved references in the new file though, maybe there's another old file hanging around I can't find? $ ldd -r libGLcore.so linux-vdso.so.1 => (0x00007fffd77c0000) libc.so.6 => /lib/libc.so.6 (0x00007fd8f8fd8000) /lib64/ld-linux-x86-64.so.2 (0x00007fd8fa67f000) undefined symbol: _nv000008gl (./libGLcore.so) undefined symbol: _nv000009gl (./libGLcore.so) undefined symbol: log (./libGLcore.so) undefined symbol: sqrt (./libGLcore.so) undefined symbol: powf (./libGLcore.so) undefined symbol: ceil (./libGLcore.so) undefined symbol: logf (./libGLcore.so) undefined symbol: floor (./libGLcore.so) undefined symbol: sqrtf (./libGLcore.so) undefined symbol: cosf (./libGLcore.so) undefined symbol: fmod (./libGLcore.so) undefined symbol: cos (./libGLcore.so) undefined symbol: sin (./libGLcore.so) undefined symbol: pow (./libGLcore.so) undefined symbol: exp (./libGLcore.so) undefined symbol: sinf (./libGLcore.so) undefined symbol: ceilf (./libGLcore.so) undefined symbol: expf (./libGLcore.so) undefined symbol: floorf (./libGLcore.so) Only the two _nv references cause problems when compiling programs, but strangely enough Compiz etc. all work fine.
Created attachment 196721 [details] nvidia driver download official or not?
(In reply to comment #10) > official releases > pre-releases how to see that 185.18.14 is not an official release? i use this dialog to get the driver: http://www.nvidia.de/Download/index.aspx?lang=de
Created attachment 196768 [details] nvidia-drivers-185.18.14.ebuild nvidia-drivers-185.18.14.ebuild with check and patch for 2.6.31 ... just in case anyone is to lazy for manual patching ;) Kind regards Bjoern
Created attachment 196770 [details, diff] nvidia-185.18.14_kernel-2.6.31.patch This patch is taken from: http://www.nvnews.net/vbulletin/attachment.php?attachmentid=37305&d=1245688007 and is required for nvidia-drivers-185.18.14.ebuild kind regards Bjoern Olausson
So why hasn't a version bump been done for the nvidia driver? The is the newest stable release from nvidia. No patches need to be used to make it compile on kernels up to the 2.6.30.1.
The attached ebuild+patch works well (compiles & runs) for me on ~amd64 and kernel 2.6.31-rc2.
(In reply to comment #18) > Created an attachment (id=196768) [edit] > nvidia-drivers-185.18.14.ebuild > > nvidia-drivers-185.18.14.ebuild with check and patch for 2.6.31 > ... just in case anyone is to lazy for manual patching ;) > > Kind regards > Bjoern > Hi. It seems the ebuild downloads wrongly the frebsd tar.gz sources on my amd64 system. It is probably the missing EAPI="2" in the ebuild.
what is going on? is there a maintainer for the nvidia driver? is he dead?
Comment #10 says that they only care about the official releases. I asked how to see weather a release is official or not - no answer. Comment #23 asked if the maintainer is dead - no answer too! so the answer must be "yes, i am dead". 185.18.14 is not a beta, so there should be an ebuild. the actual xorg-server/kernel-combination only works with this nvidia-version (for me).
Adding my two cents here to confirm 185.18.14 is offical non-beta release from Nvidia's site.
Created attachment 198432 [details] nvidia patch against 180.60 ebuild in main tree with fix for no-multilib setup Patch for 2.6.31 can be found here. Please always attach ebuild stuff as patches makes it much easier and faster to maintain such a bump.
I ask that as many multilib users test the change for non-multilib setups to ensure that both 64bit and 32bit libs are still properly installed for multilib setups.
Test report: I was using vanilla-sources 2.6.30.1 .I saw that the ebuild 185.18.14 from the zugaina overlay works fine. The ebuild 185.18.14-r1 from the otih overlay fails and could not be used with 2.6.30.1 .I changed then to 2.6.31_rc3 and try to reinstall the driver. Now the ebuild from zugaina fails but the one from otih works. Shortly: 185.18.14 ebuild from zugaina work with 2.6.30.1 but not 2.6.31_rc3 185.18.14-r1 ebuild from otih work with 2.6.31_rc3 but not with 2.6.30.1
Is this driver not going into portage because of http://bugs.gentoo.org/show_bug.cgi?id=274672 ? That bug mentions waiting for some regression to be fixed, I'm not sure if that means in the kernel or in nvidia's driver. But in any case, it would be good to know if there won't be an update in portage until the _next_ official driver gets released.
I've just pushed a new ebuild for 185.18.14 to the CVS. The ebuild does not include any patches for the kernel part of the package -- I'm following the policy of the Gentoo NVIDIA team here. The ebuild includes the no-multilib fix, which seems reasonable to me. I don't have any experience with multilib or a machine to test it on, so if anyone can test it and report whether it works or not, that would be appreciated.
Apologies for ignorance here, but how does one see if they're running multilib or not? Pointers appreciated if the answer's on a separate page.
(In reply to comment #31) > Apologies for ignorance here, but how does one see if they're running multilib > or not? Pointers appreciated if the answer's on a separate page. > ls -lad /etc/make.profile
Here are your available profiles billydv@Linux1 ~ $ eselect profile list Available profile symlink targets: [1] default/linux/amd64/2008.0 [2] default/linux/amd64/2008.0/desktop * [3] default/linux/amd64/2008.0/developer [4] default/linux/amd64/2008.0/no-multilib [5] default/linux/amd64/2008.0/server [6] hardened/amd64 [7] hardened/amd64/multilib [8] selinux/2007.0/amd64 [9] selinux/2007.0/amd64/hardened [10] hardened/linux/amd64 Unless you are running no-multilib on an amd64 box, you have multilib. X86 arch is not multilib. Spock, can you please tell me where exactly is the new ebuild, I tried searching but couldn't find an overlay for your work.
Spock, never mind, it's obviously in the main tree.
I'm running multilib, and so far so good. Passed a prelim test with Second Life on 2.6.29.3 system.