From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: [PATCH] drm/radeon: make 64bit fences more robust Date: Mon, 10 Sep 2012 14:02:24 +0200 Message-ID: <504DD6D0.1090307@vodafone.de> References: <1347268383-4150-1-git-send-email-deathsimple@vodafone.de> <1347275537.30263.368.camel@thor.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id 26FA39F4CC for ; Mon, 10 Sep 2012 05:02:28 -0700 (PDT) In-Reply-To: <1347275537.30263.368.camel@thor.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: =?ISO-8859-1?Q?Michel_D=E4nzer?= Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 10.09.2012 13:12, Michel D=E4nzer wrote: > On Mon, 2012-09-10 at 11:13 +0200, Christian K=F6nig wrote: >> Only increase the higher 32bits if we really detect a wrap around. >> >> Fixes: >> https://bugs.freedesktop.org/show_bug.cgi?id=3D54129 >> https://bugs.freedesktop.org/show_bug.cgi?id=3D54662 >> >> Possible fixes: >> https://bugzilla.redhat.com/show_bug.cgi?id=3D846505 >> https://bugzilla.redhat.com/show_bug.cgi?id=3D845639 >> >> Signed-off-by: Christian K=F6nig >> Cc: stable@vger.kernel.org >> --- >> drivers/gpu/drm/radeon/radeon_fence.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/rad= eon/radeon_fence.c >> index 7b737b9..4781e13 100644 >> --- a/drivers/gpu/drm/radeon/radeon_fence.c >> +++ b/drivers/gpu/drm/radeon/radeon_fence.c >> @@ -160,7 +160,7 @@ void radeon_fence_process(struct radeon_device *rdev= , int ring) >> do { >> seq =3D radeon_fence_read(rdev, ring); >> seq |=3D last_seq & 0xffffffff00000000LL; >> - if (seq < last_seq) { >> + if (seq < (last_seq - 0x80000000LL)) { >> seq +=3D 0x100000000LL; >> } > Can you provide a bit more explanation for this change? In particular, > how could the code previously detect a wraparound when there was none, > and why is this the proper fix? Honestly I also don't really understand how this bug happened in the = first place. We extend the 32bit fences supported by hardware by testing if a = previously read fence value is smaller than the value we read now: > if (seq < last_seq) { But the problem seems to be that on some systems we do get fence values = that are decreasing, e.g. instead of 5, 6, 7, 8 we get 5, 7, 6, 8 (or = maybe 5, 6, 0, 7, 8 because somebody accidentally overwrites the fence = value). It might be related to a hardware bug, or the algorithm is flawed in a = way I currently don't see. Anyway the old code we had wasn't so picky = about such problems and the patch just tries to make the current code as = robust as the old code was, which indeed seems to solve the problems we see. The wrap around detection still works (tested by setting the initial = fence value to 0xfffffff0 and letting it wrap around shortly after = start), so I think it we can safely commit this. Christian.