xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Dingwall <james-xen@dingwall.me.uk>
Cc: daniel.kiper@oracle.com, xen-devel@lists.xen.org
Subject: Re: kernel log flooded with: xen_balloon: reserve_additional_memory: add_memory() failed: -17
Date: Fri, 21 Dec 2012 15:25:24 -0500	[thread overview]
Message-ID: <20121221202524.GC31554@phenom.dumpdata.com> (raw)
In-Reply-To: <d779abba78844d3701963b5ce5bdae92@imap.dingwall.me.uk>

On Wed, Dec 19, 2012 at 08:47:22AM +0000, James Dingwall wrote:
> Hi,
> 
> I have encountered an apparently benign error on two systems where
> the dom0 kernel log is flooded with messages like:
> 
> [52482.163855] System RAM resource [mem 0x1b8000000-0x1bfffffff]
> cannot be added
> [52482.163860] xen_balloon: reserve_additional_memory: add_memory()
> failed: -17

Daniel tells me it is due to the recent changes in the balloon code.
CC-ing him here.

> 
> The first line is from drivers/xen/xen-balloon.c, the second from
> mm/memory_hotplug.c
> 
> The trigger for the messages seems to be the first occasion that a
> Xen guest is shutdown.  I have noted this in a vanilla 3.6.7 and
> kernel 3.5.0-18 built from Ubuntu sources.  Xen version is 4.2.0.
> It is not clear why the dom0 is kernel is trying to balloon up as
> the Xen command line is specifies a fixed dom0 memory allocation and
> noselfballooning is specified for the kernel and ballooning is also
> disabled in the xend-config.sxp / xl.conf (one system using xm,
> another xl)
> 
> xen command line:
> placeholder xsave=0 iommu=0 console=vga,com2 com2=115200,8n1
> dom0_mem=max:6144m
> 
> kernel command line:
> root=/dev/loop0 ro console=tty1 console=hvc0 earlyprintk=xen
> nomodeset noselfballooning
> 
> Examining /proc/iomem does show that the dom0 memory allocation is
> actually 64kb short of 6144Mb:
> 
> cat /proc/iomem | grep System\ RAM
> 00010000-0009bfff : System RAM      [573440 bytes]
> 00100000-cb2dffff : System RAM      [3407740928 bytes]
> 100000000-1b4d83fff : System RAM    [3034071040 bytes]
> 
> Total system ram: 6442385408 - 6x2^30 = 65536
> 
> The memory range indicated in the log message is "Unusable memory"
> in /proc/iomem:
> 1b4d84000-82fffffff : Unusable memory
> 
> Another point of interest is that we have multiple "identical"
> hardware platforms (Dell T320) for the system running the 3.5.0-18
> kernel but only see this error on a slightly more recent system.
> Older systems show in /proc/iomem that all memory is System RAM.
> 
> 100000000-82fffffff : System RAM  [older system BIOS 1.0]
> 
> 100000000-1b4d83fff : System RAM  [newer system BIOS 1.3]
> 1b4d84000-82fffffff : Unusable memory
> 
> The BIOS revision between the old and new has changed so I was
> wondering if it is possible that there is a white list which affects
> the impact of the kernel option:
> CONFIG_X86_RESERVE_LOW=64
> This is only a guess since the amount of memory reserved is
> equivalent to the short fall calculated above.  If this is the right
> area perhaps the dom0 calculation for its memory entitlement needs
> to be taught to not to try and hotplug the missing 64k when it has
> been reserved.
> 
> If any other information would be useful then please let me know.
> 
> Thanks,
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

  parent reply	other threads:[~2012-12-21 20:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-19  8:47 kernel log flooded with: xen_balloon: reserve_additional_memory: add_memory() failed: -17 James Dingwall
2012-12-19 10:55 ` James Dingwall
2012-12-21 20:23   ` Konrad Rzeszutek Wilk
2013-01-02 10:28     ` James Dingwall
2012-12-20 14:50 ` Jacek Konieczny
2012-12-20 15:55   ` James Dingwall
2012-12-21 20:25 ` Konrad Rzeszutek Wilk [this message]
2012-12-23 10:41   ` Carsten Schiers
  -- strict thread matches above, loose matches on Subject: below --
2012-12-24 14:39 Daniel Kiper
2013-01-24 21:38 ` Carsten Schiers
2013-01-25 10:48 Daniel Kiper
2013-01-28 16:36 ` Darren Shepherd
2013-01-28 17:40   ` David Vrabel
2013-01-29 11:53 Daniel Kiper

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=20121221202524.GC31554@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=daniel.kiper@oracle.com \
    --cc=james-xen@dingwall.me.uk \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).