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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel