Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes

On Sat, 20 May 2006, Andrew Morton wrote:

Mel Gorman <[email protected]> wrote:

Size zones and holes in an architecture independent manner for x86_64.

I found a .config which triggers the cant-map-acpitables problem.


With that .config, and without this patch:

Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.6
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
DMI 2.4 present.
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)


With that .config, and with this patch:

Bootdata ok (command line is ro root=LABEL=/ earlyprintk=serial,ttyS0,9600,keep [email protected]/eth0,[email protected]/00:0D:56:C6:C6:CC)
Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #33 SMP Sat May 20 12:08:03 PDT 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
Too many memory regions, truncating
Too many memory regions, truncating
Too many memory regions, truncating
DMI 2.4 present.
ACPI: Unable to map RSDT header
Intel MultiProcessor Specification v1.4
   Virtual Wire compatibility mode.
OEM ID:  Product ID:  APIC at: 0xFEE00000

I think I have figured out what went wrong here.

arch/i386/kernel/acpi/boot.c has a __acpi_map_table() function which uses a variable end_pfn_map variable defined in arch/x86_64/kernel/e820.c . Part of the arch-independent-zone-sizing patch calculates end_pfn_map from early_node_map[] which only contains information on real RAM regions.

On Christian's machine, there is no usable region after the ACPI table data so early_node_map[] finishes just before the ACPI tables. This results in the wrong value for end_pfn_map and the table fails to be mapped. In Andrew's machines case, the regions got truncated and nothing after ACPI NVS was recorded, including ACPI data which is why it fails to boot.

Am not ready to release another set of patches, but I think this was the cause of magic failures on x86_64.

--
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
-
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/

---

• References:
  • [PATCH 0/6] Sizing zones and holes in an architecture independent manner V6
    • From: Mel Gorman <[email protected]>
  • [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
    • From: Mel Gorman <[email protected]>
  • Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
    • From: Andrew Morton <[email protected]>

• Prev by Date: [PATCH] -mm: cyrix code CONFIG_PCI fix / add __initdata
• Next by Date: Re: [PATCH (try #3)] mm: avoid unnecessary OOM kills
• Previous by thread: Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
• Next by thread: [PATCH 6/6] Break out memory initialisation code from page_alloc.c to mem_init.c
• Index(es):
  • Date
  • Thread

[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]