RE: [PATCH] drm/radeon: Fix regression with suspend/resume
From: Deucher, Alexander
Date: Wed Feb 18 2015 - 09:29:19 EST
> -----Original Message-----
> From: Christian KÃnig [mailto:deathsimple@xxxxxxxxxxx]
> Sent: Wednesday, February 18, 2015 7:02 AM
> To: Ross Zwisler; Deucher, Alexander
> Cc: Michel DÃnzer; linux-kernel@xxxxxxxxxxxxxxx; dri-
> devel@xxxxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxxxxxxx]
> >>> Sent: Friday, February 13, 2015 10:55 PM
> >>> To: Michel DÃnzer
> >>> Cc: linux-kernel@xxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx;
> >>> 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
> >>>>> 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
> >>> 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.
> 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.
> > 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@xxxxxxxxxxxxxxxxxxxxx
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel