From: "Christian König" <deathsimple@vodafone.de>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: xorg-driver-ati@lists.x.org, dri-devel@lists.freedesktop.org,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH] radeon: Fix a false positive lockup after 10s of inactivity
Date: Wed, 12 Jun 2013 13:20:34 +0200 [thread overview]
Message-ID: <51B85982.6010202@vodafone.de> (raw)
In-Reply-To: <1371032777.6131.9.camel@thor.local>
Am 12.06.2013 12:26, schrieb Michel Dänzer:
> On Die, 2013-06-11 at 16:23 -0700, Andy Lutomirski wrote:
>> If the device is idle for over ten seconds, then the next attempt to do
>> anything can race with the lockup detector and cause a bogus lockup
>> to be detected.
>>
>> Oddly, the situation is well-described in the lockup detector's comments
>> and a fix is even described. This patch implements that fix (and corrects
>> some typos in the description).
>>
>> My system has been stable for about a week running this code. Without this,
>> my screen would go blank every now and then and, when it came back, everything
>> would be remarkably slow (the latter is a separate bug).
>>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> [...]
>
>> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c b/drivers/gpu/drm/radeon/radeon_ring.c
>> index 1ef5eaa..fb7b3ea 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ring.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
>> @@ -547,12 +547,12 @@ void radeon_ring_lockup_update(struct radeon_ring *ring)
>> * have CP rptr to a different value of jiffies wrap around which will force
>> * initialization of the lockup tracking informations.
>> *
>> - * A possible false positivie is if we get call after while and last_cp_rptr ==
>> - * the current CP rptr, even if it's unlikely it might happen. To avoid this
>> - * if the elapsed time since last call is bigger than 2 second than we return
>> - * false and update the tracking information. Due to this the caller must call
>> - * radeon_ring_test_lockup several time in less than 2sec for lockup to be reported
>> - * the fencing code should be cautious about that.
>> + * A possible false positive is if we get called after a while and
>> + * last_cp_rptr == the current CP rptr, even if it's unlikely it might
>> + * happen. To avoid this if the elapsed time since the last call is bigger
>> + * than 2 second then we return false and update the tracking
>> + * information. Due to this the caller must call radeon_ring_test_lockup
>> + * more frequently than once every 2s when waiting.
> Is it guaranteed that radeon_ring_test_lockup will be called more often
> than every 2s when waiting? If not, this change might prevent a real
> lockup from being detected?
>
> Either way, I wonder if there might not be a simpler solution to the
> problem, e.g. by updating last_activity when submitting commands to a
> previously empty ring.
If I remember correctly that's exactly what I used to do when creating
radeon_ring_test_lockup, and now I'm really wondering why that stuff
isn't there any more.
Anyway the problem you describe should only happen very very rarely in
case of a wraparound, so I'm pretty sure that we have a different
problem that's just masked by that patch.
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2013-06-12 11:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 21:11 Radeon lockup on 3.8.5-201.fc18.x86_64 Andy Lutomirski
2013-04-08 14:01 ` Alex Deucher
2013-04-18 21:11 ` Andy Lutomirski
[not found] ` <CALCETrVEF5eR0kdWFP32GXeQCSnDp-5CBZU=UQyJ8L1LZAk+ww-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-18 21:12 ` Alex Deucher
[not found] ` <CADnq5_MuMipJNeBRMMuCyu=-tga7yACCS89MAgHr5XW=wjHjSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-22 23:19 ` Andy Lutomirski
2013-04-23 5:55 ` Michel Dänzer
[not found] ` <1366696504.27050.93.camel-2h6evNeVVYGs1BDpvl8NfQ@public.gmane.org>
2013-04-23 17:08 ` Andy Lutomirski
2013-04-23 17:15 ` Michel Dänzer
[not found] ` <1366737313.27050.181.camel-2h6evNeVVYGs1BDpvl8NfQ@public.gmane.org>
2013-04-23 19:31 ` Andy Lutomirski
[not found] ` <CALCETrWZpCH7tWGAHJ2PePHFivXmj8B1rxMRzJh+c27=Fz5+3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-11 23:23 ` [PATCH] radeon: Fix a false positive lockup after 10s of inactivity Andy Lutomirski
[not found] ` <abba1962f03200b03c3deb16bd3e690393f4596e.1370992898.git.luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2013-06-12 10:26 ` Michel Dänzer
2013-06-12 11:20 ` Christian König [this message]
2013-06-12 13:56 ` Jerome Glisse
2013-06-13 21:22 ` Andy Lutomirski
[not found] ` <CALCETrV_UsTiGNOmQ7BiO7mHAb3UaiPsWG_7X7HyMJ33SbNq0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-18 18:12 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51B85982.6010202@vodafone.de \
--to=deathsimple@vodafone.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=luto@amacapital.net \
--cc=michel@daenzer.net \
--cc=xorg-driver-ati@lists.x.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.