From: Dave Young <dyoung@redhat.com>
To: Matt Fleming <matt@console-pimps.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
matt.fleming@intel.com, linux-efi@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@acpica.org, lenb@kernel.org, rafael.j.wysocki@intel.com,
robert.moore@intel.com, stable@vger.kernel.org,
gregkh@linuxfoundation.org
Subject: Re: [PATCH RFC] x86 early_ioremap: increase FIX_BTMAPS_SLOTS to 8
Date: Mon, 15 Sep 2014 10:38:05 +0800 [thread overview]
Message-ID: <20140915023805.GA2700@darkstar.nay.redhat.com> (raw)
In-Reply-To: <20140914141412.GJ18582@console-pimps.org>
On 09/14/14 at 03:14pm, Matt Fleming wrote:
> On Tue, 26 Aug, at 05:06:41PM, Dave Young wrote:
> > 3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the
> > bottom line of screen.
> >
> > Bisected, the first bad commit is below:
> > commit 86dfc6f339886559d80ee0d4bd20fe5ee90450f0
> > Author: Lv Zheng <lv.zheng@intel.com>
> > Date: Fri Apr 4 12:38:57 2014 +0800
> >
> > ACPICA: Tables: Fix table checksums verification before installation.
>
> [...]
>
> > Quote reply from Lv.zheng about the early ioremap slot usage in this case:
> >
> > """
> > 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.
> > """
> >
> > Thus increase the slot to 8 in this patch to fix this issue.
> > boot-time mappings become 512 page with this patch.
>
> This analysis and solution makes sense to me, but I was really hoping
> for one of the x86 maintainers to ACK the below patch. I'm happy to take
> it through the EFI tree if it's not picked up into tip meanwhile.
>
> Also, Dave, it sounds like this should be tagged for stable if the bug
> has been around since v3.16?
Matt, yes, it should be a stable issue, ccing Greg and stable list.
>
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > I'm not sure if this is ok in 32bit, review and comments are appreciated.
> > arch/x86/include/asm/fixmap.h | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > Index: linux/arch/x86/include/asm/fixmap.h
> > ===================================================================
> > --- linux.orig/arch/x86/include/asm/fixmap.h
> > +++ linux/arch/x86/include/asm/fixmap.h
> > @@ -106,14 +106,14 @@ enum fixed_addresses {
> > __end_of_permanent_fixed_addresses,
> >
> > /*
> > - * 256 temporary boot-time mappings, used by early_ioremap(),
> > + * 512 temporary boot-time mappings, used by early_ioremap(),
> > * before ioremap() is functional.
> > *
> > - * If necessary we round it up to the next 256 pages boundary so
> > + * If necessary we round it up to the next 512 pages boundary so
> > * that we can have a single pgd entry and a single pte table:
> > */
> > #define NR_FIX_BTMAPS 64
> > -#define FIX_BTMAPS_SLOTS 4
> > +#define FIX_BTMAPS_SLOTS 8
> > #define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
> > FIX_BTMAP_END =
> > (__end_of_permanent_fixed_addresses ^
>
>
> --
> Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-09-15 2:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 9:06 [PATCH RFC] x86 early_ioremap: increase FIX_BTMAPS_SLOTS to 8 Dave Young
2014-08-28 6:40 ` Zheng, Lv
2014-09-14 14:14 ` Matt Fleming
2014-09-15 2:38 ` Dave Young [this message]
2014-09-15 2:42 ` Greg KH
2014-09-15 3:33 ` Dave Young
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140915023805.GA2700@darkstar.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=devel@acpica.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=matt@console-pimps.org \
--cc=mingo@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).