http://bugs.freedesktop.org/show_bug.cgi?id=9379
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- Comment #11 from [EMAIL PROTECTED] 2007-09-05 01:42 PST -------
(Sorry for the double post, I'm a first-time bugzilla user.)
re: [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock
I have attached some heavily formatted log output, which shows drm debug
messages at the time of the hang (the messages come from the kernel log,
obtained using "modrobe drm debug=1". You can see that after the cce_idle ioctl
call, context 3 tries to lock again without unlocking first. I recompiled the
Mesa DRI driver with the DEBUG_LOCKING flag set in r128_lock.h, and found out
that this double locking behavior occurs in the depth buffer calls in
r128_span.c. Basically
/* These functions require locking */
+/*
#undef HW_LOCK
#undef HW_UNLOCK
#define HW_LOCK() LOCK_HARDWARE(R128_CONTEXT(ctx));
#define HW_UNLOCK() UNLOCK_HARDWARE(R128_CONTEXT(ctx));
+*/
/* 16-bit depth buffer functions
*/
fixed the problem for me. Apparently, the lock is taken before these functions
get called (AFAICR, r128SpanRenderStart() does the job, but I'm not sure).
re: *ERROR* r128_cce_idle called without lock held
drmP.h has a LOCK_TEST_WITH_RETURN macro, which returns -EINVAL along this
error message when the lock isn't held. Because of this, the infinite loop in
r128WaitForIdleLocked exits with ret == -EINVAL, so the actual error message is
quite misleading in this case. So, the real error is that r128WaitForIdleLocked
got called without a lock held.
I modified DEBUG_LOCK in r128_lock.h to print all lock operations to the
standard error output, and modified the code to call DEBUG_LOCK on unlocks too.
r128WaitForIdleLocked was also replaced with a macro to show where it's called
from. It turned out that sometimes r128SpanRenderFinish() is called without
calling r128SpanRenderStart() first -- so no lock is held during the call to
r128WaitForIdleLocked. I think this may be a problem with the software
fallback. Armagetron exhibits this behavior, while gl-117 calls RenderStart and
RenderFinish in pairs; lock operations also.
Using kernel 2.6.22 with drm and mesa from the freedesktop git.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
