Re: 3.9 breaks EFI boot on E350

From: Christian König
Date: Thu May 16 2013 - 08:50:05 EST

Am 16.05.2013 11:41, schrieb Christian König:
Am 15.05.2013 22:57, schrieb Yinghai Lu:
On Wed, May 15, 2013 at 8:20 AM, Christian König
<christian.koenig@xxxxxxx> wrote:
Am 15.05.2013 16:46, schrieb Yinghai Lu:

On Wed, May 15, 2013 at 2:46 AM, Christian König
<christian.koenig@xxxxxxx> wrote:
Hi guys,

the following commit breaks booting my E350 based test system in EFI

commit 8d57470d8f859635deffe3919d7d4867b488b85a
Author: Yinghai Lu <yinghai@xxxxxxxxxx>
Date: Fri Nov 16 19:38:58 2012 -0800

x86, mm: setup page table in top-down

This commit was supposed to fix it but obviously there still seem to be
bugs left in 3.9

commit 98e7a989979b185f49e86ddaed2ad6890299d9f0
Author: Yinghai Lu <yinghai@xxxxxxxxxx>
Date: Wed Mar 6 20:18:21 2013 -0800

x86, mm: Make sure to find a 2M free block for the first mapped

Henrik reported that his MacAir 3.1 would not boot with

| commit 8d57470d8f859635deffe3919d7d4867b488b85a
| Date: Fri Nov 16 19:38:58 2012 -0800
| x86, mm: setup page table in top-down

can you send out working boot log with memory map?

you need to boot system with "debug ignore_loglevel"

Sure, dmesg output it attached. Let me know if you need anything else.

[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000006ea07fff] usable
[ 0.000000] BIOS-e820: [mem 0x000000006ea08000-0x000000006ea55fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000006ea56000-0x000000006f47efff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000006f47f000-0x000000006f87bfff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000006f87c000-0x000000006f87cfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000006f87d000-0x000000006f883fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000006f884000-0x000000006fc97fff] usable
[ 0.000000] BIOS-e820: [mem 0x000000006fc98000-0x000000006fef2fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000006fef3000-0x000000006fefffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed61000-0x00000000fed70fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fef00000-0x00000000ffffffff] reserved

the kernel code should handle the memmap properly. and I use user
memmap to simulate the
that memmap, kernel could boot well.

so your system does not have serial port?

Unfortunately not, this board doesn't even have an PCI slot otherwise I could install a card there.

Anything else I could do?

Ups, the board DOES have a serial port, and I've got a log now that shows the mentioned patch above isn't the root cause.

After commit 8d57470d8f859635deffe3919d7d4867b488b85a it indeed crashes very early in the boot sequence, but commit 98e7a989979b185f49e86ddaed2ad6890299d9f0 fixes that and now it crashes while trying to unpack the initrd with a completely different backtrace.

Sorry for the noise, one black screen while bisecting is as good as another, but obviously not the same root cause.



Can you boot failed kernel on your system with "earlyprintk=ttyS0,115200
memblock=debug" to see
where is crash or hang?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at