Message-ID: <A3397C8B8B789E45844E7EC5DEAD89D06360AF62@satlexdag05.amd.com>
Date:	Wed, 18 Feb 2015 14:13:40 +0000
From:	"Deucher, Alexander" <Alexander.Deucher@....com>
To:	Christian König <deathsimple@...afone.de>,
	"Ross Zwisler" <ross.zwisler@...ux.intel.com>
CC:	Michel Dänzer <michel@...nzer.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"Dave Airlie" <airlied@...hat.com>, Lauri Kasanen <cand@....com>,
	"Koenig, Christian" <Christian.Koenig@....com>
Subject: RE: [PATCH] drm/radeon: Fix regression with suspend/resume

> -----Original Message-----
> From: Christian König [mailto:deathsimple@...afone.de]
> Sent: Wednesday, February 18, 2015 7:02 AM
> To: Ross Zwisler; Deucher, Alexander
> Cc: Michel Dänzer; linux-kernel@...r.kernel.org; dri-
> devel@...ts.freedesktop.org; Dave Airlie; Lauri Kasanen; Koenig, Christian
> Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume
> 
> On 17.02.2015 18:49, Ross Zwisler wrote:
> > On Sat, 2015-02-14 at 06:25 +0000, Deucher, Alexander wrote:
> >>> -----Original Message-----
> >>> From: Ross Zwisler [mailto:ross.zwisler@...ux.intel.com]
> >>> Sent: Friday, February 13, 2015 10:55 PM
> >>> To: Michel Dänzer
> >>> Cc: linux-kernel@...r.kernel.org; dri-devel@...ts.freedesktop.org;
> Deucher,
> >>> Alexander; Dave Airlie; Lauri Kasanen; Koenig, Christian
> >>> Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume
> >>>
> >>> On Fri, 2015-02-13 at 11:41 +0900, Michel Dänzer wrote:
> >>>> On 13.02.2015 05:30, Ross Zwisler wrote:
> >>>>> This patch reverts the changes made in this commit:
> >>>>>
> >>>>>    deadcb36f49b ("drm/radeon: Use two-ended allocation by size, v2")
> >>>>>
> >>>>> That patch caused a regression on my system where the bottom of
> the
> >>>>> screen flickers after my laptop goes thorough a suspend and resume.
> >>>> What kind of flicker is it? E.g. does it only affect X or also console,
> >>>> does it flicker all the time or only when there is activity, what does
> >>>> it look like, ...
> >>> It's kind of hard to describe it precisely, so I made a video.  :)
> >>>
> >>> http://youtu.be/ESm9SMnr0do
> >>>
> >>> It only affects X, not the console, and it seems to go away if you log
> >>> out back to the login manager (I'm using GDM on Fedora 20) and back
> into
> >>> your window manager.
> >> Does a VT switch or forcing a dpms cycle (sleep 5; xset dpms force off)
> >> also fix it?  It doesn't look related to the patch in question at all.
> >> Is the flickering 100% reproducible or does it only happen
> >> periodically?
> >  From kernels 3.14 or so (when the deadcb36f49b patch was introduced)
> > till 3.18 it happened 100% of the time.  With 3.19 it only seems to
> > happen maybe 50% of the time, but is still very easily reproducible.
> 
> Well, what the patch does is just changing where buffers are placed in
> memory. E.g. now we place the buffer at the end of memory as well.
> 
> So I can imagine at least three possible causes for the issues you see:
> 1. We haven't implemented all buffer placement restrictions correctly
> and without the patch everything just works fine by coincident.
> 2. Something is overwriting the buffer at it's new location.
> @Alex&Michel: Didn't we had a similar problem internally recently? Or
> was that just for APUs?

I think that was just two engines trying to use the same memory location for writeback since we had not properly allocated a writeback slot.

What's odd to me is that the region is actively flickering, it looks almost like a display timing issue.  I would expect static corruption unless something else is actively writing to the region.

Alex

> 3. One of the memory chips on your hardware is faulty and without the
> patch the we just don't use the affected region (rather unlikely).
> 
> For testing could you try to limit the amount of VRAM used? E.g. give
> radeon.vramlimit=256 as kernel commandline to limit the VRAM to the
> first 256MB.
> 
> Regards,
> Christian.
> 
> >
> > It's entirely possible that the patch isn't the root cause, but it just
> > brought out a bug somewhere else.  All I know is that I did a bisect,
> > and with the commit before this the issue never happens, and after this
> > commit it happens 100% of the time. :)  Also, reverting that commit with
> > 3.19 makes the issue go away.
> >
> > Nope, "xset dpms force off" doesn't fix it. After the screen goes black
> > and comes back, the flicker is still there.
> >
> > - Ross
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@...ts.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

Powered by blists - more mailing lists