From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Zwisler Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume Date: Sat, 21 Feb 2015 16:18:01 -0700 Message-ID: <1424560681.23181.2.camel@theros.lm.intel.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <54E47F4F.9090500@vodafone.de> Sender: linux-kernel-owner@vger.kernel.org To: Christian =?ISO-8859-1?Q?K=F6nig?= Cc: "Deucher, Alexander" , Michel =?ISO-8859-1?Q?D=E4nzer?= , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Dave Airlie , Lauri Kasanen , "Koenig, Christian" List-Id: dri-devel@lists.freedesktop.org On Wed, 2015-02-18 at 13:02 +0100, Christian K=C3=B6nig wrote: > Well, what the patch does is just changing where buffers are placed i= n=20 > memory. E.g. now we place the buffer at the end of memory as well. >=20 > So I can imagine at least three possible causes for the issues you se= e: > 1. We haven't implemented all buffer placement restrictions correctly= =20 > and without the patch everything just works fine by coincident. > 2. Something is overwriting the buffer at it's new location.=20 > @Alex&Michel: Didn't we had a similar problem internally recently? Or= =20 > was that just for APUs? > 3. One of the memory chips on your hardware is faulty and without the= =20 > patch the we just don't use the affected region (rather unlikely). >=20 > For testing could you try to limit the amount of VRAM used? E.g. give= =20 > radeon.vramlimit=3D256 as kernel commandline to limit the VRAM to the= =20 > first 256MB. Tried with the kernel parameter radeon.vramlimit=3D256, and it seemed t= o have the exact same behavior. The flicker was still there, same size, same frequency. Thanks, - Ross