Bug #48
closedLinux fails to boot with embedded GRUB payload but works with embedded SeaBIOS payload
Added by Timothy Pearson almost 8 years ago. Updated about 2 years ago.
0%
Description
When booting an ASUS KGPE-D16 with the embedded GRUB payload Linux fails to acquire the ACPI IRQ and/or tables; booting the same board and OS image with the embedded SeaBIOS payload works fine.
Log of failed kernel boot from GRUB attached; logs of the successful kernel boot under SeaBIOS are forthcoming.
Files
| kgpe-d16-grub-linux-acpi-failure.log (21.2 KB) kgpe-d16-grub-linux-acpi-failure.log | Linux log with GRUB (smpboot disabled) | Timothy Pearson, 04/28/2016 04:24 PM | |
| kgpe-d16-seabios-linux-success.log (376 KB) kgpe-d16-seabios-linux-success.log | Timothy Pearson, 04/28/2016 05:10 PM | ||
| kgpe-d16-grub-linux-4.5-failure.log (366 KB) kgpe-d16-grub-linux-4.5-failure.log | Timothy Pearson, 04/28/2016 05:27 PM | ||
| kgpe-d16-seabios-linux-4.5-success.log (379 KB) kgpe-d16-seabios-linux-4.5-success.log | Timothy Pearson, 04/28/2016 05:27 PM |
Updated by Timothy Pearson almost 8 years ago
I forgot to mention that I wasn't sure if this should be filed here or on the main GRUB issue tracker, as from what I can tell using GRUB works when loaded from the hard disk via SeaBIOS instead of as an embedded elf image.
Please let me know if you would like anything else to assist with debugging.
Thanks!
Updated by Timothy Pearson almost 8 years ago
See attached log for SeaBIOS successful boot. Will try a newer Linux kernel shortly.
It is possible the ACPI failure is a red herring; without the nosmp parameter the boot hangs at:
[ 0.334972] smpboot: CPU0: AMD Opteron(tm) Processor 6262 HE (fam: 15, model: 01, stepping: 02)
Updated by Timothy Pearson almost 8 years ago
- File kgpe-d16-grub-linux-4.5-failure.log kgpe-d16-grub-linux-4.5-failure.log added
- File kgpe-d16-seabios-linux-4.5-success.log kgpe-d16-seabios-linux-4.5-success.log added
Test results with Linux 4.5 and the same kernel arguments. SeaBIOS works, GRUB fails (hangs).
Updated by Aaron Durbin almost 8 years ago
The e820 maps are significantly different between seabios and grub:
coreboot's memory map is this:
- 0000000000000000-0000000000000fff: CONFIGURATION TABLES
- 0000000000001000-000000000009ffff: RAM
- 00000000000a0000-00000000000bffff: RESERVED
- 00000000000c0000-00000000b7c89fff: RAM
- 00000000b7c8a000-00000000b7ffffff: CONFIGURATION TABLES
- 00000000b8000000-00000000bfffffff: RAM
- 00000000c0000000-00000000cfffffff: RESERVED
- 00000000fcb00000-00000000fcb03fff: RESERVED
- 00000000feb00000-00000000feb00fff: RESERVED
- 00000000fec00000-00000000fec00fff: RESERVED
- 00000000fed00000-00000000fed00fff: RESERVED
- 0000000100000000-0000000837ffffff: RAM
- 0000000838000000-000000083fffffff: RESERVED
seabios produced e820 memory map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000b7c89fff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000b7c8a000-0x00000000b7ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000b8000000-0x00000000bfffcfff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000bfffd000-0x00000000cfffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fcb00000-0x00000000fcb03fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feb00000-0x00000000feb00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000837ffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000838000000-0x000000083fffffff] reserved
grub produce e820 memory map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16
[ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000b7c89fff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000b7c8a000-0x00000000b7ffffff] type 16
[ 0.000000] BIOS-e820: [mem 0x00000000b8000000-0x00000000bfffffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000c0000000-0x00000000cfffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fcb00000-0x00000000fcb03fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feb00000-0x00000000feb00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000837ffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000838000000-0x000000083fffffff] reserved
That said, what specifically is the failure? The grub failure log doesn't really have anything in it, but the dmesg is cutoff.
Updated by Timothy Pearson almost 8 years ago
Aaron Durbin wrote:
That said, what specifically is the failure? The grub failure log doesn't really have anything in it, but the dmesg is cutoff.
It's not cut off. Linux simply hangs there and does not continue booting.
Updated by Timothy Pearson over 7 years ago
Another user hit this recently; they reported that the "nolapic" kernel option resolved the boot failure at the expense of SMP. Would be interesting to determine if this is a GRUB or coreboot regression.