From: Dave Young <dyoung@redhat.com>
To: Kairui Song <kasong@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>,
Junichi Nomura <j-nomura@ce.jp.nec.com>,
Chao Fan <fanc.fnst@cn.fujitsu.com>, Baoquan He <bhe@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernels
Date: Wed, 17 Apr 2019 15:08:18 +0800 [thread overview]
Message-ID: <20190417070818.GE8411@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <CACPcB9cf0dtXFF+kpzBYXm3nvvG3uPDf81P1fa19+D37H9BaEg@mail.gmail.com>
On 04/17/19 at 02:00pm, Kairui Song wrote:
> On Wed, Apr 17, 2019 at 12:57 PM Dave Young <dyoung@redhat.com> wrote:
> >
> > On 04/17/19 at 09:38am, Dave Young wrote:
> > > On 04/16/19 at 03:22pm, Borislav Petkov wrote:
> > > > On Tue, Apr 16, 2019 at 07:41:33PM +0800, Dave Young wrote:
> > > > > On 04/16/19 at 11:52am, Borislav Petkov wrote:
> > > > > > I'll queue the below in the next days if there are no more complaints:
> > > > >
> > > > > As for the kexec breakage, even with the V3 patch, kexec still hangs on
> > > > > a Lenovo T420 laptop. Kairui also reproduced the problem. So can we
> > > > > wait a few days see if we can make some progress to find the cause?
> > > >
> > > > How is applying this patch going to change anything?
> > > >
> > > > I was told that the breakage is there even without it...
> > >
> > > Without this patch, the bug happens in the efi_get_rsdp.. function, this
> > > patch tries to fix that by adding kexec_get.. but the new introduced
> > > kexec_* function does not work on some laptops, so it is not a 100% good
> > > fix, I hoped we can get it working for all known issues. But if we can
> > > not do it eg. within one week we can go with this version and leave the
> > > laptop issue as a known issue.
> > >
> >
> > Latest debugging status:
> >
> > Kexec boot works with commenting out some code like below, so the guid
> > cmp (memcmp) caused a system reset), still need to find out why:
> >
> > diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
> > index d9f9abd63c68..13e7a23ae94c 100644
> > --- a/arch/x86/boot/compressed/acpi.c
> > +++ b/arch/x86/boot/compressed/acpi.c
> > @@ -95,10 +95,12 @@ __efi_get_rsdp_addr(unsigned long config_tables, unsigned int nr_tables,
> > table = tbl->table;
> > }
> >
> > +/*
> > if (!(efi_guidcmp(guid, ACPI_TABLE_GUID)))
> > rsdp_addr = table;
> > else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID)))
> > return table;
> > +*/
> > }
> >
> > return rsdp_addr;
> > @@ -291,9 +293,10 @@ acpi_physical_address get_rsdp_addr(void)
> > if (!pa)
> > pa = kexec_get_rsdp_addr();
> >
> > +/*
> > if (!pa)
> > pa = efi_get_rsdp_addr();
> > -
> > +*/
> > if (!pa)
> > pa = bios_get_rsdp_addr();
> >
> >
>
> Hi Dave, for this case I think it's just because GCC will found the
> loop does nothing, and optimize out the whole loop in
> __efi_get_rsdp_addr and will no longer read the actual nr_table value.
>
> I can fix the boot error on T420 with your patch, but if I add
> anything, like a hardcode value assignment with the right value for
> acpi_rsdp in the loop, it will reset the machine. But set acpi_rsdp
> with a right initial value out side the loop works fine.
> If the loop condition is false, then there should be no difference
> between just comment out the line you mentioned and add an assignment.
> Else it just assign the value multiple times, not very reasonable but
> shouldn't fail.
>
> And, I inspected the generated ASM code also suggest the same thing.
> So still, access the systab memory is the cause of the system reset on
> certain machines.
Makse sense, my previous debug also point to some systab accessing.
Probably some early pg table mess up.
Thanks
Dave
next prev parent reply other threads:[~2019-04-17 7:08 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 23:10 [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Junichi Nomura
2019-04-10 17:14 ` Borislav Petkov
2019-04-10 23:34 ` Junichi Nomura
2019-04-11 8:09 ` Borislav Petkov
2019-04-11 8:16 ` Junichi Nomura
2019-04-11 8:37 ` Borislav Petkov
2019-04-11 9:13 ` Junichi Nomura
2019-04-11 9:21 ` Boris Petkov
2019-04-11 9:32 ` Junichi Nomura
2019-04-11 9:40 ` Boris Petkov
2019-04-11 12:58 ` Borislav Petkov
2019-04-12 2:54 ` Junichi Nomura
2019-04-12 8:49 ` Borislav Petkov
2019-04-12 13:35 ` Borislav Petkov
2019-04-15 7:01 ` Junichi Nomura
2019-04-15 9:07 ` Borislav Petkov
2019-04-15 10:25 ` Borislav Petkov
2019-04-15 23:00 ` Junichi Nomura
2019-04-15 23:14 ` Junichi Nomura
2019-04-16 9:45 ` Borislav Petkov
2019-04-16 23:09 ` kexec crash on OVMF i386 + x86_64 kernel (Re: [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel) Junichi Nomura
2019-04-17 5:14 ` Dave Young
2019-04-17 17:57 ` Prakhya, Sai Praneeth
2019-04-16 9:40 ` [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Borislav Petkov
2019-04-16 9:52 ` [PATCH] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernels Borislav Petkov
2019-04-16 10:02 ` Ingo Molnar
2019-04-16 10:31 ` Borislav Petkov
2019-04-16 11:41 ` Dave Young
2019-04-16 13:22 ` Borislav Petkov
2019-04-17 1:38 ` Dave Young
2019-04-17 4:57 ` Dave Young
2019-04-17 6:00 ` Kairui Song
2019-04-17 7:08 ` Dave Young [this message]
2019-04-17 8:22 ` Borislav Petkov
2019-04-18 1:24 ` Dave Young
2019-04-19 8:34 ` [RFC PATCH] kexec, x86/boot: map systab region in identity mapping before accessing it Kairui Song
2019-04-19 8:58 ` Baoquan He
2019-04-19 9:39 ` Kairui Song
2019-04-16 22:44 ` [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Junichi Nomura
2019-04-17 7:02 ` Dave Young
2019-04-17 8:54 ` Borislav Petkov
2019-04-17 9:02 ` Borislav Petkov
2019-04-17 10:31 ` Chao Fan
2019-04-11 8:42 ` Baoquan He
2019-04-11 9:14 ` Junichi Nomura
2019-04-12 0:23 ` Baoquan He
2019-04-15 7:46 ` Dave Young
2019-06-06 19:22 ` [tip:x86/boot] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernels tip-bot for Junichi Nomura
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=20190417070818.GE8411@dhcp-128-65.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=fanc.fnst@cn.fujitsu.com \
--cc=j-nomura@ce.jp.nec.com \
--cc=kasong@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--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).