Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 104369

Summary: Unable to start Xorg on kernel 2.6.13 with nvidia driver
Product: Gentoo Linux Reporter: Marko Steinberger <marko.steinberger>
Component: [OLD] UnspecifiedAssignee: X11 External Driver Maintainers <x11-drivers>
Status: RESOLVED FIXED    
Severity: major CC: daniel.plaza.espi, daphx86, dizzinger, gentoo, johol, jrmalaq, m.langer798, mertens.steven, mike, pierre_aussaguel, swift, tieze, yarden
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: output of dmesg
Xorg Log
emerge info output
Xorg.log

Description Marko Steinberger 2005-08-31 04:33:05 UTC
After upgrading to kernel 2.6.13 using gentoo-sources on ~x86 (AMD Athlon 705MHz
on Asus K7M) I am unable to bring up X (xorg-x11-6.8.2-r2). 

I have a legacy card (Geforce 256 / Hercules 3D Prophet board) installed, so I
am unable to switch to the latest Nvidia drivers which some people reported to
work just fine. Latest available drivers for me are: nvidia-kernel-1.0.7174 with
nvidia-glx-1.0.7174-r5. These work fine up to at least gentoo-sources-2.6.12-r9
(haven't tried r10 yet but I don't see any reason why they should not work
there, too).

However, the nvidia module is loaded properly during bootup. At the end X tries
to start and stops with an error message saying that several screen
configurations have been found but none of them have a usable configuration.


Reproducible: Always
Steps to Reproduce:




Expected Results:  
Xorg should have started.

Using the "startx" command tries to load the nvidia module once more resulting
in the same error message.
Comment 1 Marko Steinberger 2005-08-31 13:52:01 UTC
Just tested 2.6.13 with nv driver (as provided by Xorg) instead of nvidia. 

nv works, nvidia not.
Comment 2 Joshua Baergen (RETIRED) gentoo-dev 2005-08-31 17:12:43 UTC
Please attach the output of your Xorg log as well as `dmesg`.
Comment 3 Yanko Hdez 2005-08-31 22:39:22 UTC
Created attachment 67383 [details]
output of dmesg
Comment 4 Yanko Hdez 2005-08-31 22:40:50 UTC
Created attachment 67385 [details]
Xorg Log
Comment 5 Yanko Hdez 2005-08-31 22:41:39 UTC
Created attachment 67386 [details]
emerge info output
Comment 6 Yanko Hdez 2005-08-31 22:46:50 UTC
My situation is similar:
* system: P3 800 Mhz, nVidia Vanta video board.
* kernel 2.6.12.2/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4 works ok
* kernel 2.6.13/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4, the kernel loads
the module, but xorg stops (xorg log attached)
* nvidia doesn't work, nv (as provided by xorg) does
Comment 7 Marko Steinberger 2005-09-01 05:22:19 UTC
The situation is getting weirder here. I was just booting 2.6.13 for a dmesg
output an Xorg.log as X came up just fine. A second boot, no change.

I've also upgraded three packages to the following versions before:
udev-068
sdl-sound-1.0.1-r1
wxGTK-2.6.1

I'll let you know if I find some reason for this strange behaviour.
Comment 8 Horst Schirmeier 2005-09-02 10:40:21 UTC
I can confirm this behaviour for the current x86 nvidia-{kernel,glx} versions
(1.0.6629), though ~x86 (1.0.7676) works (but stalls Xorg after a few hours with
my "nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1)").

To get 1.0.6629 (and possibly also the reported 1.0.7174) to work, check this
forum thread [1] for a solution. The mentioned shell script creates the missing
device nodes and can be put in (or called from) /etc/conf.d/local.start .

[1] http://forums.gentoo.org/viewtopic-t-375466.html
Comment 9 Paul Bredbury 2005-09-02 15:28:53 UTC
As some sort of additional info, this is *not* a problem for me.  Relevant
software versions are:  udev-068, xorg-x11-6.8.99.15, nvidia-kernel-1.0.7676,
nvidia-glx-1.0.7676-r1, gentoo-sources-2.6.13

This is with a Geforce 6800 video card.
Comment 10 chris 2005-09-02 22:09:41 UTC
"* kernel 2.6.12.2/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4 works ok 
* kernel 2.6.13/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4, the kernel loads 
the module, but xorg stops (xorg log attached) 
* nvidia doesn't work, nv (as provided by xorg) does" 
 
 
I'm experiencing the exact same thing as commenter #6; same versions and all. 
Comment 11 Joshua Baergen (RETIRED) gentoo-dev 2005-09-03 07:16:10 UTC
Could some people confirm the fix in comment #8?
Comment 12 Yanko Hdez 2005-09-03 11:23:52 UTC
(In reply to comment #11)
> Could some people confirm the fix in comment #8

confirmed. when I boot kernel 2.6.12.2 the nodes are created. when I boot 2.6.13
they are not.

after creating the nodes (kernel 2.6.13) it works again. I don't know if
nvidia-kernel-1.0.6629-r4 were fixed by this. I upgraded to
nvidia-kernel-1.0.7174 because some people reported build 7174 worked for them.
Not my case. In my case 7174 only worked after nodes were created by the script.
Comment 13 chris 2005-09-03 21:48:35 UTC
I can confirm comment #8's fix as well.  The legacy nvidia drivers didn't 
create the device nodes.  Manually creating them fixed the problem. 
Comment 14 Marko Steinberger 2005-09-05 05:52:05 UTC
I had RC_DEVICE_TARBALL="yes" set. This was what made Xorg suddenly working with
2.6.13 with nvidia-kernel-1.0.7174. The nodes had just been saved from a prior
2.6.12 boot.

So, it looks like a "missing device nodes" here, too.
Comment 15 Kerin Millar 2005-09-05 11:06:46 UTC
I had a brief chat with one of the kernel developers on the Gentoo team and, if
I understand him correctly, apparently sysfs is now "strictly GPL-only". This
would explain the problem because if a device is not shown by sysfs then udev
will not create or manage its device nodes. And the nvidia driver core is
neither open nor licensed under the GPL.

I've no idea which patch(es) introduced this change, when or the reasoning
behind it but I'm assuming that it was done quite deliberately and that it is
not going to be reverted. If that assumption is correct then I suppose we're
just going to have to accept that something else is going to have to be
responsible for creating the nodes.

I'm not entirely sure, but I think the very newest drivers do (or will) create
the nodes automatically of their own accord. After all, I'm sure nvidia are well
aware of the problem. For now, I'm creating the nodes in /etc/conf.d/local.start
as I suspect almost everyone else is.

  mknod /dev/nvidiactl c 195 255
  mknod /dev/nvidia0 c 195 0  
  chown root:video /dev/nvidia*
  chmod 0660 /dev/nvidia*

I suppose we (nvidia users) are just going to have to wait and see how the
situation pans out. At least there appear to be no problems other than the
aformentioned one. I'm using a Riva TNT2 with 2.6.13-ck1,
nvidia-kernel-1.0.7167-r1 and the necessary workaround. Furthermore, I use (and
have always used) the RC_DEVICE_TARBALL="no" setting. It appears to be perfectly
reliable.
Comment 16 Horst Schirmeier 2005-09-05 16:06:32 UTC
As I mentioned earlier, 1.0.7676 (current ~x86) _does_ work for me on 2.6.13 and
creates the necessary device nodes. Whatever kernel interface changes are
mentioned in comment #15, this version seems to keep up with them (though it
seems to be unstable with my pretty old GeForce2 MX, Xorg stalls after an hour
or so); maybe the nvidia people will be so kind to backport whatever they
changed to accommodate the kernel changes.

Did I ever mention binary drivers suck? I only use this one because it does a
quite better job in 2D acceleration (tvtime video overlay, scaling...) than the
Xorg nv driver, which is essential for me as my Athlon 700 does not give me an
usable frame rate when watching TV while using nv... *sigh* (And, yes, I'm not
even mentioning 3D acceleration.)
Comment 17 Ortwin Glueck 2005-09-07 12:57:24 UTC
Comment #15 probably refers to this patch that changed the sysfs export symbols
to GPL only: http://lwn.net/Articles/104392/
Comment 18 Ortwin Glueck 2005-09-07 13:34:10 UTC
Also confirmed fix in comment #8. Please note that there is already a script
/sbin/NVmakedevices.sh which you can call from your /etc/conf.d/local.start like so:

if [ ! -e /dev/nvidia0 ]; then
  /sbin/NVmakedevices.sh
fi
Comment 19 Francisco Rodera 2005-10-08 08:02:58 UTC
kernel 2.6.13/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4 here.
It doesnt work either on RC_DEVICE_TARBALL="yes" or RC_DEVICE_TARBALL="no" so...
no way for fixing it ?? :(
Comment 20 Joshua Baergen (RETIRED) gentoo-dev 2005-10-08 08:42:57 UTC
Look one comment up...
Comment 21 crsdefiance 2005-10-08 10:20:54 UTC
I have kernel 2.6.13-r3 and the latest 7676 drivers on my AMD64 system. I have
this same problem, and I don't have /sbin/NVmakedevices.sh so I can't try to see
if that works.
Comment 22 Joshua Baergen (RETIRED) gentoo-dev 2005-10-08 10:48:08 UTC
Look at the forum entry in comment #8.
Comment 23 Thijs Brobbel 2005-10-09 07:39:05 UTC
Since 2.6.13 the interface class_simple has been renamed, because it became the
default IF (instead of the artifice, it original was, see
http://www.kerneltraffic.org/kernel-traffic/kt20040120_248.html#3). The
intention of this IF is to communicate by /sys with udev, this way it knows
which device nodes it should make. The nvidia kmod uses this IF, and as of
2.6.13, it won't get compiled in (at least in the 1.0.6629-r4 version), because
the IF ceases to exist for as far the module is aware of.So this is why the
problem occurs as of 2.6.13. 

Since version 7667 and 7676, don't come up with !$ grep class_simple nv.c!
I'm guessing these are updated with the new IF (comment #8 and #9 pretty much
confirms this).

So backporting these changes will solve this (I took the /etc/conf.d/local.start
approach, because of time issues)...
Comment 24 Joshua Baergen (RETIRED) gentoo-dev 2005-10-09 10:44:07 UTC
If someone wants to do the port go ahead; chances are some of the changes
required may be rather large.  As far as I'm concerned, a workaround exists and
this is nVidia's problem.

Maybe we should add these instructions to the docs.  Adding swift to CC so he
can decide.

Also note that some people in the forum are having better luck with newer
versions of udev.
Comment 25 Dmitri Pogosian 2005-10-12 18:43:33 UTC
Just as a check point
On my amd64 machine upgraded to 2.6.13 kernel, udev-0.68, neither 6629-r4 nor
(unstable ~amd64) 7676 nvidia driver create /dev/nvidia and /deb/nvidiactrl when
the module is loaded, even when the module is autoloaded on boot. 

Workaround with a script is of course possible, as well as manual creation of
devices, but I guess this was not a point of me upgrading to brand new (for me)
udev system 
Comment 26 Dmitri Pogosian 2005-10-12 18:49:30 UTC
(In reply to comment #23)
> Since 2.6.13 the interface class_simple has been renamed, because it became the
> default IF (instead of the artifice, it original was, see
> http://www.kerneltraffic.org/kernel-traffic/kt20040120_248.html#3). The
> intention of this IF is to communicate by /sys with udev, this way it knows
> which device nodes it should make. The nvidia kmod uses this IF, and as of
> 2.6.13, it won't get compiled in (at least in the 1.0.6629-r4 version), because
> the IF ceases to exist for as far the module is aware of.So this is why the
> problem occurs as of 2.6.13. 
> 
> Since version 7667 and 7676, don't come up with !$ grep class_simple nv.c!
> I'm guessing these are updated with the new IF (comment #8 and #9 pretty much
> confirms this).
> 
> So backporting these changes will solve this (I took the /etc/conf.d/local.start
> approach, because of time issues)...

7676 does not work on my 2.6.13 amd64 machine as well

Comment 27 Ryan Hoegg 2005-10-15 09:49:09 UTC
Well the user emerging nvidia-kernel and nvidia-glx already knows that it's not
GPL and has obviously decided to go through with it.  We're going to have to
accept that udev won't play nicely, but we shouldn't punt and make the user have
to search for this bug and copy and paste a script into /etc/conf.d/local.start.
 Why not add a little script to /etc/init.d/ and add it to the boot runlevel
instead?  It's still kludgy but at least we do the work and the user doesn't
have to look at the kludge every time he runs etc-update.
Comment 28 Dmitri Pogosian 2005-10-15 11:54:08 UTC
Thank you, Ryan, exactly. 
 
I (being not an expert) feel that expecting/forcing binary non-GPL drivers to 
create directly their own devices bypassing sysfs/udev is perhaps even less 
appropriate than allowing them to communicate with sysfs. And I don't think 
users doing it manually will be consistent in properly restrictive 
ownership/permissions.  
 
So the device creation for non-GPL drivers will have to be taken care by 
ebuild maintainers. Will it result in init script for every non-GPL driver 
present :( ? 
Comment 29 Matthias Langer 2005-10-20 11:57:07 UTC
I've had exactly the same problems with nvidia-kernel-1.0.6629-r4 and 2.6.13
(gentoo and vanilla sources). After upgrading to nvidia-kernel-1.0.7676 and
nvidia-glx-1.0.7676-r1 X seems to work again (at least for the last 30 minutes).

I'm using udev-0.70 [RC_DEVICE_TARBALL="no"] and a 'GeForce3 Ti 200' card.

Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2,
2.6.13.4 i686)
=================================================================
System uname: 2.6.13.4 i686 AMD Athlon(tm) XP 2400+
Gentoo Base System version 1.6.13
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-lang/python:     2.3.5-r2, 2.4.1-r1
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -mmmx -msse -m3dnow -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -mmmx -msse -m3dnow -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="ftp://gd.tuwien.ac.at/opsys/linux/gentoo/ "
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext X aalib alsa apm arts avi berkdb bitmap-fonts bzlib cdr
crypt cups curl dbus divx4linux dvd dvdr emboss encode esd firefox foomaticdb
fortran gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile hal imagemagick
imlib ipv6 java jpeg junit libg++ libwww mad mikmod mmx mmxext motif mp3 mpeg
ncurses nls nsplugin nvidia ogg oggvorbis opengl oss pam pdflib perl plotutils
png python readline ruby sdl slang speex spell sqlite sse ssl svga tcltk tcpd
tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis win32codecs
xine xml xml2 xmms xv xvid zlib video_cards_radeon userland_GNU kernel_linux
elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS
Comment 30 Matthias Langer 2005-10-20 11:59:10 UTC
By the way: I'm using xorg-x11-6.8.2-r4
Comment 31 Frank Disseldorp 2005-10-20 16:52:43 UTC
I'm having the same troubles. the nvidia module just won't start when using
2.6.13-gentoo-r3. I've tried to upgrade nvidia-kernel and nvidia-glx and
nvidia-kernel to the latest version (media-video/nvidia-kernel-1.0.7676) but it
still didn't work, this is what the Xorg log says:

(EE) NVIDIA(0): Failed to obtain a shared memory identifier.
(II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture
(==) NVIDIA(0): Backing store disabled
(==) NVIDIA(0): Silken mouse enabled
(II) Loading extension NV-CONTROL

   *** If unresolved symbols were reported above, they might not
   *** be the reason for the server aborting.

Fatal server error:
Caught signal 11.  Server aborting

--
I'm using a 'GeForce4 MX 440' videocard
Comment 32 Frank Disseldorp 2005-10-22 07:07:47 UTC
(In reply to comment #31)
> I'm having the same troubles. the nvidia module just won't start when using
> 2.6.13-gentoo-r3. I've tried to upgrade nvidia-kernel and nvidia-glx and
> nvidia-kernel to the latest version (media-video/nvidia-kernel-1.0.7676) but it
> still didn't work, this is what the Xorg log says:
> 
> (EE) NVIDIA(0): Failed to obtain a shared memory identifier.
> (II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture
> (==) NVIDIA(0): Backing store disabled
> (==) NVIDIA(0): Silken mouse enabled
> (II) Loading extension NV-CONTROL
> 
>    *** If unresolved symbols were reported above, they might not
>    *** be the reason for the server aborting.
> 
> Fatal server error:
> Caught signal 11.  Server aborting
> 
> --
> I'm using a 'GeForce4 MX 440' videocard


Oops, I've seem to forget that 'System V IPC' was needed for the nvidia driver
to work. Now i've enabled it and upgraded to the new nvidia drivers, it works!
Comment 33 Jeremy Huddleston (RETIRED) gentoo-dev 2005-10-28 00:41:31 UTC
closing as user reports fixed.
Comment 34 Pierre AUSSAGUEL 2005-10-28 10:08:40 UTC
I am sorry, but I cannot consider this bug to be resolverd neither closed.
I use a Nforce chiset (with integrated GEFORCE2) and therefore Nvidia drivers
above 7174 do not support my GPU.
So I am stuck to 7174.
I know the workaround, but this is not clean. Udev or Nvidia ebuild should take
care of this.
Comment 35 Horst Schirmeier 2005-10-28 10:15:47 UTC
I agree with Pierre/comment #34. For me this one is not FIXED either: Newer
nvidia driver releases are very unstable if used with my GeForce2 MX hardware
and tend to freeze X11 here.
Comment 36 Dmitri Pogosian 2005-10-28 20:45:33 UTC
I don't see why the bug is closed as fixed.  I don't think comment 31 and 32
described the same problem as the original one.

At least for me on amd64 architechture there is no combination of nvidia drivers
(including ~amd64) and udev version which would automatically create nvidia
devices. This is a bug. 
Comment 37 Jeremy Huddleston (RETIRED) gentoo-dev 2005-10-29 14:52:41 UTC
Perhaps FIXED is incorrect, it should say CANTFIX.  We have no controll over
nvidia's release policy... as for what to do if you have old hardware, just mask
out newer versions by placing entries in /etc/portage/package.mask

As for the other problems not associated with this bug, please open other bug
reports for those problems if you're still having issues.  Please don't clutter
bug reports with unrelated issues, thanks.
Comment 38 Roc Vall├Ęs 2005-11-22 20:27:56 UTC
Same here, I'm stuck to 6xxx thanks to nvidia abandoning support for my card
somewhere in 7xxx. (GeForce 256)

So bad nvidia leaves us naked; not supported anymore, but drivers/documentation
not freed either. Not that I'm going to buy anything from nvidia again, unless
they radically change their way of doing things.
Comment 39 Edd Ghad 2006-02-13 06:11:01 UTC
Fails on 2.6.15  from emerge as well. Same hardware works with Arch
Comment 40 Matthias Langer 2006-02-13 18:28:48 UTC
Hmm, i'm using gentoo-sources-2.15-r5, nvidia-kernel-1.0.8178-r3 and  xorg-x11-6.8.2-r6 with a GeForce3-Ti-200 and everything seems to work fine ...

Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-gentoo-r5 i686)
=================================================================
System uname: 2.6.15-gentoo-r5 i686 AMD Athlon(tm) XP 2400+
Gentoo Base System version 1.6.14
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.inode.at/ "
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
LINGUAS="de en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext X a52 aalib alsa apm audiofile avi berkdb bitmap-fonts bonobo bzip2 bzlib cairo cdr crypt css cups curl dbus divx4linux dts dv dvd dvdr dvdread emboss encode esd evo exif expat fam fame ffmpeg firefox flac foomaticdb fortran gd gdbm gif glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal idn imagemagick imlib ipv6 java jpeg junit lcms libg++ libwww mad mikmod mmx mmxext mng motif mp3 mpeg nautilus ncurses nls nptl nsplugin nvidia ogg oggvorbis openal opengl pam pcre pdflib perl plotutils png python quicktime readline real ruby sdl slang speex spell sqlite sse ssl subtitles svga tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs xine xml xml2 xmms xv xvid zlib linguas_de linguas_en userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS
Comment 41 Yarden Livnat 2006-02-24 09:42:54 UTC
Created attachment 80607 [details]
Xorg.log
Comment 42 Yarden Livnat 2006-02-24 09:45:38 UTC
It does not work here though my setup seems very similar

Intel  EM64T  
Nvidia 6800GTO (a special version that support Apple HD 30" montior with 2560x1600)

gentoo-sources-2.6.15-r5,   (SMP)
nvidia-kernel-1.0.8178-r3
xorg-x11-6.8.2-r6 and xorg-x11-7.0-r1

the machine hangs during startx.
Xorg.0.log *always* shows "resources ranges after preInit:" follow by 42 resources and then it hangs....
(attached)

(In reply to comment #40)
> Hmm, i'm using gentoo-sources-2.15-r5, nvidia-kernel-1.0.8178-r3 and 
> xorg-x11-6.8.2-r6 with a GeForce3-Ti-200 and everything seems to work fine ...
> 
> Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2,
> 2.6.15-gentoo-r5 i686)