Re: EFI stub kexec probelm

[Dave Young]

On 02/16/17 at 07:35pm, Eric W. Biederman wrote:
> Paweł Lenkow  writes:
> 
> > Hi!
> >
> > I am trying to run EFI stub kernel using kexec and unfortunately 2nd kernel
> > crashes.
> 
> Adding the kexec list as there may be someone there who may be more
> knowledgeable about our problem.
> 
> > First kernel is loaded by UEFI, starts simple init with shell and then
> > I am loading the same image using kexec.
> >
> > It looks like a lack of correct mappings for EFI tables because it
> > calls address zero (RDI register) in efi_call.
> >
> > Does kernel support such configuration?
> >
> > If yes what could be wrong?
> 
> I don't know exactly where the support is, I haven't looked recently.
> 
> There is a major challenge with efi.  The call to place efi in virtual
> mode may be called exactly once.  There has been work on at least ia64
> to make it possible to capture the efi virtual address bass and pass it
> through to the kernel calling kexec.  I don't remember seeing the work
> to do that happen on other platforms.
> 
> I personally think we should just abandon running efi in virtual mode
> and always run efi in physicall mode, but the feedback when I suggested
> that was that efi didn't actually work if you did that.  *Shrug*
> 
> Given that efi_enter_virtual_mode is in your call trace I am guessing
> that the problem is the historical problem I have mentioned above.
> 
> Eric
> 
> 
> 
> > Using grub-efi all works fine, but it is not enough for me.
> >
> > See log below:
> >
> >
> > / # kexec -l /mnt/INSTALL/vmlinuz -s

What is the kexec-tools version? And does kexec -l works (without -s)?

A test with efi=debug parameters may help, also full logs of both
pre-kexec boot and post-kexec boot could also help to find something..

Thanks
Dave

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: EFI stub kexec probelm

[Eric W. Biederman]

Paweł Lenkow  writes:

> Hi!
>
> I am trying to run EFI stub kernel using kexec and unfortunately 2nd kernel
> crashes.

Adding the kexec list as there may be someone there who may be more
knowledgeable about our problem.

> First kernel is loaded by UEFI, starts simple init with shell and then
> I am loading the same image using kexec.
>
> It looks like a lack of correct mappings for EFI tables because it
> calls address zero (RDI register) in efi_call.
>
> Does kernel support such configuration?
>
> If yes what could be wrong?

I don't know exactly where the support is, I haven't looked recently.

There is a major challenge with efi.  The call to place efi in virtual
mode may be called exactly once.  There has been work on at least ia64
to make it possible to capture the efi virtual address bass and pass it
through to the kernel calling kexec.  I don't remember seeing the work
to do that happen on other platforms.

I personally think we should just abandon running efi in virtual mode
and always run efi in physicall mode, but the feedback when I suggested
that was that efi didn't actually work if you did that.  *Shrug*

Given that efi_enter_virtual_mode is in your call trace I am guessing
that the problem is the historical problem I have mentioned above.

Eric



> Using grub-efi all works fine, but it is not enough for me.
>
> See log below:
>
>
> / # kexec -l /mnt/INSTALL/vmlinuz -s
> / # kexec -e
> [  625.520845] kexec_core: Starting new kernel
> [0.00] Linux version 4.10.0-rc8 (plenkow@plenkow-PC) (gcc version 
> 5.4.0 (GCC) ) #2 SMP Wed Feb 15 09:49:05 CET 2017
> [0.00] Command line:
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
> [0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
> [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
> bytes, using 'compacted' format.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x00057fff] usable
> [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
> [0.00] BIOS-e820: [mem 0x00059000-0x00085fff] usable
> [0.00] BIOS-e820: [mem 0x00086000-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0xa238cfff] usable
> [0.00] BIOS-e820: [mem 0xa238d000-0xa238dfff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xa238e000-0xa23d7fff] reserved
> [0.00] BIOS-e820: [mem 0xa23d8000-0xb867dfff] usable
> [0.00] BIOS-e820: [mem 0xb867e000-0xbaf7dfff] reserved
> [0.00] BIOS-e820: [mem 0xbaf7e000-0xbcf7dfff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xbcf7e000-0xbcffdfff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xbcffe000-0xbcffefff] usable
> [0.00] BIOS-e820: [mem 0xbcfff000-0xbfff] reserved
> [0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
> [0.00] BIOS-e820: [mem 0xfd00-0xfe7f] reserved
> [0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
> [0.00] BIOS-e820: [mem 0xfed84000-0xfed84fff] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xff90-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00023dff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] extended physical RAM map:
> [0.00] reserve setup_data: [mem 
> 0x-0x000502bf] usable
> [0.00] reserve setup_data: [mem 
> 0x000502c0-0x0005032f] usable
> [0.00] reserve setup_data: [mem 
> 0x00050330-0x00057fff] usable
> [0.00] reserve setup_data: [mem 
> 0x00058000-0x00058fff] reserved
> [0.00] reserve setup_data: [mem 
> 0x00059000-0x00085fff] usable
> [0.00] reserve setup_data: [mem 
> 0x00086000-0x000f] reserved
> [0.00] reserve setup_data: [mem 
> 

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

[Xunlei Pang]

On 01/26/2017 at 02:44 PM, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
>> The hardware machine check is hard to reproduce, but the mce code of
>> RHEL7 is quite the same as that of tip/master, anyway we are able to
>> inject software mce to reproduce it.
> Please give me your exact steps so that I can try to reproduce it here
> too.
>

Hi Borislav,

I tried to use qemu to inject SRAO("mce -b 0 0 0xb100 0x5 0x0 0x0"),
it works well in 1st kernel, but it doesn't work for 1st kernel after kdump 
boots(seems
the cpus remain in 1st kernel don't respond to the simulated broadcasting mce).

But in theory, we know cpus belong to kdump kernel can't respond to the
old mce handler, so a single SRAO injection in 1st kernel should be similar.
For example, I used "... -smp 2 -cpu Haswell" to launch a simulation with 
broadcast
mce supported, and inject SRAO to cpu0 only through qemu monitor
"mce 0 0 0xb100 0x5 0x0 0x0", cpu0 will timeout/panic and reboot
the machine as follows(running on linux-4.9):
  Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception 
handler
  Kernel Offset: disabled
  Rebooting in 30 seconds..

Regards,
Xunlei

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec on panic

[Marc Milgram]

It is possible to boot into a new kernel as documented on the following 
page:


https://access.redhat.com/discussions/682993

That said, even though this is documented on a Red Hat page, Red Hat 
does not officially support it.


Marc

On 02/15/2017 12:29 PM, Clif Houck wrote:

Is it possible to kexec on demand (not panic!) into another kernel with
the idea being to avoid a reboot?

For instance, say you had Linux running in a ramdisk, and all that
ramdisk Linux did was lay down a bootable Linux image onto the main
disk, and then awaited a command to kexec to the Linux image on disk? Is
something like that possible? Would I still need to specially craft the
initrd? If so, is there any literature available on how to do that?

Thanks,
Clif Houck

On 2/10/2017 9:43 AM, Petr Tesarik wrote:

On Fri, 10 Feb 2017 10:14:02 +0200
Denys Fedoryshchenko  wrote:


Hello,

After years of using kexec and recent unpleasant experience with modern
(supposed to be blazing fast to boot) hardware that need 5-10 minutes
just to pass POST tests,
one question came up to me:
Is it possible anyhow to execute regular (not special "panic" one to
capture crash data) kexec on panic to reduce reboot time?


No. But you can load a specially crafted panic initrd which kexec's
back to the production kernel.

HTH,
Petr T

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec on panic

[Clif Houck]

Is it possible to kexec on demand (not panic!) into another kernel with
the idea being to avoid a reboot?

For instance, say you had Linux running in a ramdisk, and all that
ramdisk Linux did was lay down a bootable Linux image onto the main
disk, and then awaited a command to kexec to the Linux image on disk? Is
something like that possible? Would I still need to specially craft the
initrd? If so, is there any literature available on how to do that?

Thanks,
Clif Houck

On 2/10/2017 9:43 AM, Petr Tesarik wrote:
> On Fri, 10 Feb 2017 10:14:02 +0200
> Denys Fedoryshchenko  wrote:
> 
>> Hello,
>>
>> After years of using kexec and recent unpleasant experience with modern 
>> (supposed to be blazing fast to boot) hardware that need 5-10 minutes 
>> just to pass POST tests,
>> one question came up to me:
>> Is it possible anyhow to execute regular (not special "panic" one to 
>> capture crash data) kexec on panic to reduce reboot time?
> 
> No. But you can load a specially crafted panic initrd which kexec's
> back to the production kernel.
> 
> HTH,
> Petr T
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v32 07/13] arm64: hibernate: preserve kdump image around hibernation

[James Morse]

Hi Akashi,

On 07/02/17 08:08, AKASHI Takahiro wrote:
> Since arch_kexec_protect_crashkres() removes a mapping for crash dump
> kernel memory, the loaded contents won't be preserved around hibernation.
> 
> In this patch, arch_kexec_(un)protect_crashkres() are additionally called
> before/after hibernation so that the relevant region will be mapped again
> and restored just as the other memory regions are.

Reviewed-by: James Morse 

A quick test of this took longer than expected (writing to a slow usb device), I
suspect it is save/restoring the whole crash region (which I don't think is a
problem). If someone turns out to use this combination of features I will look
at improving this, (almost certainly requires core-code changes).


Thanks,

James

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec