Hi all,
I am happy to announce the release of kexec-tools 2.0.6.
This is a bugfix release to address a number of problems
discovered in 2.0.5.
The release can be downloaded from kernel.org:
http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.6.tar.xz
http://kernel.org
Install sample eppic scripts in the documentation directory
Signed-off-by: Aruna Balakrishnaiah
---
Makefile |2 ++
makedumpfile.spec |2 ++
2 files changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index 2f4845c..6ee2da5 100644
--- a/Makefile
+++ b/Makefile
@@ -91,3 +9
Signed-off-by: Aruna Balakrishnaiah
---
eppic_scripts/README | 294 ++
1 file changed, 294 insertions(+)
create mode 100644 eppic_scripts/README
diff --git a/eppic_scripts/README b/eppic_scripts/README
new file mode 100644
index 000..040b3ba
On Thu, Mar 6, 2014 at 12:00 AM, Muli Ben-Yehuda wrote:
> On Wed, Mar 05, 2014 at 10:50:41PM -0800, H. Peter Anvin wrote:
>
>> OK, second question... is it time to axe Calgary?
>
> I don't know of anyone still using it, but it's not
> impossible. Calgary and CalIOC2 machines would now be ~5-8 year
When preparing dump-capturing kernel, kexec userspace tool needs to know
actual amount of memory used by the running kernel. This may differ from
extire available DRAM for a couple of reasons. To address this issue,
kdump kernel support code injects several attributes into device tree that
are late
On Thu, Mar 06, 2014 at 08:47:56AM +0200, Muli Ben-Yehuda wrote:
> On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote:
>
> > Hi, Muli
> >
> > saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
> > could get rid of saved_max_pfn at all. But If this can't work, how
> > abou
On Thu, 2014-03-06 at 18:24 +0400, Nikita Yushchenko wrote:
> When preparing dump-capturing kernel, kexec userspace tool needs to know
> actual amount of memory used by the running kernel. This may differ from
> extire available DRAM for a couple of reasons. To address this issue,
> kdump kernel su
> On Thu, 2014-03-06 at 18:24 +0400, Nikita Yushchenko wrote:
> > When preparing dump-capturing kernel, kexec userspace tool needs to
> > know actual amount of memory used by the running kernel. This may
> > differ from extire available DRAM for a couple of reasons. To address
> > this issue, kdump
Move filling crash_memory_range table entries into a separate routine,
which saves quite a few lines of code.
In this routine, if range spawns over lowmem-highmem border, split range
into two. This is needed to get proper virtual address for lowmem part.
Similar thing is already done for x86. Cred
