[Bug 33139] New: Radeon HD 5750 locks up when using 3D apps with r600g

* [Bug 33139] New: Radeon HD 5750 locks up when using 3D apps with r600g
@ 2011-01-15  3:13 bugzilla-daemon
  2011-01-15  3:20 ` [Bug 33139] " bugzilla-daemon
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: bugzilla-daemon @ 2011-01-15  3:13 UTC (permalink / raw)
  To: dri-devel

https://bugs.freedesktop.org/show_bug.cgi?id=33139

           Summary: Radeon HD 5750 locks up when using 3D apps with r600g
           Product: Mesa
           Version: git
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r600
        AssignedTo: dri-devel@lists.freedesktop.org
        ReportedBy: dawitbro@sbcglobal.net

Created an attachment (id=42065)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=42065)
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!!!)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread