From: "Christian König" <christian.koenig@amd.com>
To: "Michel Dänzer" <michel@daenzer.net>,
"Alex Deucher" <alexdeucher@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/3] drm/radeon: stop poisoning the GART TLB
Date: Sun, 29 Jun 2014 12:34:50 +0200 [thread overview]
Message-ID: <53AFEBCA.4060307@amd.com> (raw)
In-Reply-To: <53AD3261.9020206@daenzer.net>
[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]
Am 27.06.2014 10:59, schrieb Michel Dänzer:
> On 27.06.2014 17:26, Christian König wrote:
>> Am 27.06.2014 04:31, schrieb Michel Dänzer:
>>> On 25.06.2014 12:59, Michel Dänzer wrote:
>>>> With these patches, 3.15 just survived two piglit runs on my Bonaire,
>>>> one with the GART poisoning fix and one without. It never survived a
>>>> single run before.
>>>>
>>>> Acked-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
>>> So, are these patches going to 3.16 and 3.15?
>> We could send them in for 3.15,
> What's the alternative for 3.15?
Well, figuring out what's the real reason behind those lockups would be
a good start :)
> Looks like e.g. https://bugs.freedesktop.org/show_bug.cgi?id=80141 is
> confirmed to be this.
>
>
>> but for 3.16 we have some new features that depend on the new code.
>>
>> We could backport them to the old code, but I really want to work on
>> figuring out what's wrong with the new approach instead.
>>
>> Going to prepare a branch for you to test over the weekend, would be
>> nice if you could give it a try on Monday and see if that fixes the
>> issues as well.
> Sure, will do.
I've just pushed the branch testing-3.15 to
git://people.freedesktop.org/~deathsimple/linux. It's based on 3.15.2
and contains the "stop poisoning the GART TLB" patch backported to 3.15
and a couple of things that I would like to try.
I've disabled the redirection of page faults to the dummy page for now
and so the system should lockup on the first page fault it encounters.
Apart from that the page directory and page tables are now completely
over allocated and over aligned.
Setting the READABLE bit on invalid entries shouldn't have an effect
other than making those entries non zero. So please try to lockup your
bonaire with this branch and as soon as you encounter the first page
fault take a look at VM_CONTEXT1_PROTECTION_FAULT_STATUS and figure out
which VMID caused the lockup.
Then use the attached script to make a dump from the complete page
directory and page table of the VMID in question. E.g. "./dump_vm.sh 1"
if the lockup was caused by VMID 1 etc... Make sure you've got a
radeontool that supports CIK, otherwise it would only return zeros as
page directory address.
Since even the invalid page table entries should now have at least the
READABLE bit set there shouldn't be anything zero in this dump and look
out for anything else suspicious as well (0xdeadbeef etc...).
Thanks for the help,
Christian.
[-- Attachment #2: dump_vm.sh --]
[-- Type: application/x-shellscript, Size: 562 bytes --]
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-06-29 10:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 13:29 [PATCH 1/3] drm/radeon: stop poisoning the GART TLB Christian König
2014-06-04 13:29 ` [PATCH 2/3] drm/radeon: remove range check from *_gart_set_page Christian König
2014-06-04 13:29 ` [PATCH 3/3] drm/radeon: use the SDMA on for buffer moves on CIK again Christian König
2014-06-04 13:46 ` [PATCH 1/3] drm/radeon: stop poisoning the GART TLB Alex Deucher
2014-06-04 13:50 ` Christian König
2014-06-10 23:30 ` Marek Olšák
2014-06-11 9:29 ` Christian König
2014-06-11 10:56 ` Marek Olšák
2014-06-12 11:23 ` Christian König
2014-06-13 13:19 ` Marek Olšák
2014-06-13 15:45 ` Christian König
2014-06-13 21:31 ` Alex Deucher
2014-06-15 12:48 ` Christian König
2014-06-19 1:48 ` Michel Dänzer
2014-06-19 9:45 ` Christian König
2014-06-23 8:15 ` Michel Dänzer
2014-06-23 9:56 ` Christian König
2014-06-24 6:49 ` Michel Dänzer
2014-06-24 10:14 ` Christian König
2014-06-25 3:59 ` Michel Dänzer
2014-06-26 12:25 ` Dieter Nützel
2014-06-27 2:31 ` Michel Dänzer
2014-06-27 8:26 ` Christian König
2014-06-27 8:59 ` Michel Dänzer
2014-06-29 10:34 ` Christian König [this message]
2014-06-30 6:10 ` Michel Dänzer
2014-06-30 7:43 ` Christian König
2014-07-01 6:48 ` Michel Dänzer
2014-07-01 12:16 ` Christian König
2014-07-02 6:57 ` Michel Dänzer
2014-07-02 19:31 ` Christian König
2014-07-03 3:48 ` Michel Dänzer
2014-07-03 6:36 ` Christian König
2014-06-19 10:20 ` Marek Olšák
2014-06-19 10:25 ` Christian König
2014-06-20 1:10 ` Michel Dänzer
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=53AFEBCA.4060307@amd.com \
--to=christian.koenig@amd.com \
--cc=alexdeucher@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel@daenzer.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.