Some changes in the kernel (described at nvnews) prevents nvidia-drivers to get compiled against recent kernels, patch included at nvnews. Reproducible: Always Steps to Reproduce: 1.emerge -1 nvidia-drivers 2. 3. Actual Results: Fails Patch is included at http://www.nvnews.net/vbulletin/showthread.php?t=95296
Kindly post some errors, this is completely useless for any search.
Created attachment 125915 [details] Failed merge output Output. This started ~git(12|13). I can only presume it was due to the merge of Xen.
Created attachment 125959 [details, diff] Adapts the nVidia-Kernel-Code to the latest Kernel interface changes. The SLAB interface changed so that kmem_cache_create no longer has a parameter for a destructor. Second, unregister_chrdev() now returns a void instead of an int, so the compiler complains about a wrong test; void can't be negative. The attached patch fixes the problems in the nVidia-Kernel-code of the 100.14.11-driver. You have to change the ebuild to apply the patch.
When 2.6.23 is final, we'll consider this. Until then, you'll have to patch on your own. Unreleased kernels are not supported.
Most likely you won't have to change anything. It's nVidia's job to make their code compile on (released) kernels. So, probably we can relax and expect nVidia to resolve the issue for us (...and patch on our own until the kernel is released).
I am confirming that Felix Wenk's patch dated 2007-07-25 08:45 0000 works successfully against 2.6.23-r1 (vanilla) on amd64. I had to turn off the sandbox mode to get around http://bugs.gentoo.org/show_bug.cgi?id=135745 But otherwise it was straightforward.
Upstream forum post on this matter: http://www.nvnews.net/vbulletin/showthread.php?t=95296
The issue with this patch as well is that it's unconditional. So once this patch is applied, nvidia-drivers only works with 2.6.23. Which is still unreleased and not finalized.
Created attachment 126231 [details] nvidia-drivers-100.14.11-r1.ebuild (fixes compile issues on 2.6.23 kernel) This new ebuild allows nvidia-drivers-100.14.11-r1 to apply the required patch only for kernels 2.6.23 or higher. This ebuild will still be backwards compatible with older kernel versions (<=2.6.22).
Created attachment 126233 [details, diff] nvidia-drivers_ebuild_100.14.11_to_100.14.11-r1.patch Diff of changes between nvidia-drivers ebuilds 100.14.11 and 100.14.11-r1
(In reply to comment #8) > The issue with this patch as well is that it's unconditional. So once this > patch is applied, nvidia-drivers only works with 2.6.23. Which is still > unreleased and not finalized. > I've attached a new ebuild which only applies the patch if the kernel version is detected as 2.6.23 or greater. Therefore the new ebuild is still backwards compatible with 2.6.22 and previous kernels.
Patching in the ebuild is not proper. The proper fix is in the code itself. Like nVidia said, they'll address this when 2.6.23 is released.
Created attachment 126674 [details, diff] Patch to the source for the eager For those who need to use 2.6.23 series kernels, here's a patch to the source that you can add to the ebuild.
*** Bug 188604 has been marked as a duplicate of this bug. ***
*** Bug 191133 has been marked as a duplicate of this bug. ***
The return type of kmem_cache_create() is struct kmem_cache * now. You might want to add this to your pretty ifdefs: --- a/usr/src/nv/nv-linux.h +++ b/usr/src/nv/nv-linux.h @@ -552,7 +552,7 @@ static inline unsigned long nv_virt_to_p kmem_cache_free(kmem_cache, ptr); \ } -extern void *nv_stack_t_cache; +extern struct kmem_cache *nv_stack_t_cache; #if (defined(NVCPU_X86) || defined(NVCPU_X86_64)) && !defined(DEBUG) #define NV_KMEM_CACHE_ALLOC_STACK(ptr) \ --- a/usr/src/nv/nv.c +++ b/usr/src/nv/nv.c @@ -111,8 +111,8 @@ int nv_use_cpa = 1; static int nv_mmconfig_failure_detected = 0; -static void *nv_pte_t_cache = NULL; -void *nv_stack_t_cache = NULL; +static struct kmem_cache *nv_pte_t_cache = NULL; +struct kmem_cache *nv_stack_t_cache = NULL; static nv_stack_t *__nv_init_sp = NULL; // allow an easy way to convert all debug printfs related to events
This bug was fixed upstream in nvidia-drivers-100.14.19 (which is already in the portage tree). Tested against 2.6.23-rc6 (vanilla). This ticket can be closed now.
use 100.14.19
Reopening as this is broken in the stable tree.. I'm now working towards 2.6.23 stabling in 2 weeks time, so this stuff should ideally be fixed in stable if possible.
*** Bug 198226 has been marked as a duplicate of this bug. ***
This bug will never be solved if amd64 people, the only arch in which nvidia-drivers-100.14.19 is unstable, is not in CC list.
on amd64: i'm using x11-drivers/nvidia-drivers-100.14.19 USE="acpi gtk (-multilib)" for more than a month now with a GeForce 8600 GT and it seems to work quite well. Portage 2.1.3.19 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r8 x86_64) ================================================================= System uname: 2.6.22-gentoo-r8 x86_64 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz Timestamp of tree: Sun, 11 Nov 2007 09:46:01 +0000 app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=nocona -O2 -pipe" DISTDIR="/var/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.ynet.sk/pub" LC_ALL="en_US.utf8" LINGUAS="en de" MAKEOPTS="-j3" PKGDIR="/var/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage/repos/gentoo" PORTDIR_OVERLAY="/var/portage/repos/private" SYNC="rsync://192.168.0.1/gentoo-portage" USE="3dnow 3dnowext X a52 aac acpi alsa amd64 beagle berkdb bitmap-fonts bzip2 cairo caps cddb cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode evo exif fam ffmpeg firefox flac fortran gd gdbm gif gimp gnome gphoto2 gpm gstreamer gtk hal hddtemp iconv icu ipod ipv6 isdnlog java jpeg jpeg2k lcms ldap libnotify lm_sensors mad matroska midi mikmod mmap mmx mmxext mono mp3 mpeg mudflap musicbrainz ncurses nls nptl nptlonly nvidia ogg opengl openmp pam pcre pdf perl plotutils png pppd python qt3support quicktime readline reflection ruby sdl session spell spl sse sse2 ssl ssse3 svg tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts unicode usb vcd vim-syntax vorbis xattr xml xorg xv xvid zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" CAMERAS="canon konica ptp2 kodak" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LINGUAS="en de" USERLAND="GNU" VIDEO_CARDS="nvidia nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
amd64 stable
These drivers cause video corruption for more than a few people, why are they marked as stable???? See http://forums.gentoo.org/viewtopic-t-584894-highlight-.html
(In reply to comment #24) > These drivers cause video corruption for more than a few people, why are they > marked as stable???? as far as i know, there have always been issues with nvidia-drivers with at least some setups and i guess theres nothing gentoo can do about that; tell nvidia to relicense their drivers and have them integrated into the mainline kernel! on the other hand side, there is not a single open gentoo-bug about x11-drivers/nvidia-drivers-100.14.19; one bug (bug 193160) has been resolved as UPSTREAM, but it is about xorg-server-1.4 which is not stable yet. also note, that everything compiz related doesn't count here. so, if you think these drivers are really that bad, file a bug.
It's up to users themselves to report issues when they have issues. Gentoo developers can not read minds via the internet, we might be able to in person though. If you have a bug or issue with something, it's best to file a bug. Though since the NVIDIA drivers are closed source and there is really nothing we can fix, 99% of the time the solution is to use nvidia-bug-report.sh and send that info to nvidia's linux support at linux-bugs@nvidia.com Gripping about issues with the drivers on a forum thread that no one but a handful of users know about won't get any solutions. Additionally, the issue seems to only happen with users using compiz, which is experimental at best and many xorg.conf's posted had incorrect settings for compiz.
I get complete UI freeze after some actions (so far I've encountered it when launching Opera and pressing enter in Claws Mail compose window) with 71.86.01 on my GeForce4 MX 440 AGP 8x, so I can't give my x86 blessings here, sorry.
Have you submitted a bug report to NVIDIA?(In reply to comment #27) > I get complete UI freeze after some actions (so far I've encountered it when > launching Opera and pressing enter in Claws Mail compose window) with 71.86.01 > on my GeForce4 MX 440 AGP 8x, so I can't give my x86 blessings here, sorry. > Have you submitted a bug report to NVIDIA?
(In reply to comment #27) > I get complete UI freeze after some actions (so far I've encountered it when > launching Opera and pressing enter in Claws Mail compose window) with 71.86.01 > on my GeForce4 MX 440 AGP 8x, so I can't give my x86 blessings here, sorry. > Have you tried the more recent 96.43.01? They work fine for me... lspci | grep -i nividia 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2)
> Have you tried the more recent 96.43.01? They work fine for me... > > lspci | grep -i nividia > 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP > 8x] (rev a2) > Yep, 96.43.01 seem to work OK. @cardoe: no, I did not report it to nvidia.
(In reply to comment #25) > (In reply to comment #24) > > These drivers cause video corruption for more than a few people, why are they > > marked as stable???? > > as far as i know, there have always been issues with nvidia-drivers with at > least some setups and i guess theres nothing gentoo can do about that; tell > nvidia to relicense their drivers and have them integrated into the mainline > kernel! > > on the other hand side, there is not a single open gentoo-bug about > x11-drivers/nvidia-drivers-100.14.19; one bug (bug 193160) has been resolved as > UPSTREAM, but it is about xorg-server-1.4 which is not stable yet. also note, > that everything compiz related doesn't count here. > > so, if you think these drivers are really that bad, file a bug. > I have two Gentoo boxes here, one an AMD64 with a 7950 GT and the other a P4 with a 6600 and both have this issue. Both are running 99% stable arch with a handful of keyworded items. None of which would affect this. The thread on gentoo forum's I referenced has a link to nVidia's forum which have a bunch of other people experiencing this. Nvidia's response was basically wait for a new driver release. I don't understand why the push to get .19 stable when I don't remember seeing anyone complaining having these issues with .11 which is still masked.
(In reply to comment #31) > I don't understand why the push to get .19 stable when I don't > remember seeing anyone complaining having these issues with .11 which is still > masked. > I have an issue with .11: it doesn't work with 2.6.23 sources. And there wan no reason to not mark .19 stable since there were no bug report for this problem.
Ok, so what are we to do now? Stable above packages or will we wait for just another release?
It's nvidia binary drivers.. Someone's going to have an issue with every driver release for some reason or another.
x86 stable, and closing
According to nVidia, this bug is fixed in 169.04, maybe that should be the target for stable? It is a beta driver though. http://www.nvnews.net/vbulletin/showpost.php?p=1454985&postcount=49
*** Bug 200444 has been marked as a duplicate of this bug. ***
*** Bug 200440 has been marked as a duplicate of this bug. ***
*** Bug 200442 has been marked as a duplicate of this bug. ***
Created attachment 137082 [details, diff] Patch for nvidia-drivers-1.0-7185 This patch works for elder version of nvidia-drivers. I'm uploading it because patches for the newest version don't work.
*** Bug 202749 has been marked as a duplicate of this bug. ***
(In reply to comment #40) Confirmed (x86) the patch for nvidia-drivers-1.0-7185 works (attachment id=137082). Thank you.
*** Bug 202941 has been marked as a duplicate of this bug. ***
