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 <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
