[ipxe-devel] Using iPXE, e820 RAM map badly changed, kernel panic over seeing only 50MB
james harvey
jamespharvey20 at gmail.com
Mon Aug 8 03:37:48 UTC 2016
Based on that git comment about x86_64 pcbios being non-functional, I
set out to try making en EFI version. I'll admit, I have never used
EFI before, being content with the way things used to work and having
nothing pushing me to it.
So, instead of running:
make bin/15b3673c.rom
I ran:
make bin-x86_64-efi/15b3673c.efirom
Successfully burned it to my Mellanox MT26428 ConnectX, and
successfully read its ROM it to a file and compared it to make sure it
was burned correctly.
On reboot, I no longer see the screen saying to hit CTRL+B to enter
IPXE. (Maybe that's supposed to go away when using EFI?)
If I enter my BIOS's boot menu, it no longer shows the card with iPXE.
If I enter my BIOS's EFI menu, running devices or drivers doesn't show
the card with iPXE.
I see http://ipxe.org/download says some network cards can't support
ROMs larger than 64kB. That might only refer to pcbios ROMS, but
anyways both are over 64kB. The iPXE pcbios ROM is 77,312 bytes, and
the iPXE efi ROM is 155,648 bytes. So, I don't think that's the
issue.
On Sun, Aug 7, 2016 at 10:27 PM, james harvey <jamespharvey20 at gmail.com> wrote:
> 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