Compiling both the kernel and the module produces these warnings: WARNING: /lib/modules/2.6.16-gentoo/video/nvidia.ko needs unknown symbol remap_page_range WARNING: /lib/modules/2.6.16-gentoo/video/nvidia.ko needs unknown symbol pci_find_class modprobing the module when booted into the new kernel fails, with this error: FATAL: Error inserting nvidia (/lib/modules/2.6.16-gentoo/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg) dmesg says this: nvidia: Unknown symbol remap_page_range nvidia: Unknown symbol pci_find_class As far as I can tell, the driver is relying on these two symbols, but the new kernel has dropped support for them. This is going to become a problem when gentoo-sources-2.6.16 comes off ~arch, because the latest "stable" driver will no longer work with the latest "stable" kernel. Fot the full story of one man's fight against unsupported symbols, check my forum post here: http://forums.gentoo.org/viewtopic-p-3207570.html
Same problem to me.
Hi - I should just point out that I solved this problem on my own box by upgrading to the latest drivers - 1.0.8178 as of this date. I haven't checked where the "cutoff point" for compatibility lies, but from what I can tell this bug should always be reproducable, so if anybody feels the need to investigate it won't be too hard.
Same problem here. Upgrading to 8178 allows compile to finish, and xorg to load, but now all my opengl apps are REALLY slow. Seems like .16 and nvidia don't play together too nicely.
The other problem is that the new driver does not support old nvidia cards like my Geforce2. It seems I must stick with the kernel 2.6.15. :-(
Got the same problem from the newest driver, 8756 and kernel 2.6.16-gentoo-r1. However, only pci_find_class wasn't found. Downgrading to 8178 also solved the issue for me.
Hi, here you can find a patch to make 7174 (at less, i dont know if it works with other versions) to make it compile with 2.6.16. http://bhhdoa.org.au/pipermail/ck/2006-March/005649.html it could be good to add it in the ebuild.
and you can find another patch, completely different .. . i dont know why, there : http://www.nvnews.net/vbulletin/showthread.php?t=67068
*** Bug 130995 has been marked as a duplicate of this bug. ***
Created attachment 85288 [details] nvidia-bug-report.log Same here... I'm attaching nvidia error log
Yesterday, after an emerge --sync and emerge -u world, I have normally updated my kernel and it broke my installation because of this bug. Is it normal 2.6.16 became stable whereas there are some compatibility problems ?
I did raise an eyebrow when I saw 2.6.16 marked as stable. I guess the kernel herd haven't seen this bug... Try upgrading to nvidia*-7174 (and applying the patch if it's not already there).
<wolf31o2|work> jforman: can you test 7174 for me and post on the bug if it works? <jforman> yo <jforman> wolf31o2|work: yeah, give me a sec <jforman> wolf31o2|work: do i just have to keyword nvidia-kernel ~x86 ? <wolf31o2|work> 7174 was the last version that still had all of the legacy drivers in it <wolf31o2|work> nope... <wolf31o2|work> here: <wolf31o2|work> echo "~media-video/nvidia-kernel-1.0.7174 ~x86" >> /etc/portage/package.keywords <wolf31o2|work> echo "~media-video/nvidia-glx-1.0.7174 ~x86" >> /etc/portage/package.keywords <wolf31o2|work> that should be it * jforman upgrades and reboots <wolf31o2|work> you da man <jforman> heh good eye that you saw that bug <wolf31o2|work> well... I'm about to hit that bug on my LiveCD builds <wolf31o2|work> since I'm testing w/ 2.6.16 kernel <wolf31o2|work> heh <jforman> okay rebooting <jforman> jforman@vail ~ $ uname -a <jforman> Linux vail 2.6.16-gentoo-r3 #1 Wed Apr 26 09:52:18 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GNU/Linux <jforman> ship it <expletive deleted> <jforman> wolf31o2|work: that means you ^ <wolf31o2|work> it works? <jforman> who else would i be talking to ? ;) <wolf31o2|work> nice <wolf31o2|work> thanks Can I get some other people to test this, also? It should resolve the issue and still has support for the older legacy cards, so nobody will be losing their OpenGL support. =]
I have tried version 71xx and kernel 2.6.15-r7. It runs but it is very very unstable (it hangs very often). Because of my legacy card I can not use 8xxx. The version 6629 runs very stable but do not work with kernel 2.6.16. :-(
I agree : I've just installed : [I--] [ ] media-video/nvidia-glx-1.0.7174-r5 (0) [I--] [ ] media-video/nvidia-kernel-1.0.7174-r2 (0) with Geforce 2 Ti, 3D works well and 2D too. But after 2 hours, I got a Xorg freeze and I had to reboot my PC. So, I think 7174 drivers aren't as stable as 6629
Can you test it with a 2.6.16 kernel and see if it is still as unstable? Try perhaps 7167 instead? I'm having some serious issues with regard to Release Engineering with x86's drivers being so far behind. For example, only the *very latest* drivers even support the 7600GT, which happens to be what I own. The current stable doesn't support the integrated 6200/6250, or any of the 7xxx series. Why is it that amd64 can mark these newer versions stable and x86 cannot? If there's issues with the older drivers (but newer than 6629) then we really should work to get them resolved, rather than forcing ourselves to lose hardware support for all of the newer cards. At some point, we're just going to have to move on with the newer versions simply because of complete lack of support for many of these cards. I had simply hoped that Nvidia would have released some newer legacy drivers by now.
Second crash after 20 minutes. I confirm : 7174 drivers are absolutely unusable with old NVidia cards (in my case, GeForce 2 Ti)
nvidia-kernel-1.0.7167 doesn't compile with 2.6.16 : In file included from /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/os-interface.c:26: /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/nv-linux.h:233:5: warning :
nvidia-kernel-1.0.7167 doesn't compile with 2.6.16 : In file included from /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/os-interface.c:26: /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/nv-linux.h:233:5: warning : « NV_ENABLE_MEM_TRACKING » undefined /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/nv-linux.h:261:5: warning : « NV_ENABLE_MEM_TRACKING » undefined /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/nv-linux.h:683:2: warning : #warning "conftest.sh failed, assuming remap_page_range(4)!" /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/os-interface.c:667:5: warning : « DEBUG » undefined /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/os-interface.c:679:5: warning : « DEBUG » undefined /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/os-interface.c: In function `os_set_mlock_capability': /var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/os-interface.c:1260: error: structure has no "rlim" member make[3]: *** [/var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv/os-interface.o] Error 1 make[2]: *** [_module_/var/tmp/portage/nvidia-kernel-1.0.7167-r1/work/NVIDIA-Linux-x86-1.0-7167-pkg1/usr/src/nv] Error 2 NVIDIA: left KBUILD. nvidia.ko failed to build! make[1]: *** [module] Erreur 1 make: *** [module] Erreur 2 !!! ERROR: media-video/nvidia-kernel-1.0.7167-r1 failed. !!! Function linux-mod_src_compile, Line 512, Exitcode 2 !!! Unable to make IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/usr/src/linux clean module. !!! If you need support, post the topmost build error, NOT this status message.
So what were' at now: - 6629 doesn't compile on 2.6.16 or support newer cards - 7174 compiles for 2.6.16, but sucks on older cards, and doesn't support newer cards - 8756 compiles for 2.6.16, but doesn't support older cards Well, it looks like the answer here is to perform 2 steps: #1. Fix 6629 to compile with 2.6.16 #2. Mark 8756 stable for people with newer cards I would definitely say that we would need to preclude the stable marking of 8756 with a nice note in the GWN and on the forums. See, we're about to hit another problem shortly as xorg-server 7.1 won't work with *any* of these older drivers (including 8756) as it has an ABI change in the driver interface. Essentially, all of you users with older cards that are not supported in >7174 are about to be left out in the cold by Nvidia, since it doesn't seem like they're going to be releasing a newer legacy driver set any time soon. Unfortunately, I have no ties to anyone within Nvidia. I'm going to try to find out what I can, but if any of you know of a good way to find out what the plans are for xorg-server 7.1 compatibility for legacy users, I'd love to hear what you find out.
I tried 1.0.8178 from NVIDIA on my GeForce FX 5200 and Panasonic PT-AE700E projector and it doesn't detect the resolutions properly - even with "IgnoreEDIDFreqs" "FALSE" and other options in xorg.conf. This is so important that I have downgraded to kernel 2.6.15. This is not a great loss for most people, but how do we go forward from here?
For what its worth, I have been using nvidia-driver-1.0-8756 and nvidia-glx-1.0.8756 with 2.6.16-r3 and nvidia GeForce4 440 Go GPU for past few days without any issues.
Well, it helps if you dont' remove everybody from CC... ;] I've been running 8756 on 2.6.16-r3 on 3 machines now and had exactly 0 issues with it. Of course, one of the machines *requires* that I use 8756, since it is a 7600GT.
Using nvidia-kernel and nvidia-glx-1.0.8756 with gentoo-sources-2.6.16-r7 and it works, but I got this in dmesg: NVRM: loading NVIDIA Linux x86 Kernel Module 1.0-8756 Wed Mar 29 14:26:26 PST 2006 NVRM: This version of the Linux kernel does not provide the vmap() NVRM: kernel interface. If you see this message, please update NVRM: your kernel to Linux 2.4.22 or install a distribution kernel NVRM: that supports the vmap() kernel interface. It wasn't easy to get it work though. With kernel 2.6.16-r4 it complained during emerge nvidia-kernel about missing symbols, but modprobe went fine. -r5, -r6 didn't complain but modprobe failed because of missing symbols. Same happened with 2.6.16-r7, but after several emerges of nvidia-kernel it suddenly started to work. I don't understand why.
For people who can't compile the nvidia-kernel: The nvidia drivers require PCI hotplug support (Bus Options -> PCI Hotplug Support -> Support for PCI Hotplug) to be compiled into the kernel. Check to make sure you have that compiled into your kernel. If not, recompile your kernel and then try to reemerge the nvidia-kernel ebuild.
> The nvidia drivers require PCI hotplug support I take it this is solely for laptops? My (desktop's) kernel has never had that and the drivers work fine for me.
I think it depends on your platform. I was installing gentoo with the AMD64 arch recently and the nvidia kernel simply wouldn't emerge. I'm also using an old Geforce 256 card on the system so I had to stick with anything <= 7174 drivers but none of them would compile (emerge). I found a website somewhere that mentioned pci hotplug support had to be enabled in the kernel for them to compile. So I enabled it and recompiled the kernel and then I reemerge the nvidia-kernel ebuild and it worked. So this might only apply to the AMD64 arch but I suppose it's worth a try on other arches?
I think it depends on your platform. I was installing gentoo with the AMD64 arch recently and the nvidia kernel simply wouldn't emerge. I'm also using an old Geforce 256 card on the system so I had to stick with anything <= 7174 drivers but none of them would compile (emerge). I found a website somewhere that mentioned pci hotplug support had to be enabled in the kernel for them to compile. So I enabled it and recompiled the kernel and then I reemerged the nvidia-kernel ebuild and it worked. So this might only apply to the AMD64 arch but I suppose it's worth a try on other arches?
(In reply to comment #26) > So this might only apply to the AMD64 arch I'll try to remember that next time I'm brave enough to stick my toe in AMD64 waters again :)
$ zcat /proc/config.gz | grep HOTPLUG CONFIG_HOTPLUG=y # CONFIG_HOTPLUG_PCI is not set This is my 100% working laptop. $ zcat /proc/config.gz | grep HOTPLUG CONFIG_HOTPLUG=y # CONFIG_HOTPLUG_CPU is not set # CONFIG_HOTPLUG_PCI is not set This is my 100% working AMD64 desktop. Now, both of thse are using newer cards. I'll look and see if possibly I can do something to make the 6629 drivers work with the newer kernels, such as trying enabling PCI hotplug. I'll let you guys know.
# grep -R remap_page_range * arch/i386/mm/ioremap.c:static int ioremap_page_range(unsigned long addr, arch/i386/mm/ioremap.c: if (ioremap_page_range((unsigned long) addr, drivers/video/sun3fb.c:#include <asm/pgtable.h> /* io_remap_page_range() */ sound/oss/maestro3.c: * revert to lame remap_page_range mmap() just to make it work # grep -R pci_find_class * drivers/video/sis/sis.h:#define SIS_PCI_GET_CLASS(a, b) pci_find_class(a, b) I just don't see how PCI hotplug could make a bit of difference here.
I must have had a brain fart. I thought I was using the 2.6.16 gentoo sources kernel when I was actually using the 2.6.15-r7 amd64 kernel. Here's what I get when I tried to emerge nvidia-kernel under 2.6.16-r7 (with PCI hotplug enabled): NVIDIA: calling KBUILD... make CC=x86_64-pc-linux-gnu-gcc KBUILD_VERBOSE=1 -C /usr/src/linux M=/var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv modules make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. mkdir -p /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/.tmp_versions make -f scripts/Makefile.build obj=/var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv echo \#define NV_COMPILER \"`x86_64-pc-linux-gnu-gcc -v 2>&1 | tail -n 1`\" > /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv_compiler.h x86_64-pc-linux-gnu-gcc -Wp,-MD,/var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/.nv.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -Os -fomit-frame-pointer -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wdeclaration-after-statement -I/var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat -Wchar-subscripts -Wparentheses -Wno-multichar -Werror -O -fno-common -mno-red-zone -MD -Wsign-compare -Wno-cast-qual -Wno-error -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE -mcmodel=kernel -DNTRM -D_GNU_SOURCE -D_LOOSE_KERNEL_NAMES -D__KERNEL__ -DMODULE -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=7174 -DNV_UNIX -DNV_LINUX -DNV_INT64_OK -DNVCPU_X86_64 -DNV_64_BITS -UDEBUG -U_DEBUG -DNDEBUG -DNV_SIGNAL_STRUCT_RLIM -DNV_MULTIPLE_BRIDGE_AGPGART_PRESENT -DNV_REMAP_PFN_RANGE_PRESENT -DNV_CHANGE_PAGE_ATTR_PRESENT -DNV_PCI_DISABLE_DEVICE_PRESENT -DNV_PCI_GET_CLASS_PRESENT -DNV_VMAP_4_PRESENT -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(nv)" -D"KBUILD_MODNAME=KBUILD_STR(nvidia)" -c -o /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.o /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c In file included from include/linux/sched.h:15, from include/linux/module.h:10, from /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:46, from /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:14: include/linux/cpumask.h: In function `__first_cpu': include/linux/cpumask.h:218: warning: signed and unsigned type in conditional expression include/linux/cpumask.h: In function `__next_cpu': include/linux/cpumask.h:224: warning: signed and unsigned type in conditional expression In file included from include/linux/sched.h:17, from include/linux/module.h:10, from /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:46, from /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:14: include/linux/nodemask.h: In function `__first_node': include/linux/nodemask.h:229: warning: signed and unsigned type in conditional expression include/linux/nodemask.h: In function `__next_node': include/linux/nodemask.h:235: warning: signed and unsigned type in conditional expression include/linux/nodemask.h: In function `__first_unset_node': include/linux/nodemask.h:253: warning: signed and unsigned type in conditional expression In file included from /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:14: /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:240:5: warning: "NV_ENABLE_MEM_TRACKING" is not defined /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:268:5: warning: "NV_ENABLE_MEM_TRACKING" is not defined In file included from /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:14: /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h: In function `NV_SET_PAGE_ATTRIB_UNCACHED': /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:1053: error: `mem_map' undeclared (first use in this function) /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:1053: error: (Each undeclared identifier is reported only once /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:1053: error: for each function it appears in.) /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h: In function `NV_SET_PAGE_ATTRIB_CACHED': /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:1062: error: `mem_map' undeclared (first use in this function) /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h: In function `NV_UNLOCK_PAGE': /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:1089: error: `mem_map' undeclared (first use in this function) /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h: In function `nv_sg_map_buffer': /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv-linux.h:1128: error: `mem_map' undeclared (first use in this function) /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c: At top level: /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:206: warning: initialization from incompatible pointer type /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:231:5: warning: "NV_ENABLE_MEM_TRACKING" is not defined /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:1189:5: warning: "NV_ENABLE_MEM_TRACKING" is not defined /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c: In function `nv_kern_vma_nopage': /var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.c:1277: error: `mem_map' undeclared (first use in this function) make[3]: *** [/var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv/nv.o] Error 1 make[2]: *** [_module_/var/tmp/portage/nvidia-kernel-1.0.7174-r2/work/NVIDIA-Linux-x86_64-1.0-7174-pkg2/usr/src/nv] Error 2 NVIDIA: left KBUILD. nvidia.ko failed to build! make[1]: *** [module] Error 1 make: *** [module] Error 2 !!! ERROR: media-video/nvidia-kernel-1.0.7174-r2 failed. !!! Function linux-mod_src_compile, Line 515, Exitcode 2 !!! Unable to make IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/usr/src/linux clean module. !!! If you need support, post the topmost build error, NOT this status message.
It seems this problem has been solved with the 7174 drivers. Check out this link: http://www.nvnews.net/vbulletin/showthread.php?t=67068 Nvidia even says they will be releasing new legacy drivers at some point to deal with the problem. In the mean time, there is a howto to fix it right now at that link.
Created attachment 86866 [details, diff] Unofficial patch that can be applied to the nvidia's drivers to make it compile
Right, but quite a few people here have mentioned that 7174 is unstable for them.
Unstable? It runs fine for me under 2.6.15-r7. I didn't experience any crashes. It was pretty fast too. According to Zhenech on that page, the driver seems to be working and stable on Debian so why not on Gentoo?
At the very least try the patch and test it out. If it compiles and is stable for a few people, it's better than nothing. Incidently, we're both using amd64 arches. What is everyone else using? Perhaps it's fine on AMD64 but buggy on x86?
(In reply to comment #35) > What is everyone else using? Perhaps it's fine on AMD64 but buggy on x86? Yup, I'm on x86.
Stability issues could arise from other things like via chipsets, albeit, my board uses via chipsets (newer ones): 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02) 00:0a.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) 00:0d.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 00:0d.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) 00:0d.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV10DDR [GeForce 256 DDR] (rev 10)
For me 7xxx series is unstable and I own also a via chipset (an older one ;-)): chl ~ # lspci | grep -i via 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 22) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 09) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 02) 00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management
7xxx series is unstable with mi via chipset : 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1b) 00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1b) 00:11.4 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1b) but I used these options with the 6629 driver : Option "RenderAccel" "TRUE" Option "NoLogo" Option "DPMS" Option "NvAGP" "3" Option "DigitalVibrance" "1"
What options are you guys using in /etc/modules.d/nvidia? Any? Also, do you get the same problems using both NvAGP and AGPGART?
I only have 2 options set in /etc/modules.d/nvidia: alias char-major-195 nvidia alias /dev/nvidiactl char-major-195
Yup, I've got the same: alias char-major-195 nvidia alias /dev/nvidiactl char-major-195 Plus a load of commented out stuff. I use kernel GART because I hear it's better (more stable or something). My motherboard is based on an nForce3 250Gb chipset. (I have an Athlon64, but I run x86 because it works better.)
I also use the kernel agpgart. I also leave all the default options in xorg.conf except for setting the NoLogo option.
Well this is interesting. I was just testing kernel 2.6.16-gentoo-r3 on my x86 machine and the nvidia-kernel-1.0.7174-r2 compiled fine. I haven't tested it in X yet, so I'll see how stable it is in there. So what's with the AMD64 arch that it doesn't compile at all?
To update my previous post, after removing all xorg.conf options and no options for the kernel, nvidia-kernel-1.0.7174-r2 is now stable with GeForce 2 Ti + x86 and can be used with 2.6.16 kernel.
Using the above patch or by itself?
With my x86 system, I did not use the patch on nvnews.net. The r2 version compiles without any extra patching. On my AMD64 system, I tried to emerge r2 and it did not compile with the error I posted above. I also tried creating an ebuild in my portage overlay with the nvnews.net patch. It patched properly but had no effect; it still did not compile on AMD64. Is there something you can do to get it to compile on AMD64?
I'd say you could probably set the x86 version of the 7174 driver to stable in portage as it sounds to me like the people who have stability issues are not using the default options for the module or xorg. I can also say that I tested 7174-r2 on my x86 box in X and I did not experience any stability issues (i.e. lockups). I use all the default settings on the module and xorg except for the NoLogo option in xorg.conf.
So, I read it's bug #113466 time again, but now for vanilla-sources-2.6.16.16. nvidia-kernel-1.0.6629-r5 compiles fine but again, doesn't work. I thought nvidia-kernel-1.0.6629-r5 was the latest version supporting GeForce2 Pro. What about nvidia-kernel-1.0.7174-r2? If it is supporting GeForce2 Ti, is it supporting the other GeForce2 cards like GeForce2 Pro too?
7174 was the last to support the "legacy" drivers. Yes, it supports your card.
I just upgraded from vanilla-sources-2.6.15.1 to vanilla-sources-2.6.16.16 (both marked as stable x86) and I hit this bug. Both kernels are using nvidia-kernel-1.0.6629-r5 (marked as stable x86). I have a GeForceFX 5500. In response to comment 40, I come across this bug with either agpgart or nvAGP. Why was this bug overlooked when considering 2.6.16.16 to be marked stable? I don't want to try upgrading to a non-stable version of nvidia-kernel, so my solution for now will be to add 2.6.16.16 to packages.mask and going back to 2.6.15.1 :-)
(In reply to comment #51) > Why was this bug overlooked when considering 2.6.16.16 to be marked stable? #1. It was never marked as a blocker for any of the 2.6.16 stabilization bugs #2. It isn't the architecture team's reponsibility to make sure that every package compiles against a newer kernel. It is each individual package maintainer's job to ensure their package doesn't get broken once the "we're going to stabilize $blah" messages get sent out *weeks* before it gets stabilized. ;] Anyway, I'm trying to help resolve this, even though I am neither a kernel maintainer, nor the nvidia-* maintainer, so please, if you don't have anything constructive to add to help me help you, then don't comment, at all. If you really want to actually *help* the situation, then try 7174, instead of bitching and giving no real benefit to this bug. Unless I get some objections from the package maintainers, or unless NVIDIA releases the updated legacy drivers before we get this cleaned up, I plan on taking some version of 7174 to stable on x86, along with 8756 (or possibly 8762). This means that users will be responsible for ensuring that their cards are supported on x86, just as they are on amd64. I also plan on trying to fix the compilation issues (if any) with 7174 on amd64. Basically, we need 7174 working on both architectures, and building against 2.6.16 kernels. We also need 87* working on both, as many newer cards are simply not supported by the older drivers, and we cannot keep going with the current situation of users with newer hardware being 100% unsupported on stable systems on either architecture. This *will* be resolved by 2006.1's release, which is exactly why I am working on this bug.
It sounds like Nvidia is about to maintain two code bases; current and legacy. Can we add a nvidia-legacy-kernel and nvidia-legacy-glx ebuild which are based on 7174 and future "legacy" code bases?
That was pretty much the idea, but we have to firts make sure that 7174 works for everyone. So, if you have any NVIDIA card and are willing to help out, please test 7174 (latest revision) and 2.6.16 kernels and report back. I'm basically trying to get together all of the information and have all of the leg work done for augustus to make his job as simple as possible. =]
@Chris: Here's my report! I have a GeForce4Ti4200 on an Athlon-Thunderbird System. emerged nvidia-kernel-1.0.7174-r2 nvidia-glx-1.0.7174-r5 Sucessfully tested apps: IceWM desktop + games: bzadmin, foobillard, glaxium, trackballs. Only Flightgear made problems: Ran fine in windowed mode, but app hung in fullscreen mode. In the last stable NVIDIA/linuxkernel-combination, this was not the case. Can anyone please verify?
As requested, here is my report: Kernel: 2.6.16-gentoo-r8 Driver: nvidia-kernel-1.0.7174-r2; nvidia-glx-1.0.7174-r5 Video card: 01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro] (rev a4) DE: Xfce4 So far, no problems running this combination. I couldn't really tell if things are running faster or slower than before. I tried to stress out my system by running an emerge -e world and opening a bunch of programs (eclipse, xine, oowriter, rythmbox, etc) and things remained stable.
This combination works on my toshiba satellite VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go] (rev a3) System uname: 2.6.16-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz driver: nvidia-kernel-1.0.7174-r2; nvidia-glx-1.0.7174-r5 (In reply to comment #54)
Here another answer to comment #54: I have a GeForce2 Pro and the next combination seems to work fine too. If any problems arise in the upcoming days, I will report them too... # uname -rmpo ; lspci |grep -i nvidia.*geforce ; emerge -pv nvidia-kernel nvidia-glx |grep ebuild 2.6.16.16 i686 AMD Athlon(tm) XP 2600+ GNU/Linux 02:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro] (rev a4) [ebuild R ] media-video/nvidia-kernel-1.0.7174-r2 0 kB [ebuild R ] media-video/nvidia-glx-1.0.7174-r5 0 kB
I was using nvidia-glx and nvidia-kernel-1.0.8762, for my GeForce 6600GT, which was working fine until I upgraded my kernel from 2.6.16-gentoo-r7 to -r9
Aniruddha, please file a bug for your problem, as it doesn't belong here. Thanks, --wolf31o2
(In reply to comment #52) > Anyway, I'm trying to help resolve this, even though I am neither a kernel > maintainer, nor the nvidia-* maintainer, so please, if you don't have anything > constructive to add to help me help you, then don't comment, at all. If you > really want to actually *help* the situation, then try 7174, instead of > bitching and giving no real benefit to this bug. > > Unless I get some objections from the package maintainers, or unless NVIDIA > releases the updated legacy drivers before we get this cleaned up, I plan on > taking some version of 7174 to stable on x86, along with 8756 (or possibly > 8762). This means that users will be responsible for ensuring that their cards > are supported on x86, just as they are on amd64. I also plan on trying to fix > the compilation issues (if any) with 7174 on amd64. > > Basically, we need 7174 working on both architectures, and building against > 2.6.16 kernels. We also need 87* working on both, as many newer cards are > simply not supported by the older drivers, and we cannot keep going with the > current situation of users with newer hardware being 100% unsupported on stable > systems on either architecture. Hi Chris, thank you for your interest in getting this fixed. It really was a showstopper for us legacy video card owners. Here's my contribution: I have an nVidia GeForce2 Ti and I gave the recommended solutions a shot. Everything worked straight out-of-the-box. lspci says: 01:00.0 VGA compatible controller: nVidia Corporation NV15DDR [GeForce2 Ti] (rev a4) portage says: [ebuild R ] sys-kernel/gentoo-sources-2.6.16-r9 [ebuild R ] media-video/nvidia-kernel-1.0.7174-r2 [ebuild R ] media-video/nvidia-glx-1.0.7174-r5 No stability problems at all so far. Will reply here if I notice anything.
(In reply to comment #61) > (In reply to comment #52) > > Anyway, I'm trying to help resolve this, even though I am neither a kernel > > maintainer, nor the nvidia-* maintainer, so please, if you don't have anything > > constructive to add to help me help you, then don't comment, at all. If you > > really want to actually *help* the situation, then try 7174, instead of > > bitching and giving no real benefit to this bug. > > > > Unless I get some objections from the package maintainers, or unless NVIDIA > > releases the updated legacy drivers before we get this cleaned up, I plan on > > taking some version of 7174 to stable on x86, along with 8756 (or possibly > > 8762). This means that users will be responsible for ensuring that their cards > > are supported on x86, just as they are on amd64. I also plan on trying to fix > > the compilation issues (if any) with 7174 on amd64. > > > > Basically, we need 7174 working on both architectures, and building against > > 2.6.16 kernels. We also need 87* working on both, as many newer cards are > > simply not supported by the older drivers, and we cannot keep going with the > > current situation of users with newer hardware being 100% unsupported on stable > > systems on either architecture. > > Hi Chris, thank you for your interest in getting this fixed. It really was a > showstopper for us legacy video card owners. Here's my contribution: > I have an nVidia GeForce2 Ti and I gave the recommended solutions a shot. > Everything worked straight out-of-the-box. > > lspci says: > 01:00.0 VGA compatible controller: nVidia Corporation NV15DDR [GeForce2 Ti] > (rev a4) > > portage says: > [ebuild R ] sys-kernel/gentoo-sources-2.6.16-r9 > [ebuild R ] media-video/nvidia-kernel-1.0.7174-r2 > [ebuild R ] media-video/nvidia-glx-1.0.7174-r5 > > No stability problems at all so far. Will reply here if I notice anything. > This should be the case assuming you are using the x86 arch. nvidia-kernel-1.0.7174-r2 does not compile at all on the AMD64 arch.
> This should be the case assuming you are using the x86 arch. > nvidia-kernel-1.0.7174-r2 does not compile at all on the AMD64 arch. Yes, I forgot to mention that i'm using x86. I'm getting a few issues in KDE with this new driver, though. Not performance or stabily related, at least that I could notice, but it seems that there are cases where the image gets corrupted. For instance, suppose I have 2 tabs openned in konqueror - one is a webpage, the other one is an embedded application, such as KDE's ShowImg image viewer. If I switch beteween tabs konqueror will mess the screen, by placing the image in tab2 on top of the webpage in tab1. I can provide a screenshot (supposing there are ways to capture this problem) upon request. Surprisingly, this is the only issue I've come across after roughly 3 hours of testing. Glxgears looks good, video output within applications such as Kaffeine works wonderfully, embedded pdf viewers in konqueror tabs also work fine, and any GUI-based application that is called from Konsole can properly open a window in Xorg (such as mplayer).
(In reply to comment #63) > Yes, I forgot to mention that i'm using x86. > > I'm getting a few issues in KDE with this new driver, though. Not performance > or stabily related, at least that I could notice, but it seems that there are > cases where the image gets corrupted. For instance, suppose I have 2 tabs > openned in konqueror - one is a webpage, the other one is an embedded > application, such as KDE's ShowImg image viewer. If I switch beteween tabs > konqueror will mess the screen, by placing the image in tab2 on top of the > webpage in tab1. I can provide a screenshot (supposing there are ways to > capture this problem) upon request. Surprisingly, this is the only issue I've > come across after roughly 3 hours of testing. Glxgears looks good, video output > within applications such as Kaffeine works wonderfully, embedded pdf viewers > in konqueror tabs also work fine, and any GUI-based application that is called > from Konsole can properly open a window in Xorg (such as mplayer). > Are you using all the default parameters for xorg and the nvidia module? Refer to Fr
(In reply to comment #63) > Yes, I forgot to mention that i'm using x86. > > I'm getting a few issues in KDE with this new driver, though. Not performance > or stabily related, at least that I could notice, but it seems that there are > cases where the image gets corrupted. For instance, suppose I have 2 tabs > openned in konqueror - one is a webpage, the other one is an embedded > application, such as KDE's ShowImg image viewer. If I switch beteween tabs > konqueror will mess the screen, by placing the image in tab2 on top of the > webpage in tab1. I can provide a screenshot (supposing there are ways to > capture this problem) upon request. Surprisingly, this is the only issue I've > come across after roughly 3 hours of testing. Glxgears looks good, video output > within applications such as Kaffeine works wonderfully, embedded pdf viewers > in konqueror tabs also work fine, and any GUI-based application that is called > from Konsole can properly open a window in Xorg (such as mplayer). > Are you using all the default parameters for xorg and the nvidia module? Refer to Frédéric's posts as he uses a Geforce 2 Ti as well.
*** Bug 136131 has been marked as a duplicate of this bug. ***
(In reply to comment #54) Working fine for two days now. 2.6.16-ck11 i686 AMD Athlon(tm) XP 3000+ GNU/Linux pci.product = 'NV20 [GeForce3 Ti 200]' [ebuild R ] media-video/nvidia-kernel-1.0.7174-r2 0 kB [ebuild R ] media-video/nvidia-glx-1.0.7174-r5 0 kB
Just as a note, for people who are testing make sure you don't have RenderAccel set in your xorg.conf file or at least set it to false: Option "RenderAccel" "False" There seems to be a long standing bug in nvidia's drivers that creates problems when that option is set: http://bugs.gentoo.org/show_bug.cgi?id=113123
(In reply to comment #62) > > This should be the case assuming you are using the x86 arch. > nvidia-kernel-1.0.7174-r2 does not compile at all on the AMD64 arch. > Just a quick reply to let you know I haven't had any problems since 2006-06-07, and I'm unable to reproduce the problem I experienced before. It must've been Konqueror's or ShowImg's fault, not nvidia-kernel. Everything is perfectly stable.
(In reply to #68) I'm using media-video/nvidia-kernel-1.0.7174-r2 for several weeks now without any further problems on my GeForce4 Ti 4200. However, there is one application that still does not work with the new driver, while it worked perfectly with 6629: FlightGear Flight Simulator in Fullscreen-Mode. Could perhaps anyone be so nice and verify this on his/her system? In order to do that, first emerge -av games-simulation/flightgear and then try running /usr/games/bin/fgfs --enable-fullscreen For me, this 1.) Takes bloody ages to start up 2.) Does not run actually full-screen but rather in a (maximized) window 3.) Seems to have Hardware-Acceleration disabled without any apparent reason. I have played the very same game with the very same settings before using 6629, and did not encounter any of those problems. As long as this issue remains, I would advise 2.6.16+ Users to use the new driver (because it is still better than the non-working 6629 driver), but would not dare to flag it as "stable".
I'm now wondering that if the AMD64 driver actually does get fixed and compiles, is it going to work on kernel 2.6.17 as well?
That is actually what I am trying to find out. I am trying to figure out exactly what needs to be done to get 7174 working on amd64 and also to ensure it stays working with 2.6.17... any information with regards to these are definitely appreciated, as I'm having a difficult time finding any useful information.
(In reply to comment #71) > That is actually what I am trying to find out. I am trying to figure out > exactly what needs to be done to get 7174 working on amd64 and also to ensure > it stays working with 2.6.17... any information with regards to these are > definitely appreciated, as I'm having a difficult time finding any useful > information. > I've been looking all over the place and hounding nvidia for a patch for >=2.6.16 on nvnews.net but nvidia's version of fixing this any time soon seems like never. It's driving me nuts because the driver for my HDTV tuner card is still buggy on AMD64 and I need to use the latest kernel to see if they've fixed the problems. Being that nvidia drivers are closed source and nvidia doesn't care to fix the legacy driver any time soon, I'm surprised anyone could find out a way to fix this problem.
Holy crap! Nvidia just released a new legacy driver for x86 and AMD64!! :-) Latest Legacy GPU version: 1.0-7182 http://www.nvidia.com/object/unix.html
I filed bug 138359 to request a new ebuild for the new legacy driver.
Yeah... that wasn't necessary... :P We're already working on it. Thanks for the bug report, though. The newer legacy drivers should be in the tree in the next couple days.
(In reply to comment #75) > Yeah... that wasn't necessary... :P > > We're already working on it. Thanks for the bug report, though. The newer > legacy drivers should be in the tree in the next couple days. > We're all looking forward to it. :-)
About stability, I experience crashes about once a week. For the last crash I have some crash information which points to media-video/nvidia-kernel-1.0.7174-r2 as the cause of the crash, see bug #138366. This makes me suspect media-video/nvidia-kernel-1.0.7174-r2 as the cause of the other crashes too.
Everyone here please try x11-drivers/nvidia-legacy-drivers or x11-drivers/nvidia-drivers, as these two will be replacing the current nvidia-kernel/nvidia-glx combo.
With Geforce 2 Ti, 2D works well and 3D too with very good performance ! x11-drivers/nvidia-legacy-drivers-1.0.7182 Tested with : blender-2.41 ppracer-0.3.1 ut-2003 cube-20050829 Orbz (commercial game) glxgears
I think this bug is now irrelevant with the new driver and should probably be closed. Everything works fine and compiles fine for me on the AMD64 arch. I'm even using 2.6.17 kernel without any issues as well.
Agreed. I should just point out that there's a new bug (139500) which is related to this - but that's happy where it is, I think.
How about we dupe on that one, then... so everyone knows... *** This bug has been marked as a duplicate of 139500 ***
I don't feel the bug is really solved.. As far as I know, there is currently no stable nvidia drivers which work with the current stable kernel. I thought this was the original issue with this bug.
I'm using the new 7182 nvidia-legacy-drivers ebuild and I don't have any problems with it. The original issue with this bug is that 6629 wouldn't compile or work with 2.6.16 and to solve that issue, you needed to upgrade to the newest legacy drivers. A patched 7174 worked on x86 and the new 7182 driver nvidia released works on everything and as far as I can tell, it is stable even though it hasn't been marked as such yet.
I am also using an unstable driver without any problem, but the bug was mostly for stable users and if one is upgrading kernel today, he will have the problem so this is not resolved and with a closed bug, the fix will be harder to find.
No, Jules is right. If you read the description I originally wrote, you'll see that I expressed concern over breakage for old card users on +arch systems - as of now, the latest +arch packages are nvidia-*-6629 and gentoo-sources-2.6.16 - which still don't work together. All that needs to happen is for the nvidia-legacy-drivers to be marked stable, and everything'll work just like it did before 2.6.16 came along with its API change and caused this bug in the first place.
It *will* be marked stable. It just needs to sit for a bit. You can help by using it, and noting how it works on bug #138358 instead.
I think technically it would be most accurate if this bug stayed open until the new legacy-driver is stable. Bug 139500 and bug 138358 could be (solved) blockers of this, and stabilisation could be tracked here, on bug 138358 or another new blocker... But maybe I'm wrong, just my 2c :)
I just had another X crash. Keyboard/mouse didn't do anything anymore, the capslock led on the keyboard didn't even react when pressing capslock. I had to do a remote login where top showed me the X process took over 99% cpu usage! A normal kill didn't work out so a kill -9 was needed and the system was usable again. sys-kernel/vanilla-sources-2.6.16.19 media-video/nvidia-kernel-1.0.7174-r2 VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro] (rev a4) I agree with Jules too: I don't feel the bug is really solved!
Do you use any option in /etc/X11/xorg.conf about the NVidia driver (like RenderAccel) or kernel driver ? Could you try with the new legacy driver : x11-drivers/nvidia-legacy-drivers-1.0.7182 instead of previous nvidia-glx and nvidia-kernel ebuilds ?
In line with the general concensus, I've reopened this bug. It should be closed again when the latest +arch nvidia drivers (current and legacy) are compatible with the latest +arch gentoo-sources.
*** Bug 140423 has been marked as a duplicate of this bug. ***
I'm using nvidia-legacy-drivers-1.0.7182 on x86 and everything is fine and worked out-of-the-box.
You should report your test results on bug 140922 or bug 140923.
With nvidia-drivers and nvidia-legacy-drivers stable, can we close this one now?
I'm using 7184 on AMD64 and I haven't noticed any stability problems.
Since nvidia-drivers/nvidia-legacy-drivers are in the tree now and stable, marking this one as FIXED.
