On Mon, Dec 3, 2012 at 7:44 AM, Michel Dänzer <[email protected]> wrote: > On Fre, 2012-11-30 at 15:08 -0500, [email protected] wrote: >> From: Jerome Glisse <[email protected]> >> >> 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 <[email protected]> >> --- >> 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 _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
