<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 13, 2016 at 12:17 PM, 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">I'm moving the discussion to OE-Core and pulling in some kernel people.<br>
I think I understand what is wrong and how to fix it but I could use<br>
someone who actually knows this code.<br>
<br>
To summarise the story so far, on qemux86, X doesn't start and there is<br>
a backtrace in the logs:<br>
<div><div class="h5"><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>
</div></div>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.<br>
<br>
I can confirm that if I make that change, X boots up just fine.<br>
<br>
The problem is I really have no idea what I'm doing :).<br>
<br>
Could someone who understands this code have a look and see whether the<br>
above makes sense and if it does, perhaps open a discussion with<br>
upstream about how to fix this properly (assuming my change isn't<br>
actually the correct fix)?<br></blockquote><div><br></div><div>I'm not familiar with this code either, but I'll start doing some bisects to see if</div><div>we can isolate the commit that introduced the behaviour change. This is the</div><div>sort of thing that is very rare, and really isn't supposed to happen. So until</div><div>I read the commit log where the change was triggered, I'd lean to it being a bug</div><div>and something to report and fix upstream.</div><div><br></div><div>I know that I booted sato with the 4.4 update, do we have any other confirmations</div><div>that this worked, or was I the only one doing 4.4 boot tests until I sent the</div><div>patch to bump the preferred version ?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
Bruce: Would you accept a patch doing the above for now?<br></blockquote><div><br></div><div>I would. I'd rather not paper over this by changing the config fragments, since</div><div>once we throw that switch, it'll most likely sit there .. covered up.</div><div><br></div><div>Bruce</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
--<br>
_______________________________________________<br>
poky mailing list<br>
<a href="mailto:poky@yoctoproject.org">poky@yoctoproject.org</a><br>
<a href="https://lists.yoctoproject.org/listinfo/poky" rel="noreferrer" target="_blank">https://lists.yoctoproject.org/listinfo/poky</a><br>
</div></div></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>