[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