* [PATCH] drm/radeon: Fix regression with suspend/resume
@ 2015-02-12 20:30 Ross Zwisler
2015-02-13 2:41 ` Michel Dänzer
0 siblings, 1 reply; 15+ messages in thread
From: Ross Zwisler @ 2015-02-12 20:30 UTC (permalink / raw)
To: linux-kernel
Cc: Ross Zwisler, Lauri Kasanen, Christian König, Dave Airlie,
Alex Deucher, dri-devel
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.
This is reproducible 100% of the time.
This patch applies cleanly to v3.19, and fixes the screen flicker issue
on my system. Here is the hardware that I'm using (from lspci):
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Lauri Kasanen <cand@gmx.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_object.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index 86fc564..dea1baf 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -173,17 +173,6 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
else
rbo->placements[i].lpfn = 0;
}
-
- /*
- * Use two-ended allocation depending on the buffer size to
- * improve fragmentation quality.
- * 512kb was measured as the most optimal number.
- */
- if (rbo->tbo.mem.size > 512 * 1024) {
- for (i = 0; i < c; i++) {
- rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
- }
- }
}
int radeon_bo_create(struct radeon_device *rdev,
--
1.9.3
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-12 20:30 [PATCH] drm/radeon: Fix regression with suspend/resume Ross Zwisler @ 2015-02-13 2:41 ` Michel Dänzer 0 siblings, 0 replies; 15+ messages in thread From: Michel Dänzer @ 2015-02-13 2:41 UTC (permalink / raw) To: Ross Zwisler Cc: linux-kernel, dri-devel, Alex Deucher, Dave Airlie, Lauri Kasanen, Christian König 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, ... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume @ 2015-02-13 2:41 ` Michel Dänzer 0 siblings, 0 replies; 15+ messages in thread From: Michel Dänzer @ 2015-02-13 2:41 UTC (permalink / raw) To: Ross Zwisler Cc: linux-kernel, dri-devel, Alex Deucher, Dave Airlie, Lauri Kasanen, Christian König 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, ... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-13 2:41 ` Michel Dänzer (?) @ 2015-02-14 3:55 ` Ross Zwisler 2015-02-14 6:25 ` Deucher, Alexander -1 siblings, 1 reply; 15+ messages in thread From: Ross Zwisler @ 2015-02-14 3:55 UTC (permalink / raw) To: Michel Dänzer Cc: linux-kernel, dri-devel, Alex Deucher, Dave Airlie, Lauri Kasanen, Christian König 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. I've tested with OpenBox, Gnome and KDE, and it happens in all three, so it doesn't appear to be related to the window manager. It does appear to flicker more if you move the mouse, but it still does flicker occasionally if you aren't doing anything. ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-14 3:55 ` Ross Zwisler @ 2015-02-14 6:25 ` Deucher, Alexander 0 siblings, 0 replies; 15+ messages in thread From: Deucher, Alexander @ 2015-02-14 6:25 UTC (permalink / raw) To: Ross Zwisler, Michel Dänzer Cc: linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1865 bytes --] > -----Original Message----- > From: Ross Zwisler [mailto:ross.zwisler@linux.intel.com] > Sent: Friday, February 13, 2015 10:55 PM > To: Michel Dänzer > Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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? Alex > > I've tested with OpenBox, Gnome and KDE, and it happens in all three, so > it doesn't appear to be related to the window manager. > > It does appear to flicker more if you move the mouse, but it still does > flicker occasionally if you aren't doing anything. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] drm/radeon: Fix regression with suspend/resume @ 2015-02-14 6:25 ` Deucher, Alexander 0 siblings, 0 replies; 15+ messages in thread From: Deucher, Alexander @ 2015-02-14 6:25 UTC (permalink / raw) To: Ross Zwisler, Michel Dänzer Cc: Dave Airlie, Lauri Kasanen, linux-kernel, dri-devel, Koenig, Christian > -----Original Message----- > From: Ross Zwisler [mailto:ross.zwisler@linux.intel.com] > Sent: Friday, February 13, 2015 10:55 PM > To: Michel Dänzer > Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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? Alex > > I've tested with OpenBox, Gnome and KDE, and it happens in all three, so > it doesn't appear to be related to the window manager. > > It does appear to flicker more if you move the mouse, but it still does > flicker occasionally if you aren't doing anything. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-14 6:25 ` Deucher, Alexander @ 2015-02-17 17:49 ` Ross Zwisler -1 siblings, 0 replies; 15+ messages in thread From: Ross Zwisler @ 2015-02-17 17:49 UTC (permalink / raw) To: Deucher, Alexander Cc: Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian On Sat, 2015-02-14 at 06:25 +0000, Deucher, Alexander wrote: > > -----Original Message----- > > From: Ross Zwisler [mailto:ross.zwisler@linux.intel.com] > > Sent: Friday, February 13, 2015 10:55 PM > > To: Michel Dänzer > > Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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. 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume @ 2015-02-17 17:49 ` Ross Zwisler 0 siblings, 0 replies; 15+ messages in thread From: Ross Zwisler @ 2015-02-17 17:49 UTC (permalink / raw) To: Deucher, Alexander Cc: Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian On Sat, 2015-02-14 at 06:25 +0000, Deucher, Alexander wrote: > > -----Original Message----- > > From: Ross Zwisler [mailto:ross.zwisler@linux.intel.com] > > Sent: Friday, February 13, 2015 10:55 PM > > To: Michel Dänzer > > Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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. 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-17 17:49 ` Ross Zwisler @ 2015-02-18 12:02 ` Christian König -1 siblings, 0 replies; 15+ messages in thread From: Christian König @ 2015-02-18 12:02 UTC (permalink / raw) To: Ross Zwisler, Deucher, Alexander Cc: Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian 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@linux.intel.com] >>> Sent: Friday, February 13, 2015 10:55 PM >>> To: Michel Dänzer >>> Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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? 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume @ 2015-02-18 12:02 ` Christian König 0 siblings, 0 replies; 15+ messages in thread From: Christian König @ 2015-02-18 12:02 UTC (permalink / raw) To: Ross Zwisler, Deucher, Alexander Cc: Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian 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@linux.intel.com] >>> Sent: Friday, February 13, 2015 10:55 PM >>> To: Michel Dänzer >>> Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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? 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-18 12:02 ` Christian König @ 2015-02-18 14:13 ` Deucher, Alexander -1 siblings, 0 replies; 15+ messages in thread From: Deucher, Alexander @ 2015-02-18 14:13 UTC (permalink / raw) To: Christian König, Ross Zwisler Cc: Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4262 bytes --] > -----Original Message----- > From: Christian König [mailto:deathsimple@vodafone.de] > Sent: Wednesday, February 18, 2015 7:02 AM > To: Ross Zwisler; Deucher, Alexander > Cc: Michel Dänzer; linux-kernel@vger.kernel.org; dri- > devel@lists.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@linux.intel.com] > >>> Sent: Friday, February 13, 2015 10:55 PM > >>> To: Michel Dänzer > >>> Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH] drm/radeon: Fix regression with suspend/resume @ 2015-02-18 14:13 ` Deucher, Alexander 0 siblings, 0 replies; 15+ messages in thread From: Deucher, Alexander @ 2015-02-18 14:13 UTC (permalink / raw) To: Christian König, Ross Zwisler Cc: Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian > -----Original Message----- > From: Christian König [mailto:deathsimple@vodafone.de] > Sent: Wednesday, February 18, 2015 7:02 AM > To: Ross Zwisler; Deucher, Alexander > Cc: Michel Dänzer; linux-kernel@vger.kernel.org; dri- > devel@lists.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@linux.intel.com] > >>> Sent: Friday, February 13, 2015 10:55 PM > >>> To: Michel Dänzer > >>> Cc: linux-kernel@vger.kernel.org; dri-devel@lists.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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-18 12:02 ` Christian König (?) (?) @ 2015-02-21 23:18 ` Ross Zwisler 2015-02-22 10:44 ` Christian König -1 siblings, 1 reply; 15+ messages in thread From: Ross Zwisler @ 2015-02-21 23:18 UTC (permalink / raw) To: Christian König Cc: Deucher, Alexander, Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian On Wed, 2015-02-18 at 13:02 +0100, Christian König wrote: > 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? > 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. Tried with the kernel parameter radeon.vramlimit=256, and it seemed to have the exact same behavior. The flicker was still there, same size, same frequency. Thanks, - Ross ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume 2015-02-21 23:18 ` Ross Zwisler @ 2015-02-22 10:44 ` Christian König 0 siblings, 0 replies; 15+ messages in thread From: Christian König @ 2015-02-22 10:44 UTC (permalink / raw) To: Ross Zwisler Cc: Deucher, Alexander, Michel Dänzer, linux-kernel, dri-devel, Dave Airlie, Lauri Kasanen, Koenig, Christian On 22.02.2015 00:18, Ross Zwisler wrote: > On Wed, 2015-02-18 at 13:02 +0100, Christian König wrote: >> 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? >> 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. > Tried with the kernel parameter radeon.vramlimit=256, and it seemed to have > the exact same behavior. The flicker was still there, same size, same > frequency. Well how much memory does the card have in the first place? 256MB was just an example. Please provide a complete dmesg output with that paramater. Regards, Christian. > > Thanks, > - Ross > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] drm/radeon: Fix regression with suspend/resume @ 2015-02-22 10:44 ` Christian König 0 siblings, 0 replies; 15+ messages in thread From: Christian König @ 2015-02-22 10:44 UTC (permalink / raw) To: Ross Zwisler Cc: Michel Dänzer, linux-kernel, dri-devel, Deucher, Alexander, Dave Airlie, Lauri Kasanen, Koenig, Christian On 22.02.2015 00:18, Ross Zwisler wrote: > On Wed, 2015-02-18 at 13:02 +0100, Christian König wrote: >> 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? >> 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. > Tried with the kernel parameter radeon.vramlimit=256, and it seemed to have > the exact same behavior. The flicker was still there, same size, same > frequency. Well how much memory does the card have in the first place? 256MB was just an example. Please provide a complete dmesg output with that paramater. Regards, Christian. > > Thanks, > - Ross > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-02-22 10:44 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-12 20:30 [PATCH] drm/radeon: Fix regression with suspend/resume Ross Zwisler 2015-02-13 2:41 ` Michel Dänzer 2015-02-13 2:41 ` Michel Dänzer 2015-02-14 3:55 ` Ross Zwisler 2015-02-14 6:25 ` Deucher, Alexander 2015-02-14 6:25 ` Deucher, Alexander 2015-02-17 17:49 ` Ross Zwisler 2015-02-17 17:49 ` Ross Zwisler 2015-02-18 12:02 ` Christian König 2015-02-18 12:02 ` Christian König 2015-02-18 14:13 ` Deucher, Alexander 2015-02-18 14:13 ` Deucher, Alexander 2015-02-21 23:18 ` Ross Zwisler 2015-02-22 10:44 ` Christian König 2015-02-22 10:44 ` Christian König
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.