From: "Christian König" <deathsimple@vodafone.de>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: "Michel Dänzer" <michel@daenzer.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Deucher, Alexander" <Alexander.Deucher@amd.com>,
"Dave Airlie" <airlied@redhat.com>,
"Lauri Kasanen" <cand@gmx.com>,
"Koenig, Christian" <Christian.Koenig@amd.com>
Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume
Date: Sun, 22 Feb 2015 11:44:39 +0100 [thread overview]
Message-ID: <54E9B317.5010109@vodafone.de> (raw)
In-Reply-To: <1424560681.23181.2.camel@theros.lm.intel.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <deathsimple@vodafone.de>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
"Michel Dänzer" <michel@daenzer.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Dave Airlie" <airlied@redhat.com>,
"Lauri Kasanen" <cand@gmx.com>,
"Koenig, Christian" <Christian.Koenig@amd.com>
Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume
Date: Sun, 22 Feb 2015 11:44:39 +0100 [thread overview]
Message-ID: <54E9B317.5010109@vodafone.de> (raw)
In-Reply-To: <1424560681.23181.2.camel@theros.lm.intel.com>
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
>
>
next prev parent reply other threads:[~2015-02-22 10:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2015-02-22 10:44 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E9B317.5010109@vodafone.de \
--to=deathsimple@vodafone.de \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=airlied@redhat.com \
--cc=cand@gmx.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
--cc=ross.zwisler@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.