From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: poky@yoctoproject.org
Subject: Re: [PATCH 1/1] poky: update qemu* to prefer 4.4 kernel
Date: Fri, 12 Feb 2016 14:36:05 +0000 [thread overview]
Message-ID: <1455287765.16142.321.camel@linuxfoundation.org> (raw)
In-Reply-To: <2e6d2b75837731be983d888eaa82a9cfcf660e85.1455203562.git.bruce.ashfield@windriver.com>
On Thu, 2016-02-11 at 10:15 -0500, Bruce Ashfield wrote:
> 4.4 is out and has had enough mileage to be the default for the
> qemu machines. Tested with sato, minimal and kernel dev image
> types.
This mostly worked except for qemux86 which is showing X failing on all
builds. Its quite reproducible, "MACHINE=qemux86 bitbake core-image
-sato -c testimage" shows it.
https://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/6
48/steps/Running%20Sanity%20Tests/logs/stdio
is one example from the autobuilder.
Poking at the image manually, it appears Xorg fails due to:
[3587706.730] (EE) XKB: Could not invoke xkbcomp
[3587706.730] (EE) XKB: Couldn't compile keymap
[3587706.731] (EE) XKB: Failed to load keymap. Loading default keymap
instead.
[3587706.765] (EE) XKB: Could not invoke xkbcomp
[3587706.765] (EE) XKB: Couldn't compile keymap
which prompted me to look at dmesg:
EXT4-fs (vda): re-mounted. Opts: data=ordered
random: dd urandom read with 51 bits of entropy available
x86/PAT: Xorg:705 map pfn expected mapping type uncached-minus for [mem 0xfd000000-0xfdffffff], got write-combining
------------[ cut here ]------------
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()
Modules linked in: uvesafb
CPU: 0 PID: 705 Comm: Xorg Not tainted 4.4.1-yocto-standard #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
00000000 00000000 cf14dd78 c1397ab2 00000000 cf14dda8 c1051477 c1aa4f6c
00000000 000002c1 c1a9fa4c 000003d9 c104b98f c104b98f cf244000 b6355000
00000000 cf14ddb8 c1051552 00000009 00000000 cf14dde0 c104b98f cf14ddd0
Call Trace:
[<c1397ab2>] dump_stack+0x4b/0x79
[<c1051477>] warn_slowpath_common+0x87/0xc0
[<c104b98f>] ? untrack_pfn+0xaf/0xc0
[<c104b98f>] ? untrack_pfn+0xaf/0xc0
[<c1051552>] warn_slowpath_null+0x22/0x30
[<c104b98f>] untrack_pfn+0xaf/0xc0
[<c104d54c>] ? kmap_atomic_prot+0x3c/0xf0
[<c114e17f>] unmap_single_vma+0x4ef/0x500
[<c114f007>] unmap_vmas+0x37/0x50
[<c1154f8f>] exit_mmap+0x5f/0xf0
[<c104eedd>] mmput+0x2d/0xb0
[<c105009c>] copy_process+0xd2c/0x13c0
[<c1050892>] _do_fork+0x82/0x340
[<c105f2d1>] ? SyS_rt_sigaction+0x51/0xa0
[<c1050c3c>] SyS_clone+0x2c/0x30
[<c1001a03>] do_syscall_32_irqs_on+0x53/0xb0
[<c189a94a>] entry_INT80_32+0x2a/0x2a
---[ end trace be3e0a61097feddc ]---
x86/PAT: Xorg:705 map pfn expected mapping type uncached-minus for [mem 0xfd000000-0xfdffffff], got write-combining
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period (net c1c271c0)
which fits since do_fork() is probably failing and would cause this
error. It looks like the above is only a warning but could be fatal
later I guess.
A quick look at upstream makes me wonder about:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d9fe4fab11976e56b2e992980bf6ce948bdf02ac
which changes the code in this area.
Any idea what is going on here?
Cheers,
Richard
next prev parent reply other threads:[~2016-02-12 14:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 15:15 [PATCH 0/1] meta-yocto: bump qemu preferred version to 4.4 Bruce Ashfield
2016-02-11 15:15 ` [PATCH 1/1] poky: update qemu* to prefer 4.4 kernel Bruce Ashfield
2016-02-12 14:36 ` Richard Purdie [this message]
2016-02-12 15:32 ` Richard Purdie
2016-02-13 8:31 ` Richard Purdie
2016-02-13 17:17 ` Richard Purdie
2016-02-13 17:17 ` [poky] " Richard Purdie
2016-02-13 18:19 ` Bruce Ashfield
2016-02-13 18:19 ` [poky] " Bruce Ashfield
2016-02-14 16:29 ` Paul Gortmaker
2016-02-14 16:29 ` [poky] " Paul Gortmaker
2016-03-02 1:41 ` Paul Gortmaker
2016-03-02 1:41 ` [poky] " Paul Gortmaker
2016-03-09 18:53 ` Bruce Ashfield
2016-03-09 18:53 ` [poky] " Bruce Ashfield
2016-03-09 21:23 ` Richard Purdie
2016-03-09 21:23 ` [poky] " Richard Purdie
2016-03-10 4:12 ` Bruce Ashfield
2016-03-10 4:12 ` [poky] " Bruce Ashfield
2016-03-10 20:59 ` Richard Purdie
2016-03-10 20:59 ` [poky] " Richard Purdie
2016-03-10 21:55 ` Bruce Ashfield
2016-03-10 21:55 ` [poky] " Bruce Ashfield
2016-02-13 18:16 ` Bruce Ashfield
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=1455287765.16142.321.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bruce.ashfield@windriver.com \
--cc=poky@yoctoproject.org \
/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.