[Openchrome-users] "Reclaim buffers locked deadlock"

[Thomas Hellström]

Paul Bender wrote:

>Thomas Hellstr?m wrote:
>  
>
>>Benno Schulenberg wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>Today I've upgraded from kernel 2.6.17 to 2.6.18, plus the latest drm from git,
>>>and the latest libdrm.  When X is starting up there is now a pause of several
>>>seconds before the cursor first appears, and in the kernel log there's this:
>>>
>>>Nov 11 23:48:31 ordesa kernel: [drm:drm_release] *ERROR* Reclaim buffers locked deadlock.
>>>Nov 11 23:48:31 ordesa kernel: [drm:drm_release] *ERROR* This is probably a single thread having multiple
>>>Nov 11 23:48:31 ordesa kernel: [drm:drm_release] *ERROR* DRM file descriptors open either dying or closing file descriptors
>>>Nov 11 23:48:31 ordesa kernel: [drm:drm_release] *ERROR* while having the lock. I will not reclaim buffers.
>>>Nov 11 23:48:31 ordesa kernel: [drm:drm_release] *ERROR* Locking context is 0x00000001
>>>Nov 11 23:48:34 ordesa kernel: [drm:drm_release] *ERROR* Reclaim buffers locked deadlock.
>>>Nov 11 23:48:34 ordesa kernel: [drm:drm_release] *ERROR* This is probably a single thread having multiple
>>>Nov 11 23:48:34 ordesa kernel: [drm:drm_release] *ERROR* DRM file descriptors open either dying or closing file descriptors
>>>Nov 11 23:48:34 ordesa kernel: [drm:drm_release] *ERROR* while having the lock. I will not reclaim buffers.
>>>Nov 11 23:48:34 ordesa kernel: [drm:drm_release] *ERROR* Locking context is 0x00000001
>>>
>>>Anyone else seeing this?  Should I maybe be using the in-kernel drm instead?
>>>
>>>Benno
>>>
>>>      
>>>
>>Hi,
>>
>>This should be happening with AIGLX. Either someone has to fix up AIGLX 
>>or we have to move away all drm drivers from using reclaim_buffers_locked.
>>
>>It might be that the latest xserver git with Dave Airlies fix to load 
>>the system libdrm instead of the xserver built-in libdrm fixes this.
>>
>>The reason it doesn't hang with the old drm is a pure coincidence.
>>
>>/Thomas
>>    
>>
>
>Unfortunately, this does not appear to be the case. I grabbed libdrm 
>2.3.0 (as well as the drm from git corresponding to the 2.3.0 tag) and 
>the patches from Dave Airlies' bug report. I applied the patches to the 
>xorg-xserver from Xorg 7.2RC2 and built MiniMyth with this patched Xorg 
>7.2RC2. The error still occurs.
>
>In addition, disabling AIGLX and Composite at either compilation or run 
>time does not appear to help.
>
>_______________________________________________
>openchrome-users mailing list
>openchrome-users at openchrome.org
>http://wiki.openchrome.org/mailman/listinfo/openchrome-users
>Main page:
>http://www.openchrome.org
>Wiki:
>http://wiki.openchrome.org
>User Forum:
>http://wiki.openchrome.org/tikiwiki/tiki-view_forum.php?forumId=1
>
>
>  
>
OK. I'll have a look at this next week. It should not only affect the 
via drivers but also all drivers using reclaim_buffers_locked.

What appears to be happening is the following:
When an open file descriptor to drm is closed, drm tries to reclaim 
allocated memory regions that belongs to the client having the file 
open. To do that it must hold the hardware lock, and therefore it either 
checks whether the lock belongs to the current file descriptor or waits 
for the lock to be released. In this case, the lock is held by the X 
server and is therefore never released, since the X server is 
single-threaded and stuck in a system call. But the lock was taken using 
a different file descriptor, so DRM doesn't recognize the lock as its own.

So to sum up, it seems that the X server has two open files to drm. It 
has grabbed the lock through one of them, and tries to close the other. 
I (apparently wrongly) assumed that the "other" was AIGLX. If someone 
can track down where this X server close operation occurs that would be 
of great help, as I currently don't have access to any VIA systems.

/Thomas