[Bug 33139] New: Radeon HD 5750 locks up when using 3D apps with r600g
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Jan 14 19:13:27 PST 2011
Summary: Radeon HD 5750 locks up when using 3D apps with r600g
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: dawitbro at sbcglobal.net
Created an attachment (id=42065)
Backtrace of /usr/bin/X once GPU was locked
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.
Steps to reproduce:
1. Stop X and install r600g Mesa drivers.
2. Start X and run a program using 3D (prboom, torcs, etc.)
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
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.)
GPU: Powercolor Radeon HD 5750 SCS 1GB
Kernel: 2.6.37 + cherry-pick drm-core-next 17db7042 (Jan. 4, 2011)
AMD Phenom II X4 955
MSI 790FX-GD70 motherboard
4x2GB DDR3 1600
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)
xf86-video-ati-6.13.99 at commit f9bbb26 (Dec. 3, 2010)
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.
More information about the dri-devel