From: "Michel Dänzer" <michel@daenzer.net>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Christian König" <christian.koenig@amd.com>,
DRI <dri-devel@lists.freedesktop.org>
Subject: Re: Long radeon stalls on recent kernels
Date: Wed, 10 Dec 2014 18:44:37 +0900 [thread overview]
Message-ID: <54881605.9080709@daenzer.net> (raw)
In-Reply-To: <CALCETrV6bm_g2j7EEp6cgRP4HgbUTRC5v2T4y-bQLg6NzqSnMw@mail.gmail.com>
On 10.12.2014 06:39, Andy Lutomirski wrote:
> On Tue, Dec 9, 2014 at 8:06 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Tue, Dec 9, 2014 at 1:18 AM, Michel Dänzer <michel@daenzer.net> wrote:
>>> On 09.12.2014 09:24, Andy Lutomirski wrote:
>>>>
>>>> The relevant line from latencytop seems to be:
>>>>
>>>> 154 20441402 489139 radeon_fence_default_wait [radeon]
>>>> fence_wait_timeout ttm_bo_wait [ttm] ttm_bo_move_accel_cleanup [ttm]
>>>> radeon_move_blit.isra.12 [radeon] radeon_bo_move [radeon]
>>>> ttm_bo_handle_move_mem [ttm] ttm_bo_evict [ttm] ttm_mem_evict_first
>>>> [ttm] ttm_bo_mem_space [ttm] ttm_bo_validate [ttm]
>>>> radeon_bo_fault_reserve_notify [radeon]
>>>
>>> Which process is this?
>>
>> Xorg
>>
>>>
>>> Looks like CPU access to a BO in VRAM, but the BO is located outside of
>>> the CPU visible area of VRAM, so it has to be moved into the CPU visible
>>> area first.
>>>
>>> Which version of Mesa are you using?
>>>
>>
>> mesa-dri-drivers-10.3.3-1.20141110.fc20.x86_64
>>
>> I'm planning on upgrading to Fedora 21 fairly soon.
>
> Upgrading to mesa-dri-drivers-10.3.3-1.20141110.fc21.x86_64 seems to
> have helped enough that my usual test (open a couple of Firefox tabs
> with graphics in them) doesn't hang anymore.
Hmm, since that looks like the exact same upstream version, maybe it was
actually upgrading something else that made the difference?
> This card still isn't *fast*.
I'm afraid it wasn't exactly a high-end card even when it was new. What
kind of operations are slow?
> Is there some way I can check that I'm actually using all 16 PCIe lanes?
> In my tinkering w/ power management settings, I got some odd logs
> suggesting that only one lane was in use.
You can try forcing off ASPM with radeon.aspm=0, other than that I'm not
sure.
> But I'm still waiting for the day that buggy userspace *can't* cause
> kernel graphics stalls.
Actually, this looks more like buggy userspace stalling itself. :)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-12-10 9:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 22:21 Long radeon stalls on recent kernels Andy Lutomirski
2014-11-17 9:51 ` Michel Dänzer
2014-11-19 0:21 ` Andy Lutomirski
2014-11-19 0:34 ` Andy Lutomirski
2014-11-19 0:50 ` Andy Lutomirski
2014-11-19 7:19 ` Michel Dänzer
2014-11-20 0:07 ` Andy Lutomirski
2014-11-20 0:58 ` Andy Lutomirski
2014-11-26 6:42 ` Michel Dänzer
2014-11-26 15:38 ` Andy Lutomirski
2014-12-09 0:24 ` Andy Lutomirski
2014-12-09 9:18 ` Michel Dänzer
2014-12-09 16:06 ` Andy Lutomirski
2014-12-09 21:39 ` Andy Lutomirski
2014-12-10 9:44 ` Michel Dänzer [this message]
2014-12-10 20:28 ` Andy Lutomirski
2014-12-11 4:24 ` Michel Dänzer
2014-12-11 5:13 ` Andy Lutomirski
2014-12-16 8:00 ` Michel Dänzer
2014-12-10 14:56 ` Alex Deucher
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=54881605.9080709@daenzer.net \
--to=michel@daenzer.net \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=luto@amacapital.net \
/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.