Created attachment 42065 [details]
Backtrace of /usr/bin/X once GPU was locked

Overview:

I have recently begun experimenting with r600g on my HD 5750 (JUNIPER) card to see if I can get it to work.  My distribution is Debian, and the Debian X Strike Force is not currently providing r600g (only r600c) so I have been packaging my own builds.

I have found that DOSBox, which I configure to use OpenGL 2D acceleration, runs fine with r600g.  However, any program which uses 3D causes my GPU to lock up.  I do not think I was able to obtain any useful debugging info when I was able to SSH into the locked up machine, but I tried; the most recent version of Mesa I tried locks the kernel, so I cannot even use SSH once the GPU locks.  (Details below.)

  Steps to reproduce:

1.  Stop X and install r600g Mesa drivers.
2.  Start X and run a program using 3D (prboom, torcs, etc.)

  Actual results:

Both prboom and torcs will run their menuing system without crashing.  Starting an actual game in prboom will work for a few moments, then lock the GPU.  Attempting to start the game in torcs causes the GPU to lock before the first 3D frame is rendered (the final text message, "Get Ready," does display... then it locks).

  Expected results:

Eventually, I hope r600g will work without locking the GPU.  Currently, r600c works fine on this hardware, other than the fact that classic is clearly inferior in performance to gallium at this point.  (See below.)

  System info:

GPU:  Powercolor Radeon HD 5750 SCS 1GB

Kernel:  2.6.37 + cherry-pick drm-core-next 17db7042 (Jan. 4, 2011)

Linux distribution:
    Debian unstable

Machine:  self-built
    AMD Phenom II X4 955
    MSI 790FX-GD70 motherboard
    4x2GB DDR3 1600

Software versions:
    libdrm-2.4.23 (built against kernel source listed above)

    mesa:  7.10-devel at commit ada9c78 (Jan. 4, 2011)
           7.11-devel at commit 69191d4 (Jan. 9, 2011)

    xorg-server-1.9.3.901

    xf86-video-ati-6.13.99 at commit f9bbb26 (Dec. 3, 2010)


  Additional Information:

This bug may be related to one or more of the following fdo bugs:

    29978  HD 3200 locks up with r600c and r600g
    31530  HD 5750 has problems with r600g
    31532  r600g lockup (no hardware mentioned)

With the Mesa I pulled from git on Jan. 4 (see above), I was able to SSH to the GPU-locked machine and try to debug with 'gdb'.  I was able to get a backtrace on /usr/bin/X, but not on the program causing the lock.  I doubt this is useful, but I am attaching it anyway.

Strangely, if I used 'strace' to attach to 'prboom' by process ID, it would prevent the GPU from hanging!  (This is why I was able to comment above that I know that r600g performance is superior to r600c on this hardware; with 'strace' attached, nothing I tried in 'prboom' would make the GPU lock!)  I tried building a debug package of 'prboom', but this (instead of the stripped binary provided by Debian) also would not lock the GPU.

Using 'torcs' always locks the GPU, and trying to attach to its PID with 'gdb' provides no information:  it simply becomes unresponsive.  (Sorry.  I tried everything I could, but maybe I'm doing it wrong.)  I was able to get 'strace' to work, but once the GPU (and kernel) locked only garbage was send to the file.  The machine runs 'fsck' after I reboot because it was not properly shutdown, so the garbage might just be random bits from the hard disk.  That file is 8.6 MB raw, and truncating the garbage and gzip'ing results in something just over 300 KB.  I don't think this bugzilla will take something that big, but if someone wants to see it I can attach it to an email.

The Mesa I pulled on Jan. 9 causes the kernel to hang once the GPU locks, so I can't even attempt to use 'gdb'; I can get 'strace' going, but the output after the lockup is random garbage.  (Please, if someone knows tricks for getting useful debugging info when a GPU locks, let me know.  It's very frustrating knowing I'm this close to superior Mesa performance, and I hate going back to r600c now that I've seen what r600g can do!!!)