[Openchrome-users] "Reclaim buffers locked deadlock"

[Paul Bender]

Thomas Hellstr?m wrote:
> Thomas Hellstr?m wrote:
>> 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
>>
>>   
> Hmm,
> I also get this problem, but only when the X server tries to launch AIGLX.
> The following line in Xorg.conf's ServerLayout section gets rid of the 
> message for me:
> 
> Option "AIGLX" "false"
> 
> Does anybody see the kernel message with this line in the conf file?
> In that case, could you please mail your Xorg.conf and 
> /var/log/Xorg.0.log file (gzipped) to the list?
> 
> Regards,
> Thomas

I have not seen this problem since updating to Xorg 7.2RC3 (with AIGLX 
disabled at compile time).