RE: kernel boot fail with efi earlyprintk (bisected)

[Zheng, Lv]

Hi,

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 acpi_tb_parse_root_table().
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
-Lv

> From: Zheng, Lv
> Sent: Friday, August 22, 2014 9:43 AM
> 
> Hi,
> 
> There is only limited entries in the x86 early mapping which is implemented by the FIXMAP.
> 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
> enough.
> 
> 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 initialization.
> 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 option.
> 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
> this cleanup.
> 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
> -Lv
> 
> > From: Matt Fleming [mailto:matt@xxxxxxxxxxxxxxxxx]
> > 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@xxxxxxxxx>
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/