Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752133AbbBRMJF (ORCPT ); Wed, 18 Feb 2015 07:09:05 -0500 Received: from pegasos-out.vodafone.de ([80.84.1.38]:42789 "EHLO pegasos-out.vodafone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751221AbbBRMJD (ORCPT ); Wed, 18 Feb 2015 07:09:03 -0500 X-Greylist: delayed 387 seconds by postgrey-1.27 at vger.kernel.org; Wed, 18 Feb 2015 07:09:02 EST X-Spam-Flag: NO X-Spam-Score: -0.054 Authentication-Results: rohrpostix2.prod.vfnet.de (amavisd-new); dkim=pass header.i=@vodafone.de X-DKIM: OpenDKIM Filter v2.6.8 pegasos-out.vodafone.de 0D6A2E65FA Message-ID: <54E47F4F.9090500@vodafone.de> Date: Wed, 18 Feb 2015 13:02:23 +0100 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ross Zwisler , "Deucher, Alexander" CC: =?UTF-8?B?TWljaGVsIETDpG56ZXI=?= , "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 References: <1423773026-5941-1-git-send-email-ross.zwisler@linux.intel.com> <54DD6469.9060809@daenzer.net> <1423886115.5037.12.camel@theros.lm.intel.com> <1424195346.12687.6.camel@theros.lm.intel.com> In-Reply-To: <1424195346.12687.6.camel@theros.lm.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3482 Lines: 77 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/