From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752006AbbBUXSH (ORCPT ); Sat, 21 Feb 2015 18:18:07 -0500 Received: from mga09.intel.com ([134.134.136.24]:10335 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751730AbbBUXSE (ORCPT ); Sat, 21 Feb 2015 18:18:04 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,622,1418112000"; d="scan'208";a="688888777" Message-ID: <1424560681.23181.2.camel@theros.lm.intel.com> Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume From: Ross Zwisler 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" Date: Sat, 21 Feb 2015 16:18:01 -0700 In-Reply-To: <54E47F4F.9090500@vodafone.de> 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20.rez) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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