[gutsy rc] nVidia Corporation Quadro NVS 140M - display locked without nvidia-glx-new

[hce]

just installed 7.10 rc on a lenovo R61
this laptop is known to ship with different graphic cards. this has:

root@aubergine:~# lspci -s 01:00.0 -v
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1) (prog-if 00 [VGA])
        Subsystem: Lenovo Unknown device 20d8
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Memory at d4000000 (64-bit, non-prefetchable) [size=32M]
        I/O ports at 2000 [size=128]
        Capabilities: [60] Power Management version 2
        Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
        Capabilities: [78] Express Endpoint IRQ 0

after installation, the screen was blank, and I wasn't able to switch to virtual consoles or reboot with the keyboard
I had to shutdown the hard way, boot with the install disk in rescue mode, install ssh server just to start doing some tests

It happears the nv driver locked the screen.

then I found out I had to use nvidia-glx-new, installed it manually, and now X works.

strangely enough, after starting and killing X with nvidia-glx-new (Driver = nvidia), the nv driver worked correctly. but after a reboot the same configuration locked the screen again.

then, I may suppose the nvidia driver does some initialization on the hardware that enables the nv driver to work, but if the nv driver is run after a reboot it isn't able to properly initialize the card.

I will post Xorg logs for the three cases.

I suggest the installer detects graphic cards that won't work, disable automatic gdm startup and warn the user, or better suggests to install the correct proprietary driver and does it if the user whishes.

a similar Xorg bug has already been filled for a Quadro FX 570M on Lenovo R61:
https://bugs.freedesktop.org/show_bug.cgi?id=12637

[hce (hce)]

very similar behaviour with a lenovo R61, using Quadro NVS 140M (rev a1)

now using the proprietary nvidia-glx-new driver (ubuntu 7.10 rc), which seems ok

strangely enough, after starting and killing X with nvidia-glx-new (Driver = nvidia), the nv driver worked correctly.
but after a reboot the same configuration locked the screen again.

then, I may suppose the nvidia driver does some initialization on the hardware that enables the nv driver to work, but if the nv driver is run after a reboot it isn't able to properly initialize the card.

[hce (hce)]

Created an attachment (id=12003)
server log with nv driver after a reboot - screen blank and locked

[hce (hce)]

Created an attachment (id=12004)
server log with nv driver after the nvidia proprietary driver has been used - works OK

[hce (hce)]

Created an attachment (id=12005)
server log with the nvidia proprietary driver - works OK

[hce (hce)]

just installed 7.10 rc on a lenovo R61
this laptop is known to ship with different graphic cards. this has:

root@aubergine:~# lspci -s 01:00.0 -v
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1) (prog-if 00 [VGA])
        Subsystem: Lenovo Unknown device 20d8
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Memory at d4000000 (64-bit, non-prefetchable) [size=32M]
        I/O ports at 2000 [size=128]
        Capabilities: [60] Power Management version 2
        Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
        Capabilities: [78] Express Endpoint IRQ 0

after installation, the screen was blank, and I wasn't able to switch to virtual consoles or reboot with the keyboard
I had to shutdown the hard way, boot with the install disk in rescue mode, install ssh server just to start doing some tests

It happears the nv driver locked the screen.

then I found out I had to use nvidia-glx-new, installed it manually, and now X works.

strangely enough, after starting and killing X with nvidia-glx-new (Driver = nvidia), the nv driver worked correctly. but after a reboot the same configuration locked the screen again.

then, I may suppose the nvidia driver does some initialization on the hardware that enables the nv driver to work, but if the nv driver is run after a reboot it isn't able to properly initialize the card.

I will post Xorg logs for the three cases.

I suggest the installer detects graphic cards that won't work, disable automatic gdm startup and warn the user, or better suggests to install the correct proprietary driver and does it if the user whishes.

a similar Xorg bug has already been filled for a Quadro FX 570M on Lenovo R61:
https://bugs.freedesktop.org/show_bug.cgi?id=12637

[hce (hce)]

xorg log with nvidia proprietary driver

[hce (hce)]

xorg log with nv driver, after the X server has been started with the nvdia proprietary driver

[hce (hce)]

xorg log with nv driver, after a reboot. screen is blank and locked

[Aaron Plattner (aplattner)]

Does the server come up after a reboot if you set Option "NoAccel"? How about Option "AccelMethod" "EXA"?

[hce (hce)]

(In reply to comment #5)
> Does the server come up after a reboot if you set Option "NoAccel"?

with the open source nv driver and Option "NoAccel", same behaviour (blank screen, no switching to text consoles)

> How about Option "AccelMethod" "EXA"?

with the open source nv driver and Option "AccelMethod" "EXA", same behaviour (blank screen, no switching to text consoles)

would you like the log files?

I must correct on one aspect: when the screen is blank, ctrl+alt+canc works (but with no feedback on the local console, I noticed it while being connected via ssh)

the two laptops (IBM T61p and lenovo R61) seems somewhat related, maybe some issue related to chipset/bios?

[Fleuret (fleuret)]

> I must correct on one aspect: when the screen is blank, ctrl+alt+canc works
> (but with no feedback on the local console, I noticed it while being connected
> via ssh)

If I connect by ssh to my T61p in that "blank screen" state, everything is fine there, with Xorg taking 100% CPU. I can kill it, but I don't get the console back.

Starting the vesa server in that state does not restore the display.

[hce (hce)]

Created an attachment (id=12017)
strace -o X.trace -f startx

I didn't notice the 100% CPU. It happens on my system too.
X wants to be killed with -9
attached is a strace of the server with nv driver. it is rather inconclusive (last syscalls are used to write log messages, then nothing more).

some more hints from gdb (attached to a running X process):

the process seems to be looping at 0xb717b1aa in G80DispInit ()

root@aubergine:~# gdb -p 6483
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
Attaching to process 6483
Reading symbols from /usr/bin/Xorg...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /usr/lib/libXfont.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXfont.so.1
Reading symbols from /usr/lib/libXau.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXau.so.6
Reading symbols from /usr/lib/libfontenc.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfontenc.so.1
Reading symbols from /usr/lib/libXdmcp.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXdmcp.so.6
Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libfreetype.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfreetype.so.6
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/xorg/modules/libpcidata.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/xorg/modules//libpcidata.so
Reading symbols from /usr/lib/xorg/modules/libglx.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/xorg/modules//libglx.so
Reading symbols from /usr/lib/libGLcore.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libGLcore.so.1
Reading symbols from /usr/lib/tls/libnvidia-tls.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/tls/libnvidia-tls.so.1
Reading symbols from /usr/lib/xorg/modules/extensions/libextmod.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/xorg/modules/extensions//libextmod.so
Reading symbols from /usr/lib/xorg/modules/extension...

[Niklas+freedesktop (niklas+freedesktop)]

I'd like to add that I have the same problem on my Lenovo R61, running current OpenBSD as of 2007-10-12, using nv 2.1.5 as well. On OpenBSD, there's not an option of using the proprietary driver for proper initialization of the chipset,
so I'd judge the bug as critical. It's not a blocker, since the vesa driver works but with 1280x1025 it gets pretty ugly on a 1680x1050 LCD screen.

[Aaron Plattner (aplattner)]

Thanks, the backtrace is helpful. Could you please build the driver with debugging and figure out exactly which line it's stuck on?

[hce (hce)]

(In reply to comment #10)
> Thanks, the backtrace is helpful. Could you please build the driver with
> debugging and figure out exactly which line it's stuck on?
>

hi

I used http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.5.tar.bz2

the blank unusable screen, and 100% CPU is reproducted with this code

X server is from ubuntu 7.10 RC
ii xorg 1:7.2-5ubuntu13 X.Org X Window System
ii xserver-xorg 1:7.2-5ubuntu13 the X.Org X server
ii xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8 X.Org X server -- core server
ii xserver-xorg-video-nv 1:2.1.5-1ubuntu1 X.Org X server -- NV display driver

the driver appears to be stuck in:
0xb71831aa in G80DispInit (pScrn=0x8216d50) at g80_display.c:261
261 while((pNv->reg[0x00610200/4] & 0x1e0000) != 0);

and it looks like gdb is unable to access pNv->reg[0x00610200/4], but maybe there's something I don't get (see below)

If you need more info, please ask

bye

MAtteo

root@aubergine:~# gdb -p 5493
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
Attaching to process 5493
Reading symbols from /usr/bin/Xorg...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /usr/lib/libXfont.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXfont.so.1
Reading symbols from /usr/lib/libXau.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXau.so.6
Reading symbols from /usr/lib/libfontenc.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfontenc.so.1
Reading symbols from /usr/lib/libXdmcp.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXdmcp.so.6
Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libfreetype.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfreetype.so.6
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/xorg/modules/libpcidata.so...(no debugging symbols found)...done.
Loaded sy...

[Aaron Plattner (aplattner)]

Okay, thank you very much. I suspect I know what's going on, but please try this to confirm:

Apply this patch:
diff --git a/src/g80_display.c b/src/g80_display.c
index 6c95773..20861ad 100644
--- a/src/g80_display.c
+++ b/src/g80_display.c
@@ -258,10 +258,14 @@ G80DispInit(ScrnInfoPtr pScrn)
     }

     pNv->reg[0x00610200/4] = 0x2b00;
- while((pNv->reg[0x00610200/4] & 0x1e0000) != 0);
+ ErrorF("Waiting for hardware to settle ... ");
+ sleep(1);
+ ErrorF("reg is 0x%x\n", pNv->reg[0x00610200/4]);
     pNv->reg[0x00610300/4] = 1;
     pNv->reg[0x00610200/4] = 0x1000b03;
- while(!(pNv->reg[0x00610200/4] & 0x40000000));
+ ErrorF("Waiting for hardware to settle ... ");
+ sleep(1);
+ ErrorF("reg is 0x%x\n", pNv->reg[0x00610200/4]);

     C(0x00000084, 0);
     C(0x00000088, 0);

and then tell me what it prints for the register values.

[hce (hce)]

(In reply to comment #12)
> Okay, thank you very much. I suspect I know what's going on, but please try
> this to confirm:
>
> Apply this patch:

...

===starting the server after the nvidia driver has run - the server still works==

(==) NV(0): Backing store disabled
(==) NV(0): Silken mouse enabled
(**) Option "dpms"
(**) NV(0): DPMS enabled
Waiting for hardware to settle ... reg is 0x48012b08
Waiting for hardware to settle ... reg is 0x490a0b0b
(II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message.
(--) RandR disabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension

==after a reboot - still blank screen==

(==) NV(0): Backing store disabled
(==) NV(0): Silken mouse enabled
(**) Option "dpms"
(**) NV(0): DPMS enabled
Waiting for hardware to settle ... reg is 0x48022b08
Waiting for hardware to settle ... reg is 0x49020b0b

(EOF)

Xorg still running at 100% CPU

now looping in:
root@aubergine:~# gdb -p 5517
GNU gdb 6.6-debian
...
0xb726a20d in G80DispCommand (pScrn=0x8216d50, addr=132, data=0) at g80_display.c:188
188 while(pNv->reg[0x00610300/4] & 0x80000000) {
(gdb) bt
#0 0xb726a20d in G80DispCommand (pScrn=0x8216d50, addr=132, data=0) at g80_display.c:188
#1 0xb726b26d in G80DispInit (pScrn=0x8216d50) at g80_display.c:270
#2 0xb726c4e1 in AcquireDisplay (pScrn=0x80010085) at g80_driver.c:508
#3 0xb726c94f in G80ScreenInit (scrnIndex=0, pScreen=0x821c430, argc=10, argv=0xbffc6064) at g80_driver.c:946
#4 0x0807653e in AddScreen ()
#5 0x080a86ce in InitOutput ()
#6 0x08076ceb in main ()
(gdb) p pNv->reg[0x00610300/4]
Cannot access memory at address 0xb66e2300

then I attempted one more step:

root@aubergine:/home/valsasna/src/xf86-video-nv-2.1.5/src# diff -c g80_display.c.p1 g80_display.c
*** g80_display.c.p1 2007-10-13 09:18:33.000000000 +0200
--- g80_display.c 2007-10-13 09:36:16.000000000 +0200
***************
*** 187,194 ****
--- 187,197 ----

      while(pNv->reg[0x00610300/4] & 0x80000000) {
          const int super = ffs((pNv->reg[0x00610024/4] >> 4) & 7);
+ ErrorF("G80DispCommand:reg is 0x%x, reg_super is 0x%x\n", pNv->reg[0x00610300/4], pNv->reg[0x00610024/4]);
+ sleep(1);

          if(super) {
+ ErrorF("G80DispCommand: super is %i", super);
              if(super == 2) {
                  xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
                  const CARD32 r = pNv->reg[0x00610030/4];

Waiting for hardware to settle ... reg is 0x48022b08
Waiting for hardware to settle ... reg is 0x49020b0b
G80DispCommand:reg is 0x80010085, reg_super is 0x0
G80DispCommand:reg is 0x80010085, reg_super is 0x0
G80DispCommand:reg is 0x80010085, reg_super is 0x0
G80DispCommand:reg is 0x80010085, reg_super is 0x0

(ad libitum until Xorg killed)

it appears the if (super) branch is never entered

[Aaron Plattner (aplattner)]

Thanks, that's exactly what I suspected was happening: your BIOS is leaving the hardware in a weird state. The fact that it doesn't respond while it's in that state isn't surprising. I'll try to code up a patch for you to try sometime this weekend.

[Aaron Plattner (aplattner)]

Created an attachment (id=12028)
proposed fix

Okay, please try the attached patch.

[Fleuret (fleuret)]

> Okay, please try the attached patch.

Great! It is not stuck anymore (T61p here)

However:

1/ The console is messed up when switching back to it

2/ the server "feels" far slower than the vesa one.

I'll try to attach my Xorg.log.0 with the patch.

[Fleuret (fleuret)]

Created an attachment (id=12029)
Xorg.log with Aaron's today patch

I patched the nv server from the debian's package.

[Aaron Plattner (aplattner)]

What exactly do you mean by "messed up"? What are you doing that "feels" slow? These sound like different problems. I'm going to mark this fixed with commit 1003bcb.

[Aaron Plattner (aplattner)]

*** Bug 12397 has been marked as a duplicate of this bug. ***

[Fleuret (fleuret)]

> What exactly do you mean by "messed up"?

The console was filled with the character "&" in blue and reverse video, and nothing happened when typing things in blind. I had to ctrl-alt-del the system to reboot.

> What are you doing that "feels" slow?

Moving the windows around (firefox and xterms) gives the impression that it takes ~4 times more time to reconstruct their content then with the vesa server. What would be the canonical benchmark to measure the performance of the server in 2D ?

Regards,

[Fleuret (fleuret)]

I can be more precise for the messed up console.

If I log in with xdm, everything is fine, then when I quit, I end up with a messed up console in text mode, with weird characters in weird color blinking around, and I can do nothing.

If I ssh on that machine, it shows again a Xorg task taking 100% CPU. Doing kill -9 on it restores the screen with the xdm invite. Doing Alt-Ctrl-f1 in that state gives a working console.

Regards,

[Aaron Plattner (aplattner)]

Sounds to me like the BIOS is buggy. You should see if an updated BIOS is available.

[Fleuret (fleuret)]

> Sounds to me like the BIOS is buggy. You should see if an updated BIOS is
> available.

Just updated with the latest BIOS from Lenovo's web site, did not solve the problem.

But the "messed console" is not the same problem as the "stuck on blank screen" you solved ?

[Niklas+freedesktop (niklas+freedesktop)]

I'd like to state that my R61 has been fixed by the patch, many thanks!
No appearant slowdown for me. and so far VT-switching has worked OK too.

However, as a long time Open Source contributor and proponent, I am somewhat dismayed about the nv driver's source. The "open" source may be free, but not really open when it comes to give users freedom, since it's full of magic numbers with no symbolic constants or commentary to document what the magic is about.

I don't think Aaron is doing this out of spite, but rather that nvidia ties his hands. I think it's sad, but of course I am happy that there's some source around, otherwise my fringe OS wouldn't have worked on the laptop I'm using. Well, maybe I would've done the right thing then, not bought an nvidia product, but that's purely hypotheticalb.

I just wanted to have this said. To end this comment in a more heartily way: many thanks! I am really happy with the fix!!

[hce (hce)]

(In reply to comment #15)
> Created an attachment (id=12028) [details]
> proposed fix
>
> Okay, please try the attached patch.
>

this works for me too (lenovo R61, Quadro NVS 140M)

the driver starts correctly after a reboot, and switching between X an VTs is OK too)

the performance is somewhat worse than the nvidia driver (when I move windows on the screen, they are quite sluggish, and it looks like the operation is performed in software without acceleration, I see the window being redrawn in pieces, and the CPU bumps to 100% while I move the window), still usable for office work.

thank you for the prompt response.

On a different note, I must also agree with Niklas: the driver in its current format is a disputable form of "open source": a source file full of nameless and undocumented numbers can hardly be considered the "preferred form to modify the code".

Either the proper documentation for on the magic number used is available somewhere else, in which case not using symbolic name (#define) in the source is just a programming practice which leaves large room for improvement, or numbers are not publicly documented, in which case only those who have access to documentation on these numbers, or possibly only those who coded them in the hardware, can actually modify the code.

BUT the x.org project is released with the very liberal X11 license, which allows obfuscated source code and gives no explicit rights to users, thus, until someone decides to write a new X server under the GPL, we are stuck with this one and its formally open drivers.

anyway, thanks again Aaron, for fixing it so quickly

bye

MAtteo

[hce (hce)]

(In reply to comment #17)
> Created an attachment (id=12029) [details]
> Xorg.log with Aaron's today patch
>
> I patched the nv server from the debian's package.

Hi, I suggest you try to build the server module from the original package (http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.5.tar.bz2) with just Aaron's patch (debian might have added some more patches on top of it).

it will install the patched driver in /usr/local/lib/xorg/modules/drivers

then you can add two "ModulePath" statements to the Files section of your xorg.conf, one with /usr/local/lib/xorg/modules/drivers and one with /usr/lib/xorg/modules/drivers

http://packages.debian.org/source/sid/xserver-xorg-video-nv
http://ftp.de.debian.org/debian/pool/main/x/xserver-xorg-video-nv/xserver-xorg-video-nv_2.1.5-1.diff.gz

and on the "can obfuscated code be considered open source", someone at debian was trying to push this driver to the non-free section along with the proprietary binary driver - see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383465

and the nouveau project is working on a true open-source version of the driver, and their effort includes de-obfuscating the code.
http://nouveau.freedesktop.org/wiki/

[hce (hce)]

a patch for the bug in the nv (""open"" source) driver has been posted to the freedesktop bugzilla, and it works for a couple of users.

http://bugs.freedesktop.org/show_bug.cgi?id=12637#c15

[Fleuret (fleuret)]

> Hi, I suggest you try to build the server module from the original package

Excellent! There is no bug anymore when "coming back to the console"!

The server is still slower than the VESA one though.

Regards,

[Aaron Plattner (aplattner)]

*** Bug 13184 has been marked as a duplicate of this bug. ***

[Dereck Wonnacott (dereck)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that this is an older issue; is it still happening in the latest release 8.04 Hardy? If so, set the bug status to 'new' and leave a comment to signify that it is ready for triage / review. Otherwise if the issue has been fixed, please set the status to 'invalid'.

[Jnelson-jamponi (jnelson-jamponi)]

I'm not sure if anybody cares but this is still a problem for me using:

openSUSE 11.0
xorg 7.3
I also built the very latest driver with no luck.
I have a Lenovo T61p which has this video:

01:00.0 VGA compatible controller: nVidia Corporation Quadro FX 570M (rev a1)

[Aaron Plattner (aplattner)]

Jon,
This particular bug is definitely fixed. You must be experiencing a different problem.

[Fleuret (fleuret)]

Jon,

The problem is definitely not solved in the version I am using, which is

 X.Org X Server 1.4.2
 Release Date: 11 June 2008
 Debian package xserver-xorg-video-nv 1:2.1.10-1

The exact same bug remains: The server starts and works fine, but will make a messy console screen and a locked PC if one quits the xsession properly. The same happens when coming back from suspend. Strangely, killing the server with ctrl-alt-del brings back xdm properly.

Also, the server is far slower than the vesa server (!)

All this on a Lenovo T61p. You said it is a BIOS issue, which may be true. Still, being able to come back to xdm with a kill and not with a proper exit is very surprising.

Regards,

--
Francois

[Bryce Harrington (bryce)]

I believe this is now fixed in the current release in jaunty. If not, please reopen.