From: keith mannthey <kmannth@us.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
lhms-devel <lhms-devel@lists.sourceforge.net>,
y-goto@jp.fujitsu.com, andrew <akpm@osdl.org>
Subject: Re: [PATCH] memory hotadd fixes [4/5] avoid check in acpi
Date: Thu, 03 Aug 2006 21:25:34 -0700 [thread overview]
Message-ID: <1154665534.5925.98.camel@keithlap> (raw)
In-Reply-To: <20060804124847.610791b5.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, 2006-08-04 at 12:48 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 03 Aug 2006 20:23:46 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
> > > > What keeps 0xa0000000 to 0xa1000000 from being re-onlined by a bad call
> > > > to add_memory?
> > >
> > > Usual sparsemem's add_memory() checks whether there are sections in
> > > sparse_add_one_section(). then add_pages() returns -EEXIST (nothing to do).
> > > And ioresouce collision check will finally find collision because 0-0xbffffff
> > > resource will conflict with 0xa0000000 to 0xa10000000 area.
> > > But, x86_64 's (not sparsemem) add_pages() doen't do collision check, so it panics.
> >
> > I have paniced with your 5 patches while doing SPARSMEM.... I think
> > your 6th patch address the issues I was seeing.
> >
with the 6 patches things work as expected. It is nice to have the
sysfs devices online the correct amount of memory.
I was broken without this patch because invalid add_memory calls are
made on by box (yet another issue) during boot.
I will build my patch set on top of your 6 patches.
Thanks,
Keith
next prev parent reply other threads:[~2006-08-04 4:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-03 3:36 [PATCH] memory hotadd fixes [4/5] avoid check in acpi KAMEZAWA Hiroyuki
2006-08-03 18:28 ` keith mannthey
2006-08-03 23:09 ` [Lhms-devel] " keith mannthey
2006-08-04 0:22 ` KAMEZAWA Hiroyuki
2006-08-04 0:13 ` keith mannthey
2006-08-04 0:44 ` KAMEZAWA Hiroyuki
2006-08-04 1:54 ` keith mannthey
2006-08-04 2:15 ` KAMEZAWA Hiroyuki
2006-08-04 2:32 ` [PATCH] memory hotadd fixes [6/5] enhance collistion check KAMEZAWA Hiroyuki
2006-08-04 3:09 ` keith mannthey
2006-08-04 3:19 ` KAMEZAWA Hiroyuki
2006-08-04 21:01 ` keith mannthey
2006-08-04 3:00 ` [PATCH] memory hotadd fixes [4/5] avoid check in acpi keith mannthey
2006-08-04 3:13 ` KAMEZAWA Hiroyuki
2006-08-04 3:23 ` keith mannthey
2006-08-04 3:48 ` KAMEZAWA Hiroyuki
2006-08-04 4:25 ` keith mannthey [this message]
2006-08-04 4:32 ` KAMEZAWA Hiroyuki
2006-08-04 8:23 ` Mika Penttilä
2006-08-04 8:32 ` keith mannthey
2006-08-04 5:46 ` Yasunori Goto
2006-08-04 5:59 ` [Lhms-devel] " KAMEZAWA Hiroyuki
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=1154665534.5925.98.camel@keithlap \
--to=kmannth@us.ibm.com \
--cc=akpm@osdl.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=y-goto@jp.fujitsu.com \
/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.