On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie airlied@gmail.com wrote:
On 17 October 2016 at 04:41, Marek Olšák maraeo@gmail.com wrote:
On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer michel@daenzer.net wrote:
[ Adding Dan Williams and dri-devel ]
On 14/10/16 03:28 AM, Shawn Starr wrote:
Hello AMD folks,
I have discovered a problem in Linus master that affects AMDGPU, nobody would notice this in drm-next-4.9-wip since its not in this repo.
[...]
87744ab3832b83ba71b931f86f9cfdb000d07da5 is the first bad commit commit 87744ab3832b83ba71b931f86f9cfdb000d07da5 Author: Dan Williams dan.j.williams@intel.com Date: Fri Oct 7 17:00:18 2016 -0700
mm: fix cache mode tracking in vm_insert_mixed() vm_insert_mixed() unlike vm_insert_pfn_prot() and vmf_insert_pfn_pmd(), fails to check the pgprot_t it uses for the mapping against the one recorded in the memtype tracking tree. Add the missing call to track_pfn_insert() to preclude cases where incompatible aliased mappings are established for a given physical address range. Link: http://lkml.kernel.org/r/147328717909.35069.14256589123570653697.stgit@dwillia2- desk3.amr.corp.intel.com Signed-off-by: Dan Williams dan.j.williams@intel.com Cc: David Airlie airlied@linux.ie Cc: Matthew Wilcox mawilcox@microsoft.com Cc: Ross Zwisler ross.zwisler@linux.intel.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
:040000 040000 7517c0019fe49c1830b5a1d81f1dc099c5aab98a fd497a604a2af5995db2b8ed1e9c640bede6adf3 M mm
Removal of this patch stops graphics stalls.
Thanks for bisecting this Shawn.
A friend of mine mentions,
"looks like a graphics thingy you depend on is requesting a mapping with a not-allowed cache mode, and now you are (rightfully) getting errors?"
It would be nice to get some more specific pointers what amdgpu (or maybe ttm, since that calls vm_insert_mixed in ttm_bo_vm_fault) might be doing wrong.
/* * We'd like to use VM_PFNMAP on shared mappings, where * (vma->vm_flags & VM_SHARED) != 0, for performance reasons, * but for some reason VM_PFNMAP + x86 PAT + write-combine is very * bad for performance. Until that has been sorted out, use * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719 */ vma->vm_flags |= VM_MIXEDMAP;We have that comment in the ttm code, which to me implies that mixed is doing the right thing now, but that is slow, as the interface we should be using.
Aren't there only 2 possibilities for this regression?
1/ a memtype entry was never made so track_pfn_insert() returns an uncached mapping
2/ a conflicting memtype entry exists and undefined behavior due to mixed mapping types is avoided with the change.