Nvidia 3D Pro, Linux, Switch User locks X11

[DragonDru]

Greetings all.

I have 3 systems with Nvidia's 3D Pro setup. All 3 exhibit the same strange behavior.

Symptoms:
When a user activates “Switch User”, the screen goes dark. Keyboard becomes unresponsive. The mouse is likely unresponsive, but there is not mouse icon to track to know.

After a while (perhaps 5 minutes), the screen will return to the NVIDIA logo, although this has been tested far less thoroughly.

NOTE:
I know this is solvable, as this issue “went away” for me once before. Unfortunately, I have no idea what I did. I had thought it was a change from the NVIDIA-Linux-x86_64-270.41.19.run driver to the NVIDIA-Linux-x86_64-285.05.09.run driver. The fix stopped functioning after I unplugged the RF emitter while cloning the hard drive. The fix had survived several reboots prior to this.
This is the same system referenced here: http://www.nvnews.net/vbulletin/showthread.php?t=164189

Work Arounds:
Remote log-in via ssh works. Killing the “low” numbered Xorg process will restore functionality, but seems to prevent spawning of new Xorg processes. This seems to require restarting gdm3 for full functionality, while kills the logged in user's session (if it was not already dead). Restarting gdm3 without killing the Xorg process will not restore functionality.

Running strace on the low numbered Xorg process and then killing the strace job (Ctrl-C), will restore the system to proper working order. Withing to session F8 gives the prompt to log-in as the previous user and F9 is a fresh gdm3 log-in session. Repeating the process with an new user will also result in the same issues as for the first user. Same resolution steps will result in a useable system.

Turning off 3D stereo mode 11. This prevents 3D stereo from working, but “switch user” works.

Failed Ideas Already Tried:
During the course of testing, may options have been tried. Some where good ideas, some where not.

Reinstalled Debian Squeeze on two of the systems, multiple times.

Nvidia drivers tried:
NVIDIA-Linux-x86_64-275.19.run
NVIDIA-Linux-x86_64-275.28.run
NVIDIA-Linux-x86_64-285.05.09.run
NVIDIA-Linux-x86_64-290.03.run (Beta driver)

And one attempt on the 32-bit system
NVIDIA-Linux-x86-285.05.09.run

Uninstalled gnome-screensaver
Did not seem to work. Messed things up after reboot, so not pursued

Running gdm instead of gdm3.
Only effect was that gdm does a better job of killing Xorg processes than gdm3.
i.e. /etc/init.d/gdm restart would unstick the system
/etc/init.d/gdm3 would not unstick the system

Disconnecting Razer Anasi keyboard and using a “normal” usb keyboard.

Setting xorg.conf with:
Option "UseDisplayDevice" "DFP,DFP"


Setup:
2 monitors, one ViewSonic VX2268wm for 3D, second monitor is non-3D (each system had a different brand and model second monitor)

Each system contains a Nvidia Quadro card. These three models are present:
Nvidia Quadro FX 4800
Nvidia Quadro FX 4600
Nvidia Quadro 4000
Debian 6.0, Squeeze
Two systems are running 64-bit Debian, One is running 32-bit Debian.
Gnome Desktop
Passwords rsynced between systems, but not automatically and not during tests.

This system worked fine when we were running Stereo mode “3” with CRT 3D stereo and shutter glasses.


System Outputs:
strace output for higher numbered Xorg:
user@system:~ $ sudo strace -p 20202
Process 20202 attached - interrupt to quit
ioctl(17, USBDEVFS_SUBMITURB or USBDEVFS_SUBMITURB32, 0x7fff3088f570) = -1 EBUSY (Device or resource busy)
ioctl(17, USBDEVFS_DISCARDURB, 0x7fff3088f570) = -1 EINVAL (Invalid argument)
ioctl(17, USBDEVFS_REAPURB or USBDEVFS_REAPURB32^C <unfinished ...>
#Killed strace here
Process 20202 detached

Syslog:
Lots of:
Nov 2 08:47:51 JKLinuxW kernel: [ 6.123846] usb 3-1: usbfs: process 1836 (Xorg) did not claim interface 0 before use
Nov 2 08:56:35 JKLinuxW kernel: [ 528.349877] usb 3-1: usbfs: process 1836 (Xorg) did not claim interface 0 before use

After strace trick, syslog fills with these:
Nov 2 10:46:21 JKLinuxW kernel: [ 7104.212070] usb 3-1: usbfs: process 23370 (Xorg) did not claim interface 0 before use


Xorg.0.log:
Attached File

nvidia-bug-report:
Attached File

[DragonDru]

Hello again.

More System Outputs

After a lot of poking around, I think the key to solving this is in the Xorg.1.log file, not the Xorg.0.log file. I will attach the whole log file, but here are what I believe to be the relevant lines:

[ 81.360] (II) NVIDIA(0): Validated modes:
[ 81.360] (II) NVIDIA(0): "nvidia-auto-select"
[ 81.360] (II) NVIDIA(0): Virtual screen size determined to be 1680 x 1050
[ 81.388] (--) NVIDIA(0): DPI set to (90, 88); computed from "UseEdidDpi" X config
[ 81.388] (--) NVIDIA(0): option
[ 81.388] (--) Depth 24 pixmap format is 32 bpp
[ 81.388] (II) NVIDIA: Using 768.00 MB of virtual memory for indirect memory access.
[ 81.680] (II) NVIDIA(0): USB emitter - Copyright (c) 2010 NVIDIA Corporation NVIDIA
[ 81.680] (II) NVIDIA(0): stereo controller
[ 282.893] (WW) NVIDIA(0): Failed to create a device corresponding to the 3D Vision Pro
[ 282.894] (WW) NVIDIA(0): dongle.
[ 282.894] (WW) NVIDIA(0): USB stereo dongle initialization failed. Disabling stereo
[ 282.903] (II) NVIDIA(0): Setting mode "nvidia-auto-select"
[ 282.927] (II) Loading extension NV-GLX
[ 282.948] (==) NVIDIA(0): Disabling shared memory pixmaps
[ 282.948] (==) NVIDIA(0): Backing store disabled
[ 282.948] (==) NVIDIA(0): Silken mouse enabled
[ 282.949] (**) NVIDIA(0): DPMS enabled


The gap in time was the time from the screen locking to the time I was able to run strace on the newest Xorg process.

This file is from a different system than the one above, so correlations are not possible. The system I produced this log file on was as simple as I could make it. 64-bit AMD, one active monitor (the second attached but not active) and only users present were created on that system.

Work Around Script

I was able to produce an ugly, but viable workaround for this problem, which I will also attach (FreeX11.sh.gz). The script find the newest Xorg process's PID number, passes that to strace and then kills strace. It needs the program timeout (on Debian provided by package “timelimit”) and the “feild” parameter (-f) on cut will need tweaking for your system (my 64-bit systems want -f2 and my 32-bit systems want -f1). Also, if one is not running this on Debian, the paths for the programs will likely need to be adjusted.

This script is run via crontab every 10 seconds.

Here is the line that does the work:

(/bin/ps -A | /bin/grep Xorg | /usr/bin/tail -1 | /usr/bin/cut -f2 -d" ") | /usr/bin/timeout 1s /usr/bin/xargs /usr/bin/strace -p

[DragonDru]

While I have used this technique successfully for months with NVIDIA-Linux-x86_64-290.03, with version NVIDIA-Linux-x86_64-295.20, I have begun to have screen lockup issues again.

Please anticipate issues between my script and driver version NVIDIA-Linux-x86_64-295.20.

[DragonDru]

Current in use version is:

for i in `(/bin/ps -eo comm,pid | /bin/grep Xorg | /usr/bin/awk '{print$2}')`; do /usr/bin/timeout 1s /usr/bin/strace -p $i ; done

It still seems to help. Between my 4 systems running with Stereo Mode 11, they all seem to have grimlins.