All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Stefan Bader <stefan.bader@canonical.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: bad page flags booting 32bit dom0 on 64bit hypervisor using dom0_mem (kernel >=4.2)
Date: Mon, 2 May 2016 13:41:18 +0200	[thread overview]
Message-ID: <57273CDE.10300@suse.com> (raw)
In-Reply-To: <57273050.6060300@canonical.com>

On 02/05/16 12:47, Stefan Bader wrote:
> I recently tried to boot 32bit dom0 on 64bit Xen host which I configured to run
> with a limited, fix amount of memory for dom0. It seems that somewhere between
> kernel versions 3.19 and 4.2 (sorry that is still a wide range) the Linux kernel
> would report bad page flags for a range of pages (which seem to be around the
> end of the guest pfn range). For a 4.2 kernel that was easily missed as the boot
> finished ok and dom0 was accessible. However starting with 4.4 (tested 4.5 and a
> 4.6-rc) the serial console output freezes after some of those bad page flag
> messages and then (unfortunately without any further helpful output) the host
> reboots (I assume there is a panic that triggers a reset).
> 
> I suspect the problem is more a kernel side one. It is just possible to
> influence things by variation of dom0_mem=#,max:#. 512M seems ok, 1024M, 2048M,
> and 3072M cause bad page flags starting around kernel 4.2 and reboots around
> 4.4. Then 4096M and not clamping dom0 memory seem to be ok again (though not
> limiting dom0 memory seems to cause trouble on 32bit dom0 later when a domU
> tries to balloon memory, but I think that is a different problem).
> 
> I have not seen this on a 64bit dom0. Below is an example of those bad page
> errors. Somehow it looks to be a page marked as reserved. Initially I wondered
> whether this could be a problem of not clearing page flags when moving mappings
> to match the e820. But I never looked into i386 memory setup in that detail. So
> I am posting this, hoping that someone may have an idea from the detail about
> where to look next. PAE is enabled there. Usually its bpf init that gets hit but
> that likely is just because that is doing the first vmallocs.

Could you please post the kernel config, Xen and dom0 boot parameters?
I'm quite sure this is no common problem as there are standard tests
running for each kernel version including 32 bit dom0 with limited
memory size.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-05-02 11:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-02 10:47 bad page flags booting 32bit dom0 on 64bit hypervisor using dom0_mem (kernel >=4.2) Stefan Bader
2016-05-02 11:41 ` Juergen Gross [this message]
2016-05-02 14:24   ` Stefan Bader
2016-05-11  8:08     ` [Xen-devel] " Stefan Bader
2016-05-11  8:08     ` Stefan Bader

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=57273CDE.10300@suse.com \
    --to=jgross@suse.com \
    --cc=stefan.bader@canonical.com \
    --cc=xen-devel@lists.xenproject.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.