From: "bhe@redhat.com" <bhe@redhat.com> To: Dave Young <dyoung@redhat.com> Cc: Junichi Nomura <j-nomura@ce.jp.nec.com>, Chao Fan <fanc.fnst@cn.fujitsu.com>, Borislav Petkov <bp@alien8.de>, "kasong@redhat.com" <kasong@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 v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Date: Thu, 4 Apr 2019 11:10:30 +0800 [thread overview] Message-ID: <20190404031030.GU7627@MiWiFi-R3L-srv> (raw) In-Reply-To: <20190404030037.GT7627@MiWiFi-R3L-srv> On 04/04/19 at 11:00am, Baoquan He wrote: > On 04/04/19 at 10:52am, Dave Young wrote: > > On 04/04/19 at 01:23am, Junichi Nomura wrote: > > > Hi Dave and Chao, > > > > > > On 4/3/19 6:02 PM, Chao Fan wrote: > > > > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote: > > > >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote: > > > >>> Fix 3. need more debugging, have you or Junichi run tests on more real > > > >>> hardware, maybe it is easier to reproduce on real hardware, I'm glad to > > > >>> help to try test patch or provide any help. > > > >> > > > >> I am still testing in real hardware. > > > > > > > > Hi Dave, > > > > > > > > I find a Fujitsu Desktop PC to test it. > > > > Without this PATCH, it failed to kexec and kdump. > > > > With this PATCH, it succeed to kexec. > > > > But failed to kdump. From the log, I think it didn't jump to the second > > > > kernel, just reboot after panic. I have not figured out what's the > > > > problem, but it seems not caused by this PATCH. > > > > So I still think this PATCH works for the Fujitsu Desktop PC. > > > > > > > > As for your issue, I think there may be some problems related to specified > > > > hardware. Are you using a Lenovo laptop? > > > > > > > > And I am not sure how Nomura tested it. > > > > > > I've tested 3 different models of EFI-booted baremetal servers with both > > > normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3, > > > the problem always reproduced without the patch and disappears with the patch. > > > > Hmm, both of my two laptops (Thinkpad T480s and T420) failed to boot with kexec. > > > > I will see if I can find something, but it may need more time because > > early console does not work especially after kexec. > > Dave, can you try below patch to print debugging message and hang kernel > to check the outputting? The hang is necessary, otherwise later printk > printking will overwrite it. > > diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c > index c0d6c560df69..68119547c4aa 100644 > --- a/arch/x86/boot/compressed/misc.c > +++ b/arch/x86/boot/compressed/misc.c > @@ -351,9 +351,6 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap, > /* Clear flags intended for solely in-kernel use. */ > boot_params->hdr.loadflags &= ~KASLR_FLAG; > > - /* Save RSDP address for later use. */ > - boot_params->acpi_rsdp_addr = get_rsdp_addr(); > - > sanitize_boot_params(boot_params); > > if (boot_params->screen_info.orig_video_mode == 7) { > @@ -370,6 +367,10 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap, > console_init(); > debug_putstr("early console in extract_kernel\n"); > + /* Save RSDP address for later use. */ + boot_params->acpi_rsdp_addr = get_rsdp_addr(); + + error("Hang kernel for kexec debugging"); Sorry, here I means calling error() to hang kernel after calling get_rsdp_addr(). > free_mem_ptr = heap; /* Heap */ > free_mem_end_ptr = heap + BOOT_HEAP_SIZE; >
WARNING: multiple messages have this Message-ID (diff)
From: "bhe@redhat.com" <bhe@redhat.com> To: Dave Young <dyoung@redhat.com> Cc: Chao Fan <fanc.fnst@cn.fujitsu.com>, "kasong@redhat.com" <kasong@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>, Borislav Petkov <bp@alien8.de>, Junichi Nomura <j-nomura@ce.jp.nec.com> Subject: Re: [PATCH v2] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Date: Thu, 4 Apr 2019 11:10:30 +0800 [thread overview] Message-ID: <20190404031030.GU7627@MiWiFi-R3L-srv> (raw) In-Reply-To: <20190404030037.GT7627@MiWiFi-R3L-srv> On 04/04/19 at 11:00am, Baoquan He wrote: > On 04/04/19 at 10:52am, Dave Young wrote: > > On 04/04/19 at 01:23am, Junichi Nomura wrote: > > > Hi Dave and Chao, > > > > > > On 4/3/19 6:02 PM, Chao Fan wrote: > > > > On Wed, Apr 03, 2019 at 04:23:06PM +0800, Chao Fan wrote: > > > >> On Wed, Apr 03, 2019 at 04:09:16PM +0800, Dave Young wrote: > > > >>> Fix 3. need more debugging, have you or Junichi run tests on more real > > > >>> hardware, maybe it is easier to reproduce on real hardware, I'm glad to > > > >>> help to try test patch or provide any help. > > > >> > > > >> I am still testing in real hardware. > > > > > > > > Hi Dave, > > > > > > > > I find a Fujitsu Desktop PC to test it. > > > > Without this PATCH, it failed to kexec and kdump. > > > > With this PATCH, it succeed to kexec. > > > > But failed to kdump. From the log, I think it didn't jump to the second > > > > kernel, just reboot after panic. I have not figured out what's the > > > > problem, but it seems not caused by this PATCH. > > > > So I still think this PATCH works for the Fujitsu Desktop PC. > > > > > > > > As for your issue, I think there may be some problems related to specified > > > > hardware. Are you using a Lenovo laptop? > > > > > > > > And I am not sure how Nomura tested it. > > > > > > I've tested 3 different models of EFI-booted baremetal servers with both > > > normal kexec and panic kexec. So far as I've tried Linus's v5.1-rc3, > > > the problem always reproduced without the patch and disappears with the patch. > > > > Hmm, both of my two laptops (Thinkpad T480s and T420) failed to boot with kexec. > > > > I will see if I can find something, but it may need more time because > > early console does not work especially after kexec. > > Dave, can you try below patch to print debugging message and hang kernel > to check the outputting? The hang is necessary, otherwise later printk > printking will overwrite it. > > diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c > index c0d6c560df69..68119547c4aa 100644 > --- a/arch/x86/boot/compressed/misc.c > +++ b/arch/x86/boot/compressed/misc.c > @@ -351,9 +351,6 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap, > /* Clear flags intended for solely in-kernel use. */ > boot_params->hdr.loadflags &= ~KASLR_FLAG; > > - /* Save RSDP address for later use. */ > - boot_params->acpi_rsdp_addr = get_rsdp_addr(); > - > sanitize_boot_params(boot_params); > > if (boot_params->screen_info.orig_video_mode == 7) { > @@ -370,6 +367,10 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap, > console_init(); > debug_putstr("early console in extract_kernel\n"); > + /* Save RSDP address for later use. */ + boot_params->acpi_rsdp_addr = get_rsdp_addr(); + + error("Hang kernel for kexec debugging"); Sorry, here I means calling error() to hang kernel after calling get_rsdp_addr(). > free_mem_ptr = heap; /* Heap */ > free_mem_end_ptr = heap + BOOT_HEAP_SIZE; > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-04-04 3:10 UTC|newest] Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-22 11:03 [PATCH] x86/boot: Use EFI setup data if provided Junichi Nomura 2019-03-22 15:23 ` Borislav Petkov 2019-03-25 0:27 ` Junichi Nomura 2019-03-25 0:27 ` Junichi Nomura 2019-03-25 6:01 ` Dave Young 2019-03-25 6:01 ` Dave Young 2019-03-25 6:19 ` Dave Young 2019-03-25 6:19 ` Dave Young 2019-03-25 6:45 ` Kairui Song 2019-03-25 6:45 ` Kairui Song 2019-03-25 6:47 ` Junichi Nomura 2019-03-25 6:47 ` Junichi Nomura 2019-03-25 6:59 ` Dave Young 2019-03-25 6:59 ` Dave Young 2019-03-25 8:27 ` [PATCH v2] " Junichi Nomura 2019-03-25 8:27 ` Junichi Nomura 2019-03-25 8:54 ` Boris Petkov 2019-03-25 8:54 ` Boris Petkov 2019-03-25 9:25 ` [PATCH v2] x86/boot: Don't try to search RSDP from EFI when kexec-booted Junichi Nomura 2019-03-25 9:25 ` Junichi Nomura 2019-03-25 10:15 ` [PATCH v2] x86/boot: Use EFI setup data if provided Dave Young 2019-03-25 10:15 ` Dave Young 2019-03-25 10:36 ` Junichi Nomura 2019-03-25 10:36 ` Junichi Nomura 2019-03-25 11:16 ` Dave Young 2019-03-25 11:16 ` Dave Young 2019-03-25 12:01 ` Borislav Petkov 2019-03-25 12:01 ` Borislav Petkov 2019-03-25 12:23 ` Dave Young 2019-03-25 12:23 ` Dave Young 2019-03-25 12:32 ` Borislav Petkov 2019-03-25 12:32 ` Borislav Petkov 2019-03-25 23:10 ` Junichi Nomura 2019-03-25 23:10 ` Junichi Nomura 2019-03-26 12:46 ` Dave Young 2019-03-26 12:46 ` Dave Young 2019-03-26 13:57 ` Borislav Petkov 2019-03-26 13:57 ` Borislav Petkov 2019-03-27 1:48 ` bhe 2019-03-27 1:48 ` bhe 2019-03-27 12:14 ` Borislav Petkov 2019-03-27 12:14 ` Borislav Petkov 2019-03-28 4:17 ` Junichi Nomura 2019-03-28 4:17 ` Junichi Nomura 2019-03-28 6:26 ` Chao Fan 2019-03-28 6:26 ` Chao Fan 2019-03-28 6:43 ` bhe 2019-03-28 6:43 ` bhe 2019-03-28 7:43 ` Junichi Nomura 2019-03-28 7:43 ` Junichi Nomura 2019-03-28 15:52 ` Borislav Petkov 2019-03-28 15:52 ` Borislav Petkov 2019-03-29 3:05 ` Junichi Nomura 2019-03-29 3:05 ` Junichi Nomura 2019-03-29 8:39 ` Borislav Petkov 2019-03-29 8:39 ` Borislav Petkov 2019-03-29 9:05 ` Chao Fan 2019-03-29 9:05 ` Chao Fan 2019-03-29 9:16 ` Borislav Petkov 2019-03-29 9:16 ` Borislav Petkov 2019-03-29 9:37 ` Junichi Nomura 2019-03-29 9:37 ` Junichi Nomura 2019-03-29 9:44 ` Chao Fan 2019-03-29 9:44 ` Chao Fan 2019-03-29 9:56 ` Junichi Nomura 2019-03-29 9:56 ` Junichi Nomura 2019-03-29 7:20 ` [PATCH] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Junichi Nomura 2019-03-29 7:20 ` Junichi Nomura 2019-03-29 7:49 ` bhe 2019-03-29 7:49 ` bhe 2019-03-29 8:29 ` Chao Fan 2019-03-29 8:29 ` Chao Fan 2019-03-29 8:39 ` Junichi Nomura 2019-03-29 8:39 ` Junichi Nomura 2019-03-29 9:18 ` Chao Fan 2019-03-29 9:18 ` Chao Fan 2019-03-29 9:16 ` bhe 2019-03-29 9:16 ` bhe 2019-03-29 9:20 ` Chao Fan 2019-03-29 9:20 ` Chao Fan 2019-04-01 0:08 ` [PATCH v2] " Junichi Nomura 2019-04-01 0:08 ` Junichi Nomura 2019-04-02 9:41 ` Chao Fan 2019-04-02 9:41 ` Chao Fan 2019-04-02 9:53 ` Junichi Nomura 2019-04-02 9:53 ` Junichi Nomura 2019-04-02 11:06 ` Chao Fan 2019-04-02 11:06 ` Chao Fan 2019-04-02 10:22 ` Junichi Nomura 2019-04-02 10:22 ` Junichi Nomura 2019-04-02 12:03 ` Dave Young 2019-04-02 12:03 ` Dave Young 2019-04-03 5:35 ` Chao Fan 2019-04-03 5:35 ` Chao Fan 2019-04-03 5:53 ` Dave Young 2019-04-03 5:53 ` Dave Young 2019-04-03 6:39 ` Dave Young 2019-04-03 6:39 ` Dave Young 2019-04-03 7:30 ` Chao Fan 2019-04-03 7:30 ` Chao Fan 2019-04-03 7:50 ` bhe 2019-04-03 7:50 ` bhe 2019-04-03 8:23 ` Dave Young 2019-04-03 8:23 ` Dave Young 2019-04-03 8:26 ` Dave Young 2019-04-03 8:26 ` Dave Young 2019-04-03 16:14 ` Borislav Petkov 2019-04-03 16:14 ` Borislav Petkov 2019-04-04 1:02 ` Chao Fan 2019-04-04 1:02 ` Chao Fan 2019-04-03 9:28 ` Chao Fan 2019-04-03 9:28 ` Chao Fan 2019-04-03 7:21 ` Chao Fan 2019-04-03 7:21 ` Chao Fan 2019-04-03 8:09 ` Dave Young 2019-04-03 8:09 ` Dave Young 2019-04-03 8:23 ` Chao Fan 2019-04-03 8:23 ` Chao Fan 2019-04-03 9:02 ` Chao Fan 2019-04-03 9:02 ` Chao Fan 2019-04-03 9:39 ` Chao Fan 2019-04-03 9:39 ` Chao Fan 2019-04-04 1:23 ` Junichi Nomura 2019-04-04 1:23 ` Junichi Nomura 2019-04-04 2:52 ` Dave Young 2019-04-04 2:52 ` Dave Young 2019-04-04 3:00 ` bhe 2019-04-04 3:00 ` bhe 2019-04-04 3:10 ` bhe [this message] 2019-04-04 3:10 ` bhe 2019-04-04 3:22 ` Dave Young 2019-04-04 3:22 ` Dave Young 2019-04-04 6:41 ` Dave Young 2019-04-04 6:41 ` Dave Young 2019-04-04 7:20 ` Chao Fan 2019-04-04 7:20 ` Chao Fan 2019-04-04 7:41 ` Dave Young 2019-04-04 7:41 ` Dave Young 2019-04-04 7:48 ` Chao Fan 2019-04-04 7:48 ` Chao Fan 2019-04-04 12:22 ` Borislav Petkov 2019-04-04 12:22 ` Borislav Petkov 2019-04-04 14:08 ` Dave Young 2019-04-04 14:08 ` Dave Young 2019-04-03 8:18 ` Dave Young 2019-04-03 8:18 ` Dave Young 2019-04-02 10:25 ` [PATCH v3] " Junichi Nomura 2019-04-02 10:25 ` Junichi Nomura 2019-04-04 7:32 ` Dave Young 2019-04-04 7:32 ` Dave Young 2019-04-04 12:24 ` Borislav Petkov 2019-04-04 12:24 ` Borislav Petkov 2019-04-04 14:12 ` Dave Young 2019-04-04 14:12 ` Dave Young 2019-04-04 14:41 ` Borislav Petkov 2019-04-04 14:41 ` Borislav Petkov 2019-04-05 1:36 ` Dave Young 2019-04-05 1:36 ` Dave Young 2019-04-05 4:19 ` Junichi Nomura 2019-04-05 4:19 ` Junichi Nomura 2019-03-28 23:11 ` [PATCH v2] x86/boot: Use EFI setup data if provided bhe 2019-03-28 23:11 ` bhe 2019-03-29 3:34 ` Junichi Nomura 2019-03-29 3:34 ` Junichi Nomura 2019-03-29 3:52 ` bhe 2019-03-29 3:52 ` bhe 2019-03-29 5:16 ` Junichi Nomura 2019-03-29 5:16 ` Junichi Nomura 2019-03-25 7:27 ` [PATCH] " Baoquan He 2019-03-25 7:53 ` Borislav Petkov 2019-03-25 8:21 ` Baoquan He 2019-03-25 8:43 ` Thomas Gleixner 2019-03-25 9:03 ` Baoquan He
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=20190404031030.GU7627@MiWiFi-R3L-srv \ --to=bhe@redhat.com \ --cc=bp@alien8.de \ --cc=dyoung@redhat.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.