[PATCH] radeon: avoid copying over itself ddx fb

Jerome Glisse j.glisse at gmail.com
Tue Dec 4 08:06:42 PST 2012


On Mon, Dec 3, 2012 at 7:44 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On Fre, 2012-11-30 at 15:08 -0500, j.glisse at gmail.com wrote:
>> From: Jerome Glisse <jglisse at redhat.com>
>>
>> In some rare case it seems that the old fb could already be the
>> ddx fb. As copying from the same bo will trigger a ttm deadlck
>> detection which will result in infinite kernel/userspace loop.
>> Avoid doing any copy as anyway it's useless.
>>
>> Signed-off-by: Jerome Glisse <jglisse at redhat.com>
>> ---
>>  src/drmmode_display.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
>> index dc608de..15407fe 100644
>> --- a/src/drmmode_display.c
>> +++ b/src/drmmode_display.c
>> @@ -292,6 +292,15 @@ void drmmode_copy_fb(ScrnInfoPtr pScrn, drmmode_ptr drmmode)
>>       if (!fbcon_id)
>>               goto fallback;
>>
>> +     if (fbcon_id == drmmode->fb_id) {
>> +             /* in some rare case there might be no fbcon and we might already
>> +              * be the one with the current fb to avoid a false deadlck in
>> +              * kernel ttm code just do nothing as anyway there is nothing
>> +              * to do
>> +              */
>> +             return;
>> +     }
>
> Looks good to me, assuming there's no better way to avoid getting into
> this situation in the first place.

I try to find out how this can happen but it's painfull, only happens
a couple time over hundred of suspend/resume cycle, it might be a race
somewhere else. I would rather had the kernel solution but Dave is not
a fan of it.

Cheers,
Jerome


More information about the xorg-driver-ati mailing list