Bug 7111

Previous link doesn't work so here is working one:

http://www.liflg.org/?what=dl&catid=6&gameid=13&filename=racer_0.5.2beta8.9-english.run

Same DRM error on dmesg here, using my own OGL app.

Hardware: Ati Radeon 9200
Kernel: 2.6.17 (with gentoo patchset)
Mesa: 6.5
Xorg-server: 1.1.1
Via AGP.

Result: only mouse moves. No keyboard, no way to get back to terminal. System
still alive (can ssh). Strace shows X is in: --- SIGALRM (Alarm clock) @ 0 (0) ---.

Running the application inside a nested X (Xnest) no hang happens and app runs
without problem.

Running with DRI, lock error appears in dmesg.

Running without DRI (for example changing permissions of dri/card0), X and
computer hangs, but no drm_lock_take error appears in dmesg. So maybe my problem
is not related to DRI at all.

This own app runs correctly on nvidia based xorg-6.8.2 and xorg-server-1.0.2
computers. But as they use nvidia card cannot tell if it's an ATI driver problem.

Problem also found in two other computers with same ATI card and:
Kernel 2.6.16 - xorg 1.1.0
Kernel 2.6.15 - xorg 1.1.0

If needed I can attach strace of problematic app.

Tested with Radeon 9000 (RV250) on one of the computers with Radeon 9200 + xorg
1.1.0 and same behaviour. With DRI, drm_lock_take appears in dmesg. Without, not
info in dmesg. With both, X hangs. This time no cursor is showed.

I can confirm this: With correct permissions to /dev/dri/card0, the X server 
freezes but the mouse is still moving, and the locking message is written to 
the logfile.

When I change these permissions, it freezes too, but the locking message is 
not written. I see that the intro of racer still runs fast enough (maybe 
because of AIGLX).

Now the interesting part: I have a Mobility Radeon 9600, so I use the 
experimental r300 driver. If I start racer with the environment variable 
R300_SPAN_DISABLE_LOCKING set to 1, it runs fine.

(In reply to comment #5)
> Now the interesting part: I have a Mobility Radeon 9600, so I use the 
> experimental r300 driver. If I start racer with the environment variable 
> R300_SPAN_DISABLE_LOCKING set to 1, it runs fine.

This indicates the problem being due to a crash in a software fallback or
similar. If that's the case, killing the application should allow the X server
to continue normally, and you should try and get a backtrace of the crash (from
a remote login).

After killing racer.bin, the system continues to run normally.

I'll try to get a backtrace in a few days. How exactly do I do that? Is it ok 
to kill the X-Server with SIGSEGV or SIGABRT? Or do I have to use the debugger 
gdb?

Besides, wouldn't this be better assigned to the mesa-dev 
(mesa3d-dev@lists.sourceforge.net) mailing list?

(In reply to comment #7)
> I'll try to get a backtrace in a few days. How exactly do I do that? Is it ok 
> to kill the X-Server with SIGSEGV or SIGABRT? Or do I have to use the debugger 
> gdb?

Killing the X server certainly won't help to get a backtrace from the
application. :) Attach gdb to the app after it happens or run the app from
within gdb to boot.

Created attachment 7435 [details]
backtrace of the problem

So, here you are, but it doesn't look that promising. Note that it freezes as
soon as racer wants to switch to the main game screen.

I was able to kill racer and the system continued to run normally.

Thanks, but again, we need a backtrace from *the application*, i.e. racer in
this case.

Created attachment 7475 [details]
backtrace of racer.bin

Oops, I'm sorry about that! I should really read what other people write... o_O


Getting this was not that easy, because gdb didn't show its prompt after using
attach or when starting it with "gdb racer.bin $(pidof racer.bin)". Maybe it
couldn't stop the running process...
So I killed racer.bin with SIGSEGV (fortunately this caused it to terminate)
and I could get the backtrace from the core dump.

(In reply to comment #11)
> Getting this was not that easy, because gdb didn't show its prompt after using
> attach or when starting it with "gdb racer.bin $(pidof racer.bin)". 

Probably because it was still running at that point, in which case Ctrl-C should
have given you a prompt.

Thanks for the backtrace, it looks like the r300 driver attempts to grab the
hardware lock recursively.

Does setting the environment variable R300_SPAN_DISABLE_LOCKING for running
racer work around this?

(In reply to comment #12)
> Probably because it was still running at that point, in which case Ctrl-C 
should
> have given you a prompt.
No, Ctrl+C killed the process completely, i.e. the process no longer existed.

pmhere 
Do you still experience this issue with newer soft ?
Please check the status of your issue.

Though I am not pmhere, I want to inform you that for me this problem has been gone for a long while now. Don't know exactly with which software versions. Sorry for not posting earlier.