Re: [PATCH] memory hotadd fixes [4/5] avoid check in acpi

From: Mika Penttilä
Date: Fri Aug 04 2006 - 04:24:49 EST


keith mannthey wrote:
On Fri, 2006-08-04 at 12:48 +0900, KAMEZAWA Hiroyuki wrote:
On Thu, 03 Aug 2006 20:23:46 -0700
keith mannthey <kmannth@xxxxxxxxxx> 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

Keith, are you working on the reserve hotadd case? It looks really broken, at the same time we both assume the hot add region contains RAM per e820 (use of reserve_bootmem_node()) and at the same time in other places (in reserve_hotadd()) that it may not contain RAM. And nodes_cover_memory() is broken no matter what we assume.


--Mika

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/