<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 14, 2016 at 4:25 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have an issue with PAT handling on older processes with limited PAT bits,<br>
see the patch description for the full problem. This replaces the runqemu<br>
workaround with a kernel patch until we can get the kernel trees sorted<br>
out and discuss a proper fix with upstream. It should be safe everywhere<br>
so is applied unconditionally.<br></blockquote><div><br></div><div>I could also merge this to the kernel tree directly, but since this is designed to be</div><div>transient, patching it this way is fine with me as well.</div><div><br></div><div>Acked-by: Bruce Ashfield <<a href="mailto:bruce.ashfield@windriver.com">bruce.ashfield@windriver.com</a>></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Signed-off-by: Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>><br>
<br>
diff --git a/meta/recipes-kernel/linux/linux-yocto/0001-Fix-qemux86-pat-issue.patch b/meta/recipes-kernel/linux/linux-yocto/0001-Fix-qemux86-pat-issue.patch<br>
new file mode 100644<br>
index 0000000..367d9b4a<br>
--- /dev/null<br>
+++ b/meta/recipes-kernel/linux/linux-yocto/0001-Fix-qemux86-pat-issue.patch<br>
@@ -0,0 +1,100 @@<br>
+From 9bfb2c711f66fc8eb6482f5ca6ea33c2ec1d792f Mon Sep 17 00:00:00 2001<br>
+From: Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>><br>
+Date: Sat, 13 Feb 2016 17:36:23 +0000<br>
+Subject: [PATCH] Fix qemux86 pat issue<br>
+<br>
+on qemux86, X doesn't start and there is<br>
+a backtrace in the logs:<br>
+<br>
+x86/PAT: Xorg:705 map pfn expected mapping type uncached-minus for [mem 0xfd000000-0xfdffffff], got write-combining<br>
+------------[ cut here ]------------<br>
+WARNING: CPU: 0 PID: 705 at /media/build1/poky/build/tmp/work-shared/qemux86/kernel-source/arch/x86/mm/pat.c:985 untrack_pfn+0xaf/0xc0()<br>
+Modules linked in: uvesafb<br>
+CPU: 0 PID: 705 Comm: Xorg Not tainted 4.4.1-yocto-standard #1<br>
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by <a href="http://qemu-project.org" rel="noreferrer" target="_blank">qemu-project.org</a> 04/01/2014<br>
+ 00000000 00000000 cf14dd78 c1397ab2 00000000 cf14dda8 c1051477 c1aa4f6c<br>
+ 00000000 000002c1 c1a9fa4c 000003d9 c104b98f c104b98f cf244000 b6355000<br>
+ 00000000 cf14ddb8 c1051552 00000009 00000000 cf14dde0 c104b98f cf14ddd0<br>
+Call Trace:<br>
+ [<c1397ab2>] dump_stack+0x4b/0x79<br>
+ [<c1051477>] warn_slowpath_common+0x87/0xc0<br>
+ [<c104b98f>] ? untrack_pfn+0xaf/0xc0<br>
+ [<c104b98f>] ? untrack_pfn+0xaf/0xc0<br>
+ [<c1051552>] warn_slowpath_null+0x22/0x30<br>
+ [<c104b98f>] untrack_pfn+0xaf/0xc0<br>
+ [<c104d54c>] ? kmap_atomic_prot+0x3c/0xf0<br>
+ [<c114e17f>] unmap_single_vma+0x4ef/0x500<br>
+ [<c114f007>] unmap_vmas+0x37/0x50<br>
+ [<c1154f8f>] exit_mmap+0x5f/0xf0<br>
+ [<c104eedd>] mmput+0x2d/0xb0<br>
+ [<c105009c>] copy_process+0xd2c/0x13c0<br>
+ [<c1050892>] _do_fork+0x82/0x340<br>
+ [<c105f2d1>] ? SyS_rt_sigaction+0x51/0xa0<br>
+ [<c1050c3c>] SyS_clone+0x2c/0x30<br>
+ [<c1001a03>] do_syscall_32_irqs_on+0x53/0xb0<br>
+ [<c189a94a>] entry_INT80_32+0x2a/0x2a<br>
+---[ end trace be3e0a61097feddc ]---<br>
+x86/PAT: Xorg:705 map pfn expected mapping type uncached-minus for [mem 0xfd000000-0xfdffffff], got write-combining<br>
+<br>
+The entry in question is setup by uvesafb which in its<br>
+uvesafb_ioremap() function calls ioremap_wc().<br>
+<br>
+It appears that Xorg mmaps this from userspace, then later does a<br>
+fork() to execute a utility. At this point, when creating the vmas for<br>
+the new process, the pat code says "eeek!" as the protection mode for<br>
+the new vmas don't match the old one, returns -EINVAL, the process dies<br>
+and X goes with it.<br>
+<br>
+There are a few hammers we can hit this with, we can boot with "nopat"<br>
+option which makes the problem go away, or turn off CONFIG_X86_PAT. No<br>
+surprises there. Changing uvesafb to use mtrr=0 doesn't help since the<br>
+ioremap_wc call still happens.<br>
+<br>
+The real issue is the "expected mapping type uncached-minus for got<br>
+write-combining" message, it all goes wrong from there.<br>
+<br>
+Upon looking at the code and scratching my head for a long while, I<br>
+notice that there are two ways of representing the protection mode<br>
+data, "enum page_cache_mode" and "pgprot_t & _PAGE_CACHE_MASK".<br>
+<br>
+The exact meaning of pgprot_t depends on which CPU you're running,<br>
+older CPUs have errata meaning only a small number of bits can be used.<br>
+The exact mapping table is determined by __cachemode2pte_tbl and is<br>
+updated at boot by calls from update_cache_mode_entry().<br>
+<br>
+The result of this if you map enum -> pgprot_t, then try to do pgprot_t<br>
+-> enum, you can get different values since its not a 1:1 mapping.<br>
+<br>
+This means the comparison in reserve_pfn_range() where it does "pcm !=<br>
+want_pcm" isn't correct and can trigger even in cases where there isn't<br>
+a problem.<br>
+<br>
+This can be "fixed" by doing cachemode2protval(pcm) !=<br>
+cachemode2protval(want_pcm) and checking whether the protection bits<br>
+match, rather than the enum values, since in reality this is what we<br>
+really care about. With that change, X boots up just fine.<br>
+<br>
+We don't see this on qemux86-64 since that has more PAT bits working<br>
+and hence the values map correctly.<br>
+<br>
+Signed-off-by: Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>><br>
+---<br>
+ arch/x86/mm/pat.c | 2 +-<br>
+ 1 file changed, 1 insertion(+), 1 deletion(-)<br>
+<br>
+diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c<br>
+index 031782e..11064fb 100644<br>
+--- a/arch/x86/mm/pat.c<br>
++++ b/arch/x86/mm/pat.c<br>
+@@ -833,7 +833,7 @@ static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot,<br>
+ if (ret)<br>
+ return ret;<br>
+<br>
+- if (pcm != want_pcm) {<br>
++ if (cachemode2protval(pcm) != cachemode2protval(want_pcm)) {<br>
+ if (strict_prot ||<br>
+ !is_new_memtype_allowed(paddr, size, want_pcm, pcm)) {<br>
+ free_memtype(paddr, paddr + size);<br>
+--<br>
+2.5.0<br>
+<br>
diff --git a/meta/recipes-kernel/linux/<a href="http://linux-yocto_4.4.bb" rel="noreferrer" target="_blank">linux-yocto_4.4.bb</a> b/meta/recipes-kernel/linux/<a href="http://linux-yocto_4.4.bb" rel="noreferrer" target="_blank">linux-yocto_4.4.bb</a><br>
index 1beeea6..c0edcf1 100644<br>
--- a/meta/recipes-kernel/linux/<a href="http://linux-yocto_4.4.bb" rel="noreferrer" target="_blank">linux-yocto_4.4.bb</a><br>
+++ b/meta/recipes-kernel/linux/<a href="http://linux-yocto_4.4.bb" rel="noreferrer" target="_blank">linux-yocto_4.4.bb</a><br>
@@ -40,3 +40,5 @@ KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"<br>
KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"<br>
KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"<br>
KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}"<br>
+<br>
+SRC_URI_append = " file://0001-Fix-qemux86-pat-issue.patch"<br>
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal<br>
index ad854d1..ebed2bd 100755<br>
--- a/scripts/runqemu-internal<br>
+++ b/scripts/runqemu-internal<br>
@@ -434,7 +434,7 @@ if [ "$MACHINE" = "qemux86" ]; then<br>
fi<br>
# Currently oprofile's event based interrupt mode doesn't work(Bug #828) in<br>
# qemux86 and qemux86-64. We can use timer interrupt mode for now.<br>
- KERNCMDLINE="$KERNCMDLINE oprofile.timer=1 nopat"<br>
+ KERNCMDLINE="$KERNCMDLINE oprofile.timer=1"<br>
fi<br>
<br>
if [ "$MACHINE" = "qemux86-64" ]; then<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>