I checked the arch/x86/platform/efi/early_printk.c.
In early_efi_scroll_up(), 2 mapping entries will be used for the src/dst screen buffer.
In drivers/acpi/acpica/tbutils.c, we've improved the early table loading code in
We now need 2 mapping entries:
1. One mapping entry is used for RSDT table mapping. Each RSDT entry contains an address
for another ACPI table.
2. For each entry in RSDP, we need another mapping entry to map the table to perform
necessary check/override before installing it.
When acpi_tb_parse_root_table() prints something through EFI earlyprintk console,
we'll have 4 mapping entries used.
The current 4 slots setting of early_ioremap() seems to be too small for such a use case.
I'm not 100% sure if this is the cause.
If it's the cause and we think both of the mappings are reasonable, we can simply
increase the FIX_BITMAPS_SLOTS defined in arch/x86/include/asm/fixmap.h.
What do you think of this?
Thanks and best regards
From: Zheng, Lv
Sent: Friday, August 22, 2014 9:43 AM
There is only limited entries in the x86 early mapping which is implemented by the
So this means for all __init call invoked for x86, if there was a early mapping in it, it
should be unmapped before exiting the __init call.
Using this rule, all __init call implementers can make sure that before entering the
__init call, the limited number of FIXMAP entries is
The following bisected commit just increase early mapping times from 1 to 2 in ACPICA
early table handling code.
The number of 2 is less than the number of available FIXMAP entries.
And ACPICA code has ensured that all mappings are correctly unmapped after the table
So we didn't break the rule.
We can offer a workaround in ACPICA to reduce mapping count from 2 to 1 using a global
But since this report sounds like that the root cause is earlyprintk=efi has broken the
above rule and the existing issue is triggered by
So could someone check the earlyprintk=efi code first?
I think earlyprintk=efi should either unmap the increased mapping or increase the number
of FIXMAP entries in case earlyprintk=efi
need additional early mappings.
Otherwise it will always be chances for earlyprintk=efi to break future code.
Thanks and best regards
> From: Matt Fleming [mailto:[email protected]
> Sent: Friday, August 22, 2014 4:52 AM
> On Tue, 19 Aug, at 04:16:58PM, Dave Young wrote:
> > Hi,
> > 3.16 kernel boot fail with earlyprintk=efi on my laptop.
> > It keeps scrolling at the bottom line of screen.
> > Bisected, the first bad commit is below:
> > commit 86dfc6f339886559d80ee0d4bd20fe5ee90450f0
> > Author: Lv Zheng <lv.zheng(a)intel.com>
> > Date: Fri Apr 4 12:38:57 2014 +0800
> > ACPICA: Tables: Fix table checksums verification before installation.
> > I did some debugging by enabling both serial and efi earlyprintk, below is
> > some debug dmesg, seems early_ioremap fails in scroll up function due to
> > no free slot, but I'm still not sure if the debug info is right or not.
> Thanks Dave, your callstack seems to make sense.
> Can you also enable early_ioremap_debug so that we can figure out where
> all the FIXMAP slots are going?
> Matt Fleming, Intel Open Source Technology Center