Mel Gorman wrote:
> On (13/01/08 10:34), [EMAIL PROTECTED] didst pronounce:
...
>> int update_end_of_memory(unsigned long end) {return -1;}
>> @@ -343,7 +346,8 @@ int __init acpi_scan_nodes(unsigned long
>> /* First clean up the node list */
>> for (i = 0; i < MAX_NUMNODES; i++) {
>>
On Mon, 14 Jan 2008, Mike Travis wrote:
> I see the mistake in the node array. But AFAICT, pxm is the proximity
> between nodes and cannot be expressed as greater than the number of
> nodes, yes? (Or can it be arbitrarily expressed where 32 bits is
> necessary?) I ask this because the real node
Jan Engelhardt wrote:
...
>> --- a/arch/x86/mm/srat_64.c
>> +++ b/arch/x86/mm/srat_64.c
>> @@ -384,6 +388,12 @@ int __init acpi_scan_nodes(unsigned long
>> }
>>
>> #ifdef CONFIG_NUMA_EMU
>> +static int fake_node_to_pxm_map[MAX_NUMNODES] __initdata = {
>> +[0 ... MAX_NUMNODES-1] = PXM_INVAL
>>
Jan Engelhardt wrote:
> On Jan 13 2008 10:34, [EMAIL PROTECTED] wrote:
>> --- a/arch/x86/kernel/mpparse_64.c
>> +++ b/arch/x86/kernel/mpparse_64.c
>> @@ -132,7 +132,7 @@ static void __cpuinit MP_processor_info(
>> * area is created.
>> */
>> if (x86_cpu_to_apicid_ptr) {
>> -
Mel Gorman wrote:
> On (13/01/08 10:34), [EMAIL PROTECTED] didst pronounce:
>> Change the size of APICIDs from u8 to u16. This partially
>> supports the new x2apic mode that will be present on future
>> processor chips. (Chips actually support 32-bit APICIDs, but that
>> change is more intrusive.
On Jan 13 2008 10:34, [EMAIL PROTECTED] wrote:
>--- a/arch/x86/kernel/mpparse_64.c
>+++ b/arch/x86/kernel/mpparse_64.c
>@@ -132,7 +132,7 @@ static void __cpuinit MP_processor_info(
>* area is created.
>*/
> if (x86_cpu_to_apicid_ptr) {
>- u8 *x86_cpu_to_apicid =
On (13/01/08 10:34), [EMAIL PROTECTED] didst pronounce:
> Change the size of APICIDs from u8 to u16. This partially
> supports the new x2apic mode that will be present on future
> processor chips. (Chips actually support 32-bit APICIDs, but that
> change is more intrusive. Supporting 16-bit is suf
7 matches
Mail list logo
