On Wed, Nov 25, 2020 at 11:26:59PM +0106, John Ogness wrote:
> Linux 5.10 moved to a new lockless ringbuffer. The new ringbuffer
> is structured completely different to the previous iterations.
> Add support for retrieving the ringbuffer using vmcoreinfo. The
> new ringbuffer is detected based on
On Fri, Oct 09, 2020 at 05:39:18PM +0200, Ahelenia Ziemiańska wrote:
> This patchset essentially boils down to:
> (a) disabling -mcmodel=large, and
> (b) allowing ELFCLASS32 in x86_64.
>
> I've also updated the autotools scripts so they detect x32 correctly
> and fixed some warnings.
Thanks,
On Fri, Oct 23, 2020 at 05:41:03PM +0200, Ahelenia Ziemiańska wrote:
> On Fri, Oct 23, 2020 at 04:33:07PM +0200, Simon Horman wrote:
> > On Fri, Oct 09, 2020 at 05:39:42PM +0200, Ahelenia Ziemiańska wrote:
> > > Signed-off-by: Ahelenia Ziemiańska
> > &
On Fri, Oct 09, 2020 at 05:39:42PM +0200, Ahelenia Ziemiańska wrote:
> Signed-off-by: Ahelenia Ziemiańska
> ---
> configure.ac | 8
> purgatory/arch/x86_64/Makefile | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index
On Fri, Oct 16, 2020 at 01:40:57PM +0200, Matthias Brugger wrote:
> Hi,
>
> On 02/10/2020 20:34, Bhupesh Sharma wrote:
> > Hello Matthias,
> >
> > Thanks for the updated revision.
> >
> > On Fri, Oct 2, 2020 at 7:13 PM wrote:
> > >
> > > From: Matthias Brugger
> > >
> > > Add option to
firmware_memmap.c:152:2: note: ‘snprintf’ output between 6 and 4101
> bytes into a destination of size 4096
> snprintf(filename, PATH_MAX, "%s/%s", entry, "type");
> ^~~~
>
> Since the simplest metho
On Wed, Sep 23, 2020 at 12:48:02PM +0200, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> Add option to allow purgatory printing on arm64 hardware
> by passing the console name which should be used.
> Based on a patch by Geoff Levand.
>
> Cc: Geoff Levand
> Signed-off-by: Matthias
On Tue, Sep 22, 2020 at 02:32:44PM +0530, Bhupesh Sharma wrote:
> The vmcore-dmesg utility has been in usage for several years,
> and is pretty stable now.
>
> So its useful now to modify its man page to indicate the same.
> Also fix some minor formatting issues.
>
> Cc: Sim
On Sat, Sep 12, 2020 at 09:39:49AM +0800, Youling Tang wrote:
> Add some missing free() calls.
>
> Signed-off-by: Youling Tang
Thanks, applied.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Thu, Sep 17, 2020 at 12:14:02AM +0530, Bhupesh SHARMA wrote:
> Hi Youling,
>
> On Sat, Sep 12, 2020 at 7:10 AM Youling Tang wrote:
> >
> > Where Y specifies how much memory to reserve for the dump-capture kernel
> > and X specifies the beginning of this reserved memory. So Y should be
> >
Hi Bhupesh,
thanks for your patch.
...
> +static int get_vabits_actual_from_id_aa64mmfr2_el1(void)
> +{
> + int l_vabits_actual;
> + unsigned long val;
> +
> + /* Check if ID_AA64MMFR2_EL1 CPU-ID register indicates
> + * ARMv8.2/LVA support:
> + * VARange, bits [19:16]
> +
On Sat, Sep 12, 2020 at 09:32:24AM +0800, Youling Tang wrote:
> "mem=" indicating the memory region the new kernel can use to boot into.
> And passed to the dump-capture kernel by kernel commandline parameter
> "mem=". But in the dump-capture kernel, we don’t need to use this parameter
> now, so
On Wed, Sep 02, 2020 at 05:48:00PM +0200, Geert Uytterhoeven wrote:
> On Wed, Sep 2, 2020 at 5:41 PM Geert Uytterhoeven
> wrote:
> > Pass the following properties to the crash dump kernel, to provide a
> > modern DT interface between kexec and the crash dump kernel:
> >
> > - linux,elfcorehdr:
On Wed, Aug 26, 2020 at 09:53:34AM -0600, Khalid Aziz wrote:
> On 8/25/20 6:51 PM, Youling Tang wrote:
> > Add missing close() call.
> >
> > Signed-off-by: Youling Tang
> > ---
> > kexec/kexec.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kexec/kexec.c b/kexec/kexec.c
> >
On Tue, Aug 25, 2020 at 08:29:57AM -0600, Khalid Aziz wrote:
> New email address for Khalid Aziz.
>
> Signed-off-by: Khalid Aziz
Thanks Khalid,
applied.
___
kexec mailing list
kexec@lists.infradead.org
On Tue, Aug 25, 2020 at 04:43:23PM +0800, Youling Tang wrote:
> Add free() call when handling some error returns.
>
> Signed-off-by: Youling Tang
Is there a value in cleaning up like this immediately before exiting?
___
kexec mailing list
On Thu, Aug 13, 2020 at 01:31:52PM +0800, Youling Tang wrote:
> Fix the following warnings:
>
> kexec/arch/mips/kexec-elf-mips.c:161:41: warning: passing argument 3 of
> ‘dtb_set_initrd’ makes integer from pointer without a cast
> dtb_set_initrd(_buf, _length, initrd_buf, initrd_buf +
:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Al
On Tue, Jun 02, 2020 at 12:40:34PM +0200, Łukasz Stelmach wrote:
> Increase the size of the zImage after seeking for the tag to avoid
> reading past the end of the supplied buffer should there be not tag
> in the zImage.
>
> Fixes: f57f0bf8975d24fe1e7c4936fdfb5c3b123ab75f
> Signed-off-by: Łukasz
On Tue, Jun 02, 2020 at 10:01:59AM +0530, Hari Bathini wrote:
> Fixes: 28d4ab532808 ("Add generic debug option")
> Cc: Cong Wang
> Signed-off-by: Hari Bathini
Thanks, applied.
> ---
> kexec/kexec.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kexec/kexec.c b/kexec/kexec.c
>
On Thu, May 21, 2020 at 04:32:57PM +0800, Chen Zhou wrote:
> Currently, there is only one crash kernel region on arm64, we add
> another region "crash kernel low" used for crash dump kernel devices.
>
> To do this, we add DT property "linux,low-memory-range" to crash
> dump kernel's dtb to pass
On Wed, Apr 22, 2020 at 09:45:04PM +0200, Łukasz Stelmach wrote:
> Redefine OPT_APPEND to avoid clash with OPT_KEXEC_SYSCALL_AUTO.
> Redefine OPT_RAMDISK to avoid such problems in the future
>
> Minor cleanup in HPPA too.
>
> Signed-off-by: Łukasz Stelmach
> ---
> Sven,
>
> I removed some arch
On Mon, Apr 20, 2020 at 04:33:11PM +0200, Lukasz Stelmach wrote:
> > On Wed, Apr 15, 2020 at 12:58:45PM +0200, Łukasz Stelmach wrote:
> >> Redefine OPT_APPEND to avoid clash with OPT_KEXEC_SYSCALL_AUTO.
> >> Redefine OPT_RAMDISK to avoid such problems in the future
> >>
> >> Signed-off-by: Łukasz
On Wed, Apr 15, 2020 at 12:58:45PM +0200, Łukasz Stelmach wrote:
> Redefine OPT_APPEND to avoid clash with OPT_KEXEC_SYSCALL_AUTO.
> Redefine OPT_RAMDISK to avoid such problems in the future
>
> Signed-off-by: Łukasz Stelmach
Hi Łukasz,
I am slightly concerned that this will break things for
On Fri, Apr 03, 2020 at 01:45:04PM +0200, Petr Tesarik wrote:
> On Wed, 1 Apr 2020 14:40:09 +0200
> Simon Horman wrote:
>
> > On Fri, Mar 13, 2020 at 03:09:27PM +0100, Petr Tesarik wrote:
> > > From: Petr Tesarik
> > >
> > > As noticed by Raymun
On Fri, Apr 03, 2020 at 01:19:16PM +0200, Petr Tesarik wrote:
> The command line is duplicated on s390 if kexec_file_load(2) is not
> implemented. That's because the corresponding variable is not reset
> to an empty string before re-parsing the kexec command line.
>
> Fixes: 9cf721279f6c ("Reset
On Wed, Apr 01, 2020 at 06:57:15PM +0200, Varad Gautam wrote:
> And convert all callers of xc_kexec_get_range to use this. Allows reusing
> sanity checks for other KEXEC_RANGEs
>
> v2: define xen_get_kexec_range outside of HAVE_LIBXENCTRL
Thanks, series applied.
On Wed, Jan 29, 2020 at 01:38:19PM +0800, Kairui Song wrote:
> When building kexec-tools for Fedora 32, following error is observed:
>
> /usr/bin/ld: kexec/arch/x86_64/kexec-bzImage64.o:(.bss+0x0): multiple
> definition of `bzImage_support_efi_boot';
> kexec/arch/i386/kexec-bzImage.o:(.bss+0x0):
On Fri, Feb 07, 2020 at 10:00:32AM +0100, Varad Gautam wrote:
> Xen is intended to expose a KEXEC_TYPE_LIVE_UPDATE operation which
> implies a stateful-kexec into a new xen image - or a "live update".
> Make kexec-tools capable of triggering a live update.
>
> For a multiboot2 xen image, this
On Tue, Mar 03, 2020 at 03:56:49AM +, Leonidas S. Barbosa wrote:
> Hi,
>
> Looking in the kexec-tools code I found these conditions that
> seems will never be met. Not sure if that was intentional for explicitity,
> if it was the case, please disconsider this patch.
>
>
>
>
> xmalloc and
On Mon, Feb 24, 2020 at 12:17:50PM +0530, Bhupesh Sharma wrote:
> Hi Lianbo,
>
> On Mon, Feb 24, 2020 at 12:07 PM Lianbo Jiang wrote:
> >
> > When loading kernel and initramfs for kexec, kexec-tools could get the
> > e820 reserved region from "/proc/iomem" in order to rebuild the e820
> > ranges
On Fri, Mar 13, 2020 at 03:09:27PM +0100, Petr Tesarik wrote:
> From: Petr Tesarik
>
> As noticed by Raymund Will, kexec -la does not work on kernels without
> the kexec_file_load(2) syscall, revealing some shortcomings in the
> automatic syscall selection.
>
> Petr Tesarik (2):
>
On Wed, Mar 04, 2020 at 08:27:11PM -0300, Thadeu Lima de Souza Cascardo wrote:
> When reading the device-tree exported crashkernel-base and
> crashkernel-size, their values should be converted from big-endian to the
> CPU byte order.
>
> These is the output of running kexec --print-ckr-size on a
On Mon, Nov 18, 2019 at 12:52:15PM +1300, Chris Packham wrote:
> This addresses the following compilation issues when building for i386.
>
> kexec/arch/i386/kexec-x86.c:39:22: error: 'multiboot2_x86_probe' undeclared
> here (not in a function); did you mean 'multiboot_x86_probe'?
>{
On Fri, Nov 08, 2019 at 12:08:54PM -0600, Brandon Maier wrote:
> We use a large initrd that maxes out our available RAM when loading
> kexec. The problem can be mitigated by using slurp_file_mmap(), which
> avoids creating a copy of the initrd. The initrd does not use free,
> realloc, etc, so it
On Mon, Dec 23, 2019 at 12:25:00PM +0530, Bhupesh Sharma wrote:
> Thanks for the patches Masa,
>
> On Wed, Dec 18, 2019 at 10:13 PM Masayoshi Mizuma
> wrote:
> >
> > In recent arm64 kernels, /proc/iomem has an extended file format like:
> >
> > 4000-5871 : System RAM
> >
Hi Linbo,
thanks for your patch.
On Wed, Oct 23, 2019 at 10:19:11PM +0800, Lianbo Jiang wrote:
> Kdump kernel will reuse the first 640k region because the real mode
> trampoline has to work in this area. When the vmcore is dumped, the
> old memory in this area may be accessed, therefore, kernel
On Fri, Oct 04, 2019 at 01:01:09PM +0200, Helge Deller wrote:
> When compiling kexec-tools on a 32-bit platform, assigning an
> (unsigned long long) value to an (unsigned long) variable creates
> this warning:
>
> elf_info.c: In function 'read_phys_offset_elf_kcore':
> elf_info.c:805:14: warning:
On Fri, Oct 04, 2019 at 11:51:05AM +0200, Helge Deller wrote:
> On 04.10.19 11:37, Simon Horman wrote:
> > On Thu, Oct 03, 2019 at 10:52:37AM +0200, Helge Deller wrote:
> > > On 03.10.19 10:14, Simon Horman wrote:
> > > > On Tue, Oct 01, 2019 at 05:14:16PM +0200, Helg
On Thu, Oct 03, 2019 at 10:52:37AM +0200, Helge Deller wrote:
> On 03.10.19 10:14, Simon Horman wrote:
> > On Tue, Oct 01, 2019 at 05:14:16PM +0200, Helge Deller wrote:
> > > When compiling kexec-tools on a 32-bit platform, assigning an
> > > (unsigned long long)
On Tue, Oct 01, 2019 at 05:06:05PM +0200, Helge Deller wrote:
> Fix a possible out-of-bounds access in function ifdown():
>
> ifdown.c: In function 'ifdown':
> ifdown.c:56:4: warning: 'strncpy' specified bound 16 equals destination size
> [-Wstringop-truncation]
>56 |
On Tue, Oct 01, 2019 at 05:14:16PM +0200, Helge Deller wrote:
> When compiling kexec-tools on a 32-bit platform, assigning an
> (unsigned long long) value to an (unsigned long) variable creates
> this warning:
>
> elf_info.c: In function 'read_phys_offset_elf_kcore':
> elf_info.c:805:14: warning:
On Sat, Sep 21, 2019 at 08:36:51PM +0200, Helge Deller wrote:
> On 19.09.19 20:26, Sven Schnelle wrote:
> > This patch adds support for the parisc Architecture. kexec support
> > for parisc is included with linux-5.4.
> >
> > Signed-off-by: Sven Schnelle
>
> Tested-by: Helge Deller
Thanks,
On Mon, Sep 16, 2019 at 12:47:00PM +0200, Donald Buczek wrote:
> On 9/16/19 9:23 AM, Simon Horman wrote:
> > On Mon, Sep 09, 2019 at 10:33:11AM +0530, Bhupesh Sharma wrote:
> > > Sorry Guys,
> > >
> > > On Tue, Sep 3, 2019 at 11:36 PM Donald Buczek
>
On Mon, Sep 09, 2019 at 10:33:11AM +0530, Bhupesh Sharma wrote:
> Sorry Guys,
>
> On Tue, Sep 3, 2019 at 11:36 PM Donald Buczek wrote:
> >
> > Dear Simon,
> >
> > On 03.09.19 16:41, Simon Horman wrote:
> > > On Fri, Aug 30, 2019 at 11:12:58AM +0200
On Mon, Sep 16, 2019 at 10:49:05AM +0800, quanyan...@gmail.com wrote:
> From: Quanyang Wang
>
> In the kernel upstream commit 4ab65ba7a5cb
> ("ARM: add kexec_file_load system call number"),
> __NR_kexec_file_load for arm has been defined to be 401.
> This results that even if kexec_file_load
On Tue, Sep 10, 2019 at 03:51:48PM +0530, Bhupesh Sharma wrote:
> This patchset fixes two kexec-tools issues:
> - Fixes a shifting error reported by cppcheck inside
>'vmcore-dmesg/vmcore-dmesg.c'.
> - Fixes a compilation warning in 'i386/kexec-mb2-x86.c'.
Thanks, applied.
On Wed, Sep 04, 2019 at 09:29:20PM +0800, lijiang wrote:
> 在 2019年09月03日 22:37, Simon Horman 写道:
> > On Wed, Aug 28, 2019 at 05:18:58PM +0800, lijiang wrote:
> >> Hi, Simon and other reviewers, any comment about v2?
> >
> > Hi,
> >
> > sorry fo
On Fri, Aug 30, 2019 at 11:12:58AM +0200, Donald Buczek wrote:
> Linux kernel commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR
> region on 5-level paging") changed the base of the direct mapping
> from 0x8800 to 0x8880. This was merged
> into v4.20-rc2.
>
> Update
On Wed, Aug 28, 2019 at 05:18:58PM +0800, lijiang wrote:
> Hi, Simon and other reviewers, any comment about v2?
Hi,
sorry for the extended delay.
I will look over this.
___
kexec mailing list
kexec@lists.infradead.org
On Thu, Aug 15, 2019 at 11:37:56AM +0800, Lianbo Jiang wrote:
> With some corrupted vmcore files, the vmcore-dmesg.txt file may grow
> forever till the kdump disk becomes full, and also probably causes
> the disk error messages as follow:
> ...
> sd 0:0:0:0: [sda] tag#6 FAILED Result:
Hi Lianbo,
I like where this patch is going but I would like to request a few changes.
Please see comments inline.
On Thu, Aug 15, 2019 at 11:37:55AM +0800, Lianbo Jiang wrote:
> Some code related to vmcore-dmesg.c is put into the util_lib, which
> is not very reasonable, so lets move it back
Hi all,
I am happy to announce the release of kexec-tools 2.0.20.
This is a feature release coinciding with the release of v5.2
of the Linux Kernel.
This release can be downloaded from kernel.org:
http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.20.tar.xz
Hi all,
I am happy to announce the release of kexec-tools 2.0.20-rc2.
This is an incremental feature pre-release.
I had planed to release v2.0.20 at this time but have, instead,
decided to add Bhupesh Sharma's support for zlib compressed kernel
images for ARM64 and release 2.0.20-rc2.
So long
On Mon, Jul 15, 2019 at 11:32:52AM +0530, Bhupesh Sharma wrote:
> Changes since v1:
>
> (v1 can be viewed here:
> http://lists.infradead.org/pipermail/kexec/2019-July/023288.html)
> - Fixed the potential file descriptor leakage code legs pointed out by
>Simon.
> - Ran
On Thu, Jul 11, 2019 at 01:24:29AM +0530, Bhupesh Sharma wrote:
> Currently the kexec_file_load() support for arm64 doesn't allow
> handling zlib compressed (i.e. Image.gz) image.
>
> Since most distributions use 'make zinstall' rule inside
> 'arch/arm64/boot/Makefile' to install the arm64
>
On Thu, Jul 11, 2019 at 01:24:28AM +0530, Bhupesh Sharma wrote:
> This patch adds 'is_zlib_file()' helper function which can be
> used to quickly determine with the passed kernel image is a zlib
> compressed kernel image.
>
> This is specifically useful for arm64 zImage (or Image.gz) support,
>
Hi all,
I am happy to announce the release of kexec-tools 2.0.20-rc1.
This is an incremental feature pre-release.
So long as no serious problems arise I intend to release kexec-tools 2.0.20
in a weeks time. Testing of 2.0.20-rc1 would be greatly appreciated.
I do not have any outstanding
Fixes: 22a2ed55132e ("x86: Support multiboot2 images")
Signed-off-by: Simon Horman
---
include/Makefile | 1 +
kexec/arch/i386/Makefile | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
I intend to apply this patch for inclusion in v2.0.20-rc1
the release of
On Wed, Jul 03, 2019 at 10:04:32AM +0200, Simon Horman wrote:
> xenctrl.h defines struct e820entry as:
>
> if defined(__i386__) || defined(__x86_64__)
> ...
> #define E820_RAM1
> ...
> struct e820entry {
> uint64_t addr;
ude ordering. Perhaps a better solution in the longer
term would be to rename the local definition of struct e820entry.
Fixes: cedeee0a3007 ("x86: Introduce helpers for getting RSDP address")
Signed-off-by: Simon Horman
---
kexec/arch/i386/kexec-x86-common.c | 2 +-
1 file changed, 1 inserti
On Tue, Jul 02, 2019 at 02:29:56PM +0100, David Woodhouse wrote:
> On Tue, 2019-07-02 at 13:09 +0200, Simon Horman wrote:
> > > diff --git a/include/x86/multiboot2.h b/include/x86/multiboot2.h
> > > new file mode 100644
> > > index 000..5693923
> > >
Hi all,
I am planning to release kexec-tools v2.0.20 in the next two weeks
to roughly coincide with the release of the v5.2 kernel.
I would like to ask interested parties to send any patches they would like
included in v2.0.20 within one week so that I can make an rc release.
For reference the
On Thu, Jun 27, 2019 at 12:12:43PM +0200, Varad Gautam wrote:
> Add a new type `multiboot2-x86` that allows loading multiboot2 [1] images
> within the relocation range specified in the image header. The image is
> always placed at the lowest available address, regardless of the
> preference
On Mon, Jun 10, 2019 at 04:10:30PM +0800, Kairui Song wrote:
> On Fri, May 31, 2019 at 5:27 PM Simon Horman wrote:
> >
> > On Fri, May 24, 2019 at 02:23:17PM +0800, Kairui Song wrote:
> > > This patch sync the behavior of user space kexec and kexec_file_load,
&
On Fri, May 31, 2019 at 05:38:25PM +0800, Kairui Song wrote:
> On Fri, May 31, 2019 at 5:29 PM Simon Horman wrote:
> >
> > On Fri, Nov 23, 2018 at 05:28:01PM +0800, Kairui Song wrote:
> > > Some device (eg. hyperv_fb) will mimic EFI (or VESA) VGA on first boot
> > &
On Thu, Oct 25, 2018 at 02:54:52AM +0530, Bhupesh Sharma wrote:
> Since kernel version 4.19-rc5 (Commit 23c85094fe1895caefdd
> ["proc/kcore: add vmcoreinfo note to /proc/kcore"]), '/proc/kcore'
> contains a new PT_NOTE which carries the VMCOREINFO information.
>
> If the same is available, one
On Fri, Nov 23, 2018 at 05:26:33PM +0800, Kairui Song wrote:
> In a EFI system, the frame buffer address is 64bit, so currently
> if the address is beyound 4G, kexec will set wrong address due to
> truncate.
>
> Linux kernel commit ae2ee627dc87 ('efifb: Add support for 64-bit
> frame buffer
On Fri, Nov 23, 2018 at 05:28:01PM +0800, Kairui Song wrote:
> Some device (eg. hyperv_fb) will mimic EFI (or VESA) VGA on first boot
> up, but after the real driver is loaded, it will switch to new mode
> and no longer compatible with EFI/VESA VGA. Keep setting
> orig_video_isVGA to EFI/VESA VGA
On Wed, Apr 03, 2019 at 10:55:04AM +0800, Chen Zhou wrote:
> When crashkernel is reserved above 4G in memory, kernel should
> reserve some amount of low memory for swiotlb and some DMA buffers.
> So there may be two crash kernel regions, one is below 4G, the other
> is above 4G.
>
> Currently,
On Fri, May 24, 2019 at 02:23:17PM +0800, Kairui Song wrote:
> This patch sync the behavior of user space kexec and kexec_file_load,
> they will both fill the boot_params.acpi_rsdp_addr with a valid RSDP
> value, to make sure second kernel can always get the RSDP consistently.
>
> This will make
On Tue, May 21, 2019 at 09:32:28AM +0200, Varad Gautam wrote:
> Add a new type `multiboot2-x86` that allows loading multiboot2 images
> within the relocation range specified in the image header. The image is
> always placed at the lowest available address, regardless of the
> preference
On Tue, May 21, 2019 at 09:32:26AM +0200, Varad Gautam wrote:
> From: David Woodhouse
>
> Unlike Linux which creates a full identity mapping, Xen only maps those
> segments which are explicitly requested. Therefore, xen_kexec_load()
> silently adds in a segment from zero to 1MiB to ensure that
On Mon, Apr 29, 2019 at 10:21:33AM +0200, Niklas Hambüchen wrote:
> Hi,
>
> please find below two fixes to kexec-tools that improve its operation
> on read-only file systems and initial ramdisks without /etc/mtab,
> as well as making detection of sysfs and debugfs more robust by relying
> on the
On Sun, Apr 28, 2019 at 01:52:12PM +0300, David Woodhouse wrote:
> From: David Woodhouse
>
> Unlike Linux which creates a full identity mapping, Xen only maps those
> segments which are explicitly requested. Therefore, xen_kexec_load()
> silently adds in a segment from zero to 1MiB to ensure
>
> Machines that have slow console baud rate benefit from less output.
>
> Signed-off-by: Pavel Tatashin
Reviewed-by: Simon Horman
> ---
> kernel/kexec_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/kexec_core.c b/kerne
On Tue, Apr 09, 2019 at 11:59:21AM +0800, Bhupesh Sharma wrote:
> Hi Simon, Chen,
>
> On Mon, Apr 8, 2019 at 5:36 PM Simon Horman wrote:
> >
> > On Mon, Apr 08, 2019 at 05:22:39PM +0800, Chen Zhou wrote:
> > > When crashkernel is reserved above 4G in memory, ke
On Mon, Apr 08, 2019 at 05:22:39PM +0800, Chen Zhou wrote:
> When crashkernel is reserved above 4G in memory, kernel should
> reserve some amount of low memory for swiotlb and some DMA buffers.
> So there may be two crash kernel regions, one is below 4G, the other
> is above 4G.
>
> Currently,
On Wed, Mar 06, 2019 at 05:34:23PM +0800, Dave Young wrote:
> On 03/05/19 at 07:34pm, Kairui Song wrote:
> > After commit 060eee58 "x86: use old screen_info if needed", kexec-tools
> > will force use old screen_info and vga type if failed to determine
> > current vga type. But it is not always a
Hi all,
I am happy to announce the release of kexec-tools 2.0.19.
This is a feature release coinciding with the release of v5.0
of the Linux Kernel.
This release can be downloaded from kernel.org:
http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.19.tar.xz
Hi all,
I am happy to announce the release of kexec-tools 2.0.19-rc1.
This is an incremental feature pre-release.
So long as no serious problems arise I intend to release kexec-tools 2.0.19
in a weeks time. Testing of 2.0.19-rc1 would be greatly appreciated.
I do not have any outstanding
Hi all,
I am planning to release kexec-tools v2.0.19 in the next two weeks
to roughly coincide with the release of the v5.0 kernel.
I would like to ask interested parties to send any patches they would like
included in v2.0.18 within one week so that I can make an rc release.
For reference the
On Fri, Feb 01, 2019 at 03:50:28PM +, Jean-Philippe Brucker wrote:
> When copying the DTB from the current kernel, if the user didn't pass an
> initrd on the command-line, make sure that the new DTB doesn't contain
> initrd properties with stale addresses. Otherwise the next kernel will
> try
On Mon, Jan 28, 2019 at 11:58:44AM +0100, Simon Horman wrote:
> On Mon, Jan 28, 2019 at 06:50:40PM +0800, Kairui Song wrote:
> > There has been a lot of workarounds for purgatory disabling many
> > specified CFLAGS that will break purgatory. It will be better to not
> >
On Mon, Jan 28, 2019 at 06:50:45PM +0800, Kairui Song wrote:
> This make it easier for passing extra cflags, for example hardening
> flags could be passed in with enviroment variable.
>
> Signed-off-by: Kairui Song
Thanks, I like this a lot.
I would like to wake a little to see if there is
On Mon, Jan 28, 2019 at 06:50:40PM +0800, Kairui Song wrote:
> There has been a lot of workarounds for purgatory disabling many
> specified CFLAGS that will break purgatory. It will be better to not
> let the CFLAGS used to compile purgatory honor the CFLAGS from
> environment variables. So we
On Tue, Jan 22, 2019 at 10:25:42AM +0800, Kairui Song wrote:
> On Wed, Dec 5, 2018 at 5:22 PM Kairui Song wrote:
> >
> > In a EFI system, the frame buffer address is 64bit, so currently
> > if the address is beyound 4G, kexec will set wrong address due to
> > truncate.
> >
> > Linux kernel commit
On Mon, Jan 21, 2019 at 08:07:32PM +0100, cinap_len...@felloff.net wrote:
> i'm unsubscribing from this list as i did not get any
> response about these patches from anyone but horms so far
> and that was a long time ago.
>
> http://lists.infradead.org/pipermail/kexec/2018-August/021357.html
>
On Tue, Jan 15, 2019 at 04:41:19PM +0100, Daniel Kiper wrote:
> On Tue, Jan 15, 2019 at 03:15:28PM +0100, Simon Horman wrote:
> > On Mon, Jan 14, 2019 at 01:52:07PM -0600, Eric DeVolder wrote:
> > > These changes work in conjunction with the signature
> > > verification
On Tue, Jan 15, 2019 at 12:26:04AM +0530, Bhupesh Sharma wrote:
> Hi Akashi,
>
> Thanks for the patch.
>
> On 01/11/2019 03:27 PM, AKASHI Takahiro wrote:
> > # My kexec_file patch for arm64 is now merged in v5.0-rc1.
> >
> > With this patch, kexec_file_load() system call is supported.
> >
> >
On Mon, Jan 14, 2019 at 01:52:07PM -0600, Eric DeVolder wrote:
> These changes work in conjunction with the signature
> verification support for Xen I published recently.
>
> Prior to this change, kexec supported the following
> three modes of operation:
>
> kexec_load:
> - unverified loading of
On Mon, Jan 07, 2019 at 04:22:49PM +0530, Bhupesh Sharma wrote:
> Hi Simon,
>
> On Thu, Dec 20, 2018 at 4:52 PM Bhupesh Sharma wrote:
> >
> > Changes from v1:
> > ---
> > - Added the support for older kernels, where we determine the
> >PHYS_OFFSET value from PT_LOAD segments
> > >
> > > > A couple of these issues were reported for 'kexec load' use case by
> > > > Vicenç and I found the other two while experiment with 'kdump' use
> > > > cases.
> > > >
> > > > I have tested the patchset on my qualcomm-amberwing
On Thu, Nov 15, 2018 at 06:10:36AM -0800, Simon Horman wrote:
> On Mon, Nov 12, 2018 at 11:24:07AM +0900, AKASHI Takahiro wrote:
> > On Mon, Nov 12, 2018 at 02:00:16AM +0530, Bhupesh Sharma wrote:
> > > Vicenç reported (via [1]) that currently executing kexec with
> > >
On Mon, Nov 12, 2018 at 11:24:07AM +0900, AKASHI Takahiro wrote:
> On Mon, Nov 12, 2018 at 02:00:16AM +0530, Bhupesh Sharma wrote:
> > Vicenç reported (via [1]) that currently executing kexec with
> > '--dtb' option and passing a .dtb which doesn't have a '/chosen' node
> > leads to the following
Hi all,
I am happy to announce the release of kexec-tools 2.0.18.
This is a feature release coinciding with the release of v4.19 of the Linux
Kernel.
This release can be downloaded from kernel.org:
http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.18.tar.xz
On Tue, Oct 23, 2018 at 01:50:20AM +0530, Bhupesh Sharma wrote:
> For calculating the random 'kaslr-seed' value to be passed to the
> secondary kernel (kexec or kdump), we invoke the 'getrandom' syscall
> inside 'setup_2nd_dtb()' function.
>
> Normally on most arm64 systems this syscall doesn't
On Mon, Oct 22, 2018 at 03:54:16PM +0800, Pingfan Liu wrote:
> If the err_out label is reached, address of a stack variable is passed to
> free(). Fix it.
>
> Signed-off-by: Pingfan Liu
Thanks, applied.
___
kexec mailing list
Hi all,
I am happy to announce the release of kexec-tools 2.0.18-rc1.
This is an incremental feature pre-release.
So long as no serious problems arise I intend to release kexec-tools 2.0.18
in a weeks time. Testing of 2.0.18-rc1 would be greatly appreciated.
I do not have any outstanding
On Fri, Sep 07, 2018 at 09:05:50AM +0800, Dave Young wrote:
> On 09/06/18 at 01:56pm, Lianbo Jiang wrote:
> > When kexec-tools load the kernel and initramfs for kdump, kexec-tools will
> > read /proc/iomem and recreate the e820 ranges for kdump kernel. But it fails
> > to parse the e820 reserved
201 - 300 of 1232 matches
Mail list logo
