[ipxe-devel] Using iPXE, e820 RAM map badly changed, kernel panic over seeing only 50MB

james harvey jamespharvey20 at gmail.com
Mon Aug 8 02:27:18 UTC 2016 

I can boot an unmodified Arch Linux ISO from a DVD, and kernel
correctly sees 64GB, reporting:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000392f6fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000392f7000-0x0000000039e69fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000039e6a000-0x000000003a109fff] usable
[    0.000000] BIOS-e820: [mem 0x000000003a10a000-0x000000003acb8fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000003acb9000-0x000000003b613fff] reserved
[    0.000000] BIOS-e820: [mem 0x000000003b614000-0x000000003b614fff] usable
[    0.000000] BIOS-e820: [mem 0x000000003b615000-0x000000003b69afff] reserved
[    0.000000] BIOS-e820: [mem 0x000000003b69b000-0x000000003b8b7fff] usable
[    0.000000] BIOS-e820: [mem 0x000000003b8b8000-0x000000003bff8fff] reserved
[    0.000000] BIOS-e820: [mem 0x000000003bff9000-0x000000003bffffff] usable
[    0.000000] BIOS-e820: [mem 0x000000003c000000-0x000000003dffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000040000000-0x000000004fffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed24fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed30000-0x00000000fed34fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000010bfffffff] usable
[    0.000000] debug: ignoring loglevel setting.

If I boot the SAME unmodified Arch linux ISO through iPXE (from
another machine sharing it using SRP), kernel only sees about 50MB,
reporting:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-88: [mem 0x0000000000000000-0x000000000009efff] usable
[    0.000000] BIOS-88: [mem 0x0000000000100000-0x00000000032bbfff] usable
[    0.000000] debug: ignoring loglevel setting.

I believe iPXE is modifying the e820 information the linux kernel
retrieves.  Both because almost no memory is seen, and the kernel
gives each block of memory referring to "BIOS-88" rather than
"BIOS-e820".

I saw in the iPXE code fakee820.{h,c} and e820mangler.S.  In
e820mangler.S, I see references to "morons at ACPI" causing problems
in this area before, so I think I'm on the right track on what's going
on, rather than it being a kernel bug, since at this point the kernel
shouldn't be behaving any differently, and until 2 more kernel seconds
doesn't try to do anything differently having been loaded by SRP.

I am developing an ib_sbft kernel module and a program to use it, to
be able to complete SRP booting using your SBFT ACPI table, and one of
the most active linux Infiniband kernel developers has agreed to look
over, help test, and help get accepted, based on how iscsi works with
the kernel module iscsi_ibft.  I actually think the kernel module is
about done, as it correctly parses randomly made SBFT tables using
your structure on an already booted system - I'm now trying to test it
using your SBFT tables.

But I'm getting a kernel panic that the 27MB initrd is too large due
to not having enough memory, which led me here.

Looking at the git log for the e820 source files, I saw a very
confusing (to me) git comment:

    [bios] Add bin-x86_64-pcbios build platform

    Move most arch/i386 files to arch/x86, and adjust the contents of the
    Makefiles and the include/bits/*.h headers to reflect the new
    locations.

    This patch makes no substantive code changes, as can be seen using a
    rename-aware diff (e.g. "git show -M5").

    This patch does not make the pcbios platform functional for x86_64; it
    merely allows it to compile without errors.

So I'm confused by "does not make the pcbios platform functional for
x86_64".  I am on a 64-bit system, a MSI MS-7885/X99S SLI Plus
motherboard, an Intel i7 5820K, and 64GB memory.



Also below is the kernel panic through iPXE.  Using an earlier made
ISO that had a 24MB initrd gets 2 kernel seconds past this point, to
where the kernel attempts mounting the new root, which is where my
kernel module + other program will come in.

============================================
(Manually typed)

[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes,
using 'standard' format.
[    0.000000] x86/fpu: Using 'eager' FPU context switches.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-88: [mem 0x0000000000000000-0x000000000009efff] usable
[    0.000000] BIOS-88: [mem 0x0000000000100000-0x00000000032bbfff] usable
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] console [earlyvga0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x32bc max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000080000000 mask 3FFF80000000 uncachable
[    0.000000]   1 base 000040000000 mask 3FFFC0000000 uncachable
[    0.000000]   2 base 380000000000 mask 3FC000000000 uncachable
[    0.000000]   3 base 00003F000000 mask 3FFFFF000000 uncachable
[    0.000000]   4 base 0000E0000000 mask 3FFFF0000000 write-through
[    0.000000]   5 base 0000F0000000 mask 3FFFFF000000 write-through
[    0.000000]   6 base 0000F1000000 mask 3FFFFF800000 write-through
[    0.000000]   7 disabled
[    0.000000]   8 disabled
[    0.000000]   9 disabled
[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [ffff880000096000] 96000 size 24576
[    0.000000] Using GB pages for direct mapping
[    0.000000] BRK [0x01b4e000, 0x01b4efff] PGTABLE
[    0.000000] BRK [0x01b4f000, 0x01b4ffff] PGTABLE
[    0.000000] BRK [0x01b50000, 0x01b50fff] PGTABLE
[    0.000000] Kernel panic - not syncing: initrd too large to handle, disabling
 initrd (27426236 needed, 26398720 available)
[    0.000000]
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.4-1-ARCH #1
[    0.000000]  0000000000000086 5c08bc9d6d100ae8 ffffffff81803e48 ffffffff812e5
4c2
[    0.000000]  ffffffff816f5de0 ffffffff81803ee0 ffffffff81803ed0 ffffffff8116d
721
[    0.000000]  0000000000000018 ffffffff81803ee0 ffffffff81803e78 5c08bc9d6d100
ae8
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff812e54c2>] dump_stack+0x63/0x81
[    0.000000]  [<ffffffff8116d721>] panic+0xde/0x220
[    0.000000]  [<ffffffff819198e4>] setup_arch+0x79d/0xcdd
[    0.000000]  [<ffffffff8116da49>] ? printk+0x57/0x73
[    0.000000]  [<ffffffff8190c120>] ? early_idt_handler_array+0x120/0x120
[    0.000000]  [<ffffffff8190cc64>] start_kernel+0xb2/0x45f
[    0.000000]  [<ffffffff8190c120>] ? early_idt_handler_array+0x120/0x120
[    0.000000]  [<ffffffff8190c346>] x86_64_start_reservations+0x2a/0x2c
[    0.000000]  [<ffffffff8190c494>] x86_64_start_kernel+0x14c/0x16f
[    0.000000] ---[ end Kernel panic - not syncing: initrd too large to handle,
disabling initrd (27426236 needed, 26398720 available)
[    0.000000]
============================================

More information about the ipxe-devel mailing list