Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752025AbbBVKos (ORCPT ); Sun, 22 Feb 2015 05:44:48 -0500 Received: from pegasos-out.vodafone.de ([80.84.1.38]:54045 "EHLO pegasos-out.vodafone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751671AbbBVKoq (ORCPT ); Sun, 22 Feb 2015 05:44:46 -0500 X-Spam-Flag: NO X-Spam-Score: -0.053 Authentication-Results: rohrpostix1.prod.vfnet.de (amavisd-new); dkim=pass header.i=@vodafone.de X-DKIM: OpenDKIM Filter v2.6.8 pegasos-out.vodafone.de D55FB26068A Message-ID: <54E9B317.5010109@vodafone.de> Date: Sun, 22 Feb 2015 11:44:39 +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 CC: "Deucher, Alexander" , =?UTF-8?B?TWljaGVsIA==?= =?UTF-8?B?RMOkbnplcg==?= , "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> <54E47F4F.9090500@vodafone.de> <1424560681.23181.2.camel@theros.lm.intel.com> In-Reply-To: <1424560681.23181.2.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: 1541 Lines: 40 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 > > -- 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/