Bugzilla Bug 186490

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 an attachment (id=125915) [details]
Failed merge output

Output.

This started ~git(12|13). I can only presume it was due to the merge of Xen.

Created an attachment (id=125959) [details]
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 an attachment (id=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 an attachment (id=126233) [details]
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 an attachment (id=126674) [details]
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 an attachment (id=137082) [details]
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. ***