the input of /sys/kernel/kexec_crash_size, both reserved ranges
might be released if the new size is smaller than current size. The order
of release is (crashk_res -> crashk_low_res). Only if the new size defined
by the user is smaller than the size of low memory range, continue to
rele
.
>
> If getting the input of /sys/kernel/kexec_crash_size, both reserved ranges
> might be released if the new size is smaller than current size. The order
> of release is (crashk_res -> crashk_low_res). Only if the new size defined
> by the user is smaller than the size of low memo
to release the reserved
low memory range after completely releasing the high memory range.
Signed-off-by: Kaihao Bai
---
kernel/kexec_core.c | 75 +++--
1 file changed, 56 insertions(+), 19 deletions(-)
diff --git a/kernel/kexec_core.c b/kernel
be released if the new size is smaller than current size. The order
of release is (crashk_res -> crashk_low_res). Only if the new size defined
by the user is smaller than the size of low memory range, continue to
release the reserved low memory range after completely releasing the high
memory ra
4231fd27 ("x86/kdump: Always reserve the low 1M when the
> >> crashkernel
> >> > > option is specified"), we changed to lock the whole low 1M to avoid
> >> > > writting any kernel data into, like this we can skip this area when
> >> > > dum
dumping vmcore.
> >
> > Above is why we try to memblock reserve the whole low 1M. We don't want
> > to use it, just don't want anyone to use it in 1st kernel.
> >
> > >
> > > I propose that the right solution is to give low-memory-reserving code
> &g
nel data into, like this we can skip this area when
> dumping vmcore.
>
> Above is why we try to memblock reserve the whole low 1M. We don't want
> to use it, just don't want anyone to use it in 1st kernel.
>
> >
> > I propose that the right solution is to give low-memor
y kernel data into, like this we can skip this area when
> dumping vmcore.
>
> Above is why we try to memblock reserve the whole low 1M. We don't want
> to use it, just don't want anyone to use it in 1st kernel.
>
>>
>> I propose that the right solution is to give low-mem
that the right solution is to give low-memory-reserving code paths
> two chances to do what they need: once at the very beginning and once after
> EFI boot services are freed.
>
> Alternatively, just reserve *all* otherwise unused sub 1M memory up front,
> then release it right after re
serving code paths
two chances to do what they need: once at the very beginning and once after EFI
boot services are freed.
Alternatively, just reserve *all* otherwise unused sub 1M memory up front, then
release it right after releasing boot services, and then invoke the special
cases
On 04/09/21 at 07:59pm, H. Peter Anvin wrote:
> Why don't we do this unconditionally? At the very best we gain half a
> megabyte of memory (except the trampoline, which has to live there, but it is
> only a few kilobytes.)
This is a great suggestion, thanks. I think we can fix it in this way to
der 1M? Assume efi boot code/data
Or patch [2]
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 5ecd69a48393..ceec5af0dfab 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1058,6 +1058,7 @@ void __init setup_arch(char **cmdline_p)
sev_setup_arch();
re
ervices() after reserve_real_mode() to fix this bug?
Or move reserve_real_mode() before efi_reserve_boot_services() since
those real mode regions are all under 1M? Assume efi boot code/data
won't rely on low 1M area any more at this moment.
Thanks
Baoquan
>
> Do not release sub-1MB memory reg
14b/0x23b
[8.815793] __memblock_free_late: [0x0001-0x00013fff]
efi_free_boot_services+0x14b/0x23b
Do not release sub-1MB memory regions even though they are reserved by
EFI boot services, so that always reserve all sub-1MB memory regions when
the crashkernel option is
Functions reserve and release memory from CMA area(s).
Signed-off-by: Ronit Halder <ronit@gmail.com>
---
include/linux/kexec.h | 11 ++-
kernel/kexec_core.c | 83 +++
2 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/i
>Hello,
>
>makedumpfile-1.6.0 was scheduled in May, but still there is a
>unresolved issue so the release will be delayed.
>
>The issue is that the multi-thread feature doesn't work correctly
>on ia64, the generated dump is indefinite.
>The dumps below are generated b
Hello,
makedumpfile-1.6.0 was scheduled in May, but still there is a
unresolved issue so the release will be delayed.
The issue is that the multi-thread feature doesn't work correctly
on ia64, the generated dump is indefinite.
The dumps below are generated by the same option (-cd31 + --num
Hello,
I see in the development branch for makedumpfile that the upcoming release plans
to support kernels for up to 4.2
Are there any plans to go any higher than that before the next release comes out
? This way I can prepare a bit as our next release will come with a 4.4 kernel
Hello Louis,
>Hello,
>
>I see in the development branch for makedumpfile that the upcoming release
>plans
>to support kernels for up to 4.2
>
>Are there any plans to go any higher than that before the next release comes
>out
>? This way I can prepare a bit as
On 09/02/15 at 10:00am, Simon Horman wrote:
> On Thu, Aug 27, 2015 at 01:19:30PM +0530, Pratyush Anand wrote:
> > On 27/08/2015:02:29:57 PM, Dave Young wrote:
> > > Pratyush, rethink about it, it is still confused. Considering below case:
> > >
> > > git clone kexec-tools;
> > > bootstrap and
On Wed, Sep 02, 2015 at 09:24:12AM +0800, Dave Young wrote:
> kexec --version reports like below:
> kexec-tools 2.0.7 released 05 February 2015
>
> The date string is generated when one run bootstrap script, thus
> it is more like a build date instead of release date.
> Even for
On 08/25/15 at 04:12pm, Pratyush Anand wrote:
On 25/08/2015:04:47:59 PM, Dave Young wrote:
On 08/24/15 at 03:59pm, Pratyush Anand wrote:
May be we can take same approach what kernel build takes. Kernel build
does not
add build/release string. It just add date and time like Mon Aug
On 08/24/15 at 03:59pm, Pratyush Anand wrote:
On 24/08/2015:05:10:05 PM, Dave Young wrote:
kexec --version reports like below:
kexec-tools 2.0.7 released 05 February 2015
The date string is generated when one run bootstrap script, thus
it is more like a build date instead of release
On 25/08/2015:04:47:59 PM, Dave Young wrote:
On 08/24/15 at 03:59pm, Pratyush Anand wrote:
May be we can take same approach what kernel build takes. Kernel build does
not
add build/release string. It just add date and time like Mon Aug 10
23:38:23 UTC 2015.
$ uname -a
Linux
, Scott Wood wrote:
booted_from_exec is similar to __run_at_load, except that it is set
for
regular kexec as well as kdump.
The flag is needed because the SMP release mechanism for FSL book3e is
different from when booting with normal hardware. In theory we could
On Tue, 2015-08-25 at 18:40 -0500, Scott Wood wrote:
On Tue, 2015-08-25 at 11:57 +1000, Michael Ellerman wrote:
I guess it's arguable whether that's more or less horrible than adding an
#ifdef'ed booted_from_kexec check, but I think I'd prefer the
spinning_secondaries solution.
We'd
On 24/08/2015:05:10:05 PM, Dave Young wrote:
kexec --version reports like below:
kexec-tools 2.0.7 released 05 February 2015
The date string is generated when one run bootstrap script, thus
it is more like a build date instead of release date.
Even for distribution like Fedora it will make
kexec --version reports like below:
kexec-tools 2.0.7 released 05 February 2015
The date string is generated when one run bootstrap script, thus
it is more like a build date instead of release date.
Even for distribution like Fedora it will make more sense if it can
report something like kexec
.
The flag is needed because the SMP release mechanism for FSL book3e is
different from when booting with normal hardware. In theory we could
simulate the normal spin table mechanism, but not at the addresses
U-Boot put in the device tree -- so there'd need to be even more
communication
Hi Scott,
Sorry for the delay. So I'm back to square one on this patch.
On Sat, 2015-07-18 at 15:08 -0500, Scott Wood wrote:
booted_from_exec is similar to __run_at_load, except that it is set for
regular kexec as well as kdump.
The flag is needed because the SMP release mechanism for FSL
it's low level guts.
I see you asked for them to be removed on the original patch but all the other
vars in there are named that way.
regular kexec as well as kdump.
The flag is needed because the SMP release mechanism for FSL book3e is
different from when booting with normal hardware
. fsl-book3e relies on this to
+* know how to release secondary cpus.
+*/
+ .long 0x6e6b7863
Couldn't we say that nkxc (whatever that stands for)
It stands for no kexec, which is true if that value is not overwritten.
means unknown, and
have kexec-tools write yes to indicate
booted_from_exec is similar to __run_at_load, except that it is set for
regular kexec as well as kdump.
The flag is needed because the SMP release mechanism for FSL book3e is
different from when booting with normal hardware. In theory we could
simulate the normal spin table mechanism
.
--
bye,
pabs
http://bonedaddy.net/pabs3/
From c3437b10008dba491843aa46aa54b860b5e69785 Mon Sep 17 00:00:00 2001
From: Paul Wise pa...@bonedaddy.net
Date: Thu, 24 Apr 2014 12:20:56 +0800
Subject: [PATCH] Do not distribute generated files in the release tarball
Generated files should always be built
While I'm not opposed to this off-hand I am curious to know what the
motivation for it is.
On Thu, Apr 24, 2014 at 12:20:56PM +0800, Paul Wise wrote:
---
kexec/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/Makefile b/kexec/Makefile
index
On Thu, Apr 24, 2014 at 12:46:08PM +0800, Paul Wise wrote:
On Thu, 2014-04-24 at 13:32 +0900, Simon Horman wrote:
While I'm not opposed to this off-hand I am curious to know what the
motivation for it is.
Within Debian there has been a renewed focus on finding and removing
sourceless
On Mon, Feb 03, 2014 at 07:49:11PM -0800, Luis R. Rodriguez wrote:
Hey folks, I see recent discussions about desire for a new recent
release of kexec, one of such reasons is kexec support on EFI systems.
SUSE is also interested in this, and it'd be great if we can all synch
up on supporting
On 02/04/2014 08:19 AM, Vivek Goyal wrote:
W.r.t syncing on supporting same kexec-tools release, I am not sure how
will that work. Every distribution will have its own release schedule.
I'd not seen Luis' e-mail. Agree with above, we'll all have our own differing
release schedules.
tony
Hey folks, I see recent discussions about desire for a new recent
release of kexec, one of such reasons is kexec support on EFI systems.
SUSE is also interested in this, and it'd be great if we can all synch
up on supporting the same recent release.
Thanks!
Luis
Hello,
On Tue, 27 Nov 2012 19:37:27 +0900
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello,
If there is no problem, I will release v1.5.1 GA on Nov 28.
I did regression test for v1.5.1 in the last weekend and found some bugs.
So the release date will be delayed by few
Hello,
On Tue, 27 Nov 2012 21:32:34 +0900 (JST)
HATAYAMA Daisuke d.hatay...@gmail.com wrote:
From: Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp
Subject: [ANNOUNCE] makedumpfile: Postpone the release of 1.5.1
Date: Tue, 27 Nov 2012 19:37:27 +0900
Hello,
If there is no problem, I
Hello,
If there is no problem, I will release v1.5.1 GA on Nov 28.
I did regression test for v1.5.1 in the last weekend and found some bugs.
So the release date will be delayed by few weeks, sorry.
However, I don't think there are big issues for almost all users, because:
- #1 doesn't
From: Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp
Subject: [ANNOUNCE] makedumpfile: Postpone the release of 1.5.1
Date: Tue, 27 Nov 2012 19:37:27 +0900
Hello,
If there is no problem, I will release v1.5.1 GA on Nov 28.
I did regression test for v1.5.1 in the last weekend and found
Hello, Kumagai-san,
I saw you released 1.4.2:
commit 7ccf93312266eb4b2e4f9ac701875eb926a861f3
Author: Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp
Date: Mon Jan 23 10:44:07 2012 +0900
[v1.4.2] Update version
This patch updates makedumpfile to version 1.4.2.
Signed-off-by:
On 01/25/2012 06:50 PM, Cong Wang wrote:
Hello, Kumagai-san,
I saw you released 1.4.2:
By the way, the latest kernel supported by makedumpfile 1.4.2 is still
2.6.36.
makedumpfile.h
383:#define LATEST_VERSION KERNEL_VERSION(2, 6, 36)/* linux-2.6.36
*/
The latest stable kernel
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
This patch introduces an sysfs interface '/sys/kernel/fadump_release_mem' to
invalidate the last fadump registration, invalidate '/proc/vmcore', release
the reserved memory for general use and re-register for future kernel dump.
Once the dump
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
This patch introduces an sysfs interface '/sys/kernel/fadump_release_mem' to
invalidate the last fadump registration, invalidate '/proc/vmcore', release
the reserved memory for general use and re-register for future kernel dump.
Once the dump
Hello Simon,
I wanted to inquire about the next kexec release. The current release
(2.0.2) has a few bugs that prevent mpc85xx from working that are
fixed in git head. Any plans to make a 2.0.3 release?
Regards,
Matthew
___
kexec mailing list
kexec
On Mon, Apr 18, 2011 at 03:15:22PM +, McClintock Matthew-B29882 wrote:
Hello Simon,
I wanted to inquire about the next kexec release. The current release
(2.0.2) has a few bugs that prevent mpc85xx from working that are
fixed in git head. Any plans to make a 2.0.3 release?
Hi Matthew
while (nodeoffset != -FDT_ERR_NOTFOUND) {
const void *buf;
int sz, ret;
- u64 val = 0;
+ u64 tmp;
buf = fdt_getprop(blob_buf, nodeoffset, cpu-release-addr,
sz);
- if (sz == 4
Matthew McClintock wrote:
+unsigned long long initrd_base, initrd_size;
+unsigned long long devicetree_base, devicetree_size;
These should be declared uint64_t, to match the code that assigns them.
+ if (n == 4) {
+ kernel_end =
kexec built from git HEAD shows release date as 13th August 2009, which is not
correct. Instead of that use the build date as release date.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac
On Mon, Mar 29, 2010 at 02:52:58PM +0300, Ameya Palande wrote:
kexec built from git HEAD shows release date as 13th August 2009, which is not
correct. Instead of that use the build date as release date.
Thanks, applied.
___
kexec mailing list
kexec
Hi,
wouldn't it time for kexec-tools 2.1? There are many changes in git
currently. :)
Bernhard
--
Bernhard Walle, SUSE Linux Products GmbH, Architecture Development
___
kexec mailing list
kexec@lists.infradead.org
54 matches
Mail list logo
