Problem restarting Xserver with ASUS GT520 Silent

On several boxes fitted with ASUS GT520 Silent graphic cards is see the following problem.

When I start X it works fine the first time. However, when the X server is restarted (eg after a logout) the second (and subsequent) time the Xserver is totally unresponsive. Clients (such as xdpyinfo) connect to the server successfully, but hang indefinitely. If the client is kdm, it eventually times out and kills the server. After a few tries kdm disables the server.

After the first execution of the Xserver, and before the second execution, things are apparently normal, but after the second execution, vt switching doesn’t work and it is impossible to do anything on the console. It is possible to log in remotely, but killing the X server does not restore the virtual terminals (vt).

This problem an identical software configuration works properly with a GeForce 8600M GT and a GT218 [ION] GPU.

This is with a version 304.64 driver, but it also occurred with earlier versions. I am not able to confirm whether or not this problem has always existed with the ASUS GT520 Silent cards or whether it is unique to those cards.

I have the output from two runs of nvidia-bug-report.sh for the first and second executions of the server. In both cases the server was running while the bug report was prepared (although in the second case the server is not responding). However, when I try and attach the log files I get an error message about an invalid extension.

read this ([url]If you have a problem, PLEASE read this first - Linux - NVIDIA Developer Forums) and attach the log, rename it as JPG

Adding renamed logs as requested.

Does this problem still occur with 310.19?

Yes it does.

When the X server is hung, can you connect to the system remotely with ssh, then attach to the X server with a debugger and get a backtrace? Specifically, please run “sudo gdb -p pidof Xorg” and paste the output of “backtrace”, “info registers”, and “info files”.

Same problem with Gigabyte 440 solved with /usr/bin/nvidia-smi -pm 1

This was slightly misleading. 310.19 still doesn’t work when it is started the second time, but instead of hanging it fails with a “Failed to initialize DMA” error.

I tried with

but no difference with this card.

I’m attaching a new log taken after the second run has failed.

I could go back to 304.64 and get a backtrace, but I’m guessing that would be pointless now.

Problem persists with 313.18.