> I don't think Linux should require the ACPI add event to contain the
> _pxm information. (I don't see it required in the spec).
Agree.
> acpi_get_node
> is only going to work with systems that implement the acpi table in this
> way.
This cause is just I didn't know that there is a box without _PXM
in DSDT. :-P
I prefer that acpi_get_node() should include your case.
Then caller of it can get node without knowledge about SRAT or
DSDT by one call. So, my idea was like followings.
acpi_get_node()
{
:
if (node < 0)
node = arch_search_srat_info(handle);
if (node < 0) /* NUMA kernel executed on non NUMA box */
node = 0;
return node;
}
arch_search_srat_info() must be made for each arch
(i386, x86-64, ia64). And I don't know that all of them can be
posted by publish of 2.6.18. So, I would like to rescue
againt panic.
However, I might make sense one more by your patch....
> I think something like this might be better...
Why do you enter memory_add_physaddr_to_nid() IN the loop of
searching mem_device? This implies, there is a _CRS which have multiple
memory block entries, and each entries might belong DIFFERENT node
each other. If so, above my idea is not appropriate. :-(
BTW, memory_add_physaddr_to_nid() is not defined for ia64's NUMA box and
i386's NUMA box.
Thanks.
>
> diff -urN linux-2.6.18-rc3-stock/drivers/acpi/acpi_memhotplug.c linux-2.6.17/drivers/acpi/acpi_memhotplug.c
> --- linux-2.6.18-rc3-stock/drivers/acpi/acpi_memhotplug.c 2006-07-31 19:59:05.000000000 -0400
> +++ linux-2.6.17/drivers/acpi/acpi_memhotplug.c 2006-08-01 13:56:03.000000000 -0400
> @@ -241,6 +241,9 @@
> continue;
> }
>
> + if (node < 0)
> + node = memory_add_physaddr_to_nid(info->start_addr);
> +
> result = add_memory(node, info->start_addr, info->length);
> if (result)
> continue;
--
Yasunori Goto
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
