From: Bernhard Walle [EMAIL PROTECTED]
This patch fixes following compiler warning:
kexec/arch/i386/kexec-x86.c:234: \
warning: missing initializer
kexec/arch/i386/kexec-x86.c:234: \
warning: (near initialization for 'arches[5].arch')
Signed-off-by: Bernhard Walle
From: Bernhard Walle [EMAIL PROTECTED]
With the previous patch, we have a duplication between that both functions
for following tasks:
- don't report the interrupt table as RAM,
- set the mem_min and mem_max limits for kdump.
This patch removes that redundancy into the function
From: Bernhard Walle [EMAIL PROTECTED]
After the patch that provides /sys/firmware/memmap has been merged in the 'tip'
tree by Ingo Molnar, kexec should use that interface.
This patch implements architecture-independent parsing in a new file called
firmware_memmap.c. The x86 part is ported
From: Bernhard Walle [EMAIL PROTECTED]
This patch just removes trailing whitespace from kexec/arch/i386/kexec-x86.c
before modifying something.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/arch/i386/kexec-x86.c | 28
is currently broken in our kernel on
PPC64. Don't know why, we're investigating ...
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo
Hi,
* Greg KH [2008-06-26 15:24]:
On Thu, Jun 26, 2008 at 10:19:01PM +0200, Bernhard Walle wrote:
This patch adds /sys/firmware/memmap interface that represents the BIOS
(or Firmware) provided memory map. The tree looks like:
/sys/firmware/memmap/0/start (hex number
This patch uses the /sys/firmware/memmap interface provided in the last patch
on the x86 architecture when E820 is used. The patch copies the E820
memory map very early, and registers the E820 map afterwards via
firmware_map_add_early().
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch
or not. This is highly variable. So,
please ignore above comment.
Maybe below 4G makes sense. Because you need some 32 bit memory for DMA.
That's mostly an architecture limitation, so that could make sense to
check here.
But I don't have any strong opinion about that.
Bernhard
--
Bernhard Walle, SUSE
* Vivek Goyal [2008-06-27 10:19]:
On Fri, Jun 27, 2008 at 04:06:56PM +0200, Bernhard Walle wrote:
* Vivek Goyal [2008-06-27 09:42]:
Thinking more about. Let me step back. I think it is not good idea to
take this kernel take decision about the capability of kernel being
loaded
* [EMAIL PROTECTED] (Eric W. Biederman) [2008-06-27 11:00]:
Bernhard Walle [EMAIL PROTECTED] writes:
Ah, that's true. Only on x86, right? (That would be an alternative for
ia64, too ...)
But in general policy should go in userspace (if possible), so I agree
with you that kexec-tools
I would suggest to remove the experimental status from Kdump.
Kdump is now in the kernel since a long time and used by Enterprise
distributions. I don't think that experimental is true any more.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/Kconfig |1 -
fs/Kconfig
architectures can be added later.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
This patch uses the /sys/firmware/memmap interface provided in the last patch
on the x86 architecture when E820 is used. The patch copies the E820
memory map very early, and registers the E820 map afterwards via
firmware_map_add_early().
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch
to /proc. Talk to Greg.
http://lkml.org/lkml/2008/6/26/75
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
* Mikael Pettersson [2008-06-26 10:13]:
Vivek Goyal writes:
On Wed, Jun 25, 2008 at 09:57:05PM +0200, Bernhard Walle wrote:
This patch adds /sys/firmware/memmap interface that represents the BIOS
(or Firmware) provided memory map. The tree looks like:
/sys/firmware/memmap
* Vivek Goyal [2008-06-26 08:35]:
On Thu, Jun 26, 2008 at 10:28:03AM +0200, Bernhard Walle wrote:
* Andrew Morton [2008-06-26 01:23]:
config PROC_VMCORE
bool /proc/vmcore support (EXPERIMENTAL)
-depends on PROC_FS EXPERIMENTAL CRASH_DUMP
This bug fixes the generation of vmcoreinfo files on 32bit hosts for ELF64
files, i.e. 64bit kernels. The concrete problem was PPC64 which is built in a
32bit environment at SUSE.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
makedumpfile.c | 37
This patch removes the experimental status of kdump on IA64. kdump is on IA64
now since more than one year and it has proven to be stable.
For i386/x86_64, a similar patch has been accepted by Ingo Molnar and Vivek
Goyal.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/powerpc/Kconfig
This patch removes the experimental status of kdump on IA64. kdump is on IA64
now since more than one year and it has proven to be stable.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/ia64/Kconfig |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ia64
This is just a cleanup patch that removes trailing whitespace from
implementation files.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
diskdump_mod.h |2 +-
ia64.c |4 ++--
makedumpfile.c | 52 ++--
makedumpfile.h |2
-by: Bernhard Walle [EMAIL PROTECTED]
---
makedumpfile.c |4
makedumpfile.h | 16
2 files changed, 12 insertions(+), 8 deletions(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -30,6 +30,10 @@ struct DumpInfo *info = NULL;
int message_level;
/*
+ * Forward
option to implement such a progress.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
makedumpfile.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -32,6 +32,17 @@ int message_level;
/*
* Forward declarations
This patch removes the experimental status of kdump on PPC64. kdump is on PPC64
now since more than one year and it has proven to be stable.
For i386/x86_64, a similar patch has been accepted by Ingo Molnar and Vivek
Goyal.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/powerpc
CONFIG_EMBEDDED.
Now we have all opinions about how making that interface
configurable. Mikael, should an option under CONFIG_EMBEDDED be
acceptable for you?
Then I can repost the patch, Cc Greg KH and see if the sysfs structure
would be ok for him.
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH
.
Please provide feedback!
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/kernel/setup.c | 70 +++
1 files changed, 52 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a81d82c..c30bb7b
This patch fixes a small bug in documentation: x86_64 also has now
the ability to build a relocatable kernel.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
Documentation/kdump/kdump.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/kdump/kdump.txt
This patch uses the /sys/firmware/memmap interface provided in the last patch
on the x86 architecture when E820 is used. The patch copies the E820
memory map very early, and registers the E820 map afterwards via
firmware_map_add_early().
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch
. Added Greg KH to Cc as suggested by H. Peter Anvin to review sysfs
structure.
2. Display the configuration option only if CONFIG_EMBEDDED is set.
If not, default to including the code in any case as it is not only
useful for kexec.
Please review!
Signed-off-by: Bernhard Walle [EMAIL
via the firmware. So kexec can:
- use the original memory map for rebooting,
- use the /proc/iomem for setting up the ELF core headers for kdump
case that should only represent the memory of the system.
The patch has been tested on i386 and x86_64.
Signed-off-by: Bernhard Walle [EMAIL
* Srinivas Murthy [EMAIL PROTECTED] [2008-06-24 16:48]:
Any suggestions for how to cross compile the crash-4.0-6.3 for x86_64
on an x86 system.
Tweak the Makefile. Or ask Dave on the crash list
(https://www.redhat.com/mailman/listinfo/crash-utility).
Bernhard
--
Bernhard Walle, SUSE LINUX
This patch modifies the E820 map when specifying the mem kernel command line
parameter. That's the behaviour i386 had before the merging work in the
current tip tree.
As Yinghai Lu pointed out in email discussion, e820_update_range() should be
used for the updating instead of an own function. Two
that uses e820_update_range()
to limit the E820 map when mem parameter is specified on the command line.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/kernel/e820.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
was tested for compilation and booting on a 32 bit and 64 bit system.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/kernel/e820.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7d1109b..19b7f05 100644
Allow the specifying of ULLONG_MAX to limit the whole E820 map from the
specified start to the end. Without the patch, there would be integer
overflows.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/kernel/e820.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions
* Yinghai Lu [2008-06-25 09:01]:
On Wed, Jun 25, 2008 at 5:02 AM, Bernhard Walle [EMAIL PROTECTED] wrote:
}
early_param(mem, parse_memopt);
@@ -1023,6 +1025,7 @@ static int __init parse_memmap_opt(char *p)
e820_add_region(start_at, mem_size, E820_RESERVED
was tested for compilation and booting on a 32 bit and 64 bit system.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/kernel/e820.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index a1b0548..3771386 100644
* Yinghai Lu [EMAIL PROTECTED] [2008-06-25 09:58]:
On Wed, Jun 25, 2008 at 9:03 AM, Bernhard Walle [EMAIL PROTECTED] wrote:
only this one is needed now. but please change ULLONG_MAX to
ULLONG_MAX - mem_size
Why can't we add that check at the beginning of e820_update_range() as
you
via the firmware. So kexec can:
- use the original memory map for rebooting,
- use the /proc/iomem for setting up the ELF core headers for kdump
case that should only represent the memory of the system.
The patch has been tested on i386 and x86_64.
Signed-off-by: Bernhard Walle [EMAIL
architectures can be added later.
This patch is RFC. It has been tested on x86-64 and i386 and
replaces my previous attemt that adds such an interface via
procfs.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
___
kexec mailing list
kexec@lists.infradead.org
This patch uses the /sys/firmware/memmap interface provided in the last patch
on the x86 architecture when E820 is used. The patch copies the E820
memory map very early, and registers the E820 map afterwards via
firmware_map_add_early().
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch
I would suggest to remove the experimental status from Kdump.
Kdump is now in the kernel since a long time and used by Enterprise
distributions. I don't think that experimental is true any more.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/Kconfig |1 -
fs/Kconfig
* Yinghai Lu [2008-06-22 13:11]:
On Sun, Jun 22, 2008 at 12:56 PM, Bernhard Walle [EMAIL PROTECTED] wrote:
* Yinghai Lu [EMAIL PROTECTED] [2008-06-20 13:34]:
any problem that you encountered without this patch?
Sorry, forgot to answer that question.
Yes, if you use mem=3G and take
when you build i386 on
x86-64). You need to build a cross compiler, and then you would pass
that via
CC=your-cross-compiler ./configure
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
___
kexec mailing list
kexec
not exist on SUSE, we use 'linux32'. I don't have
an overview about other Linux distributions. Unfortunately, that seems
to be not standardised via LSB.)
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
___
kexec mailing
that it's ok for kexec to export an
unfiltered view of the memory map.
The patch has been tested on i386 and x86_64.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman
This patch copies the E820 map very early, before the kernel applies various
operations. That copy is used later to register only the BIOS-provided E820
map later in the resource tree for /proc/firmware_mem.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/kernel/e820.c | 44
full-time on that, so be
a bit patient. :)
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
.
implies that it's by design.
(And EFI code might be different again. However, I have no non-IA64
EFI machine to test.)
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
___
kexec mailing list
kexec@lists.infradead.org
the error
handling to the caller.
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
the e820 map to avoid double free */
#ifdef CONFIG_NUMA
nid = phys_to_nid(phys);
[...]
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org
:
--
From: Bernhard Walle [EMAIL PROTECTED]
Subject: Add 'flags' parameter to reserve_bootmem_generic()
This patch adds a 'flags' parameter to reserve_bootmem_generic() like it
already has been added in reserve_bootmem() with commit
72a7fe3967dbf86cb34e24fbf1d957fe24d2f246.
It also
vendors had similar
issues.
Ok, in that case it makes indeed sense to just return success here.
Here's my third version of that patch:
-
From: Bernhard Walle [EMAIL PROTECTED]
Subject: Add 'flags' parameter
.
Bernhard
--
From: Bernhard Walle [EMAIL PROTECTED]
Subject: Add 'flags' parameter to reserve_bootmem_generic()
This patch adds a 'flags' parameter to reserve_bootmem_generic() like it
already has been added
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 16:54]:
On Mon, Jun 09, 2008 at 10:42:11PM +0200, Bernhard Walle wrote:
Hi Vivek,
* Vivek Goyal [EMAIL PROTECTED] [2008-06-09 16:29]:
Can you please put some more explanation comment here to explain that
why it is ok to return
/Thomas and how to merge patches. So, I'll wait a few days and then
resend the patches with Andrew in Cc.
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance
___
kexec mailing list
kexec@lists.infradead.org
http
in
5c3391f9f749023a49c64d607da4fb49263690eb when adding the BOOTMEM_EXCLUSIVE
parameter.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
arch/x86/kernel/setup_64.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -243,7 +243,7 @@ static void __init
only, so no need to test on other architectures.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman
This patch changes the function reserve_bootmem_node() from void to int,
returning -ENOMEM if the allocation fails.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED];
---
include/linux/bootmem.h |2 +-
mm/bootmem.c|6 --
2 files changed, 5 insertions(+), 3 deletions
This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for i386
and prints a error message on failure.
The patch is still for 2.6.26 since it is only bug fixing. The unification of
reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27.
Signed-off-by: Bernhard
with i386.
Fix tested on x86_64-suse-linux and i586-suse-linux.
I also added __always_inline__ to make sure that the function gets always
inlined, regardless of optimisation compiler flags.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
purgatory/arch/i386/include/arch/io.h | 42
.'
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
kernel.
The mistake has been introduced by commit
3c5bb06948881b3e31c783c19edef74275794280
by myself.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/kexec.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/kexec.c b/kexec/kexec.c
index 0a8ed32..fee895d
.
The problem was introduced in 3bf0213789d56054f601c5a06372f78567aacdd9 by
myself, the initial EDD implementation.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/arch/i386/x86-linux-setup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/i386/x86-linux
* [EMAIL PROTECTED] (Eric W. Biederman) [2008-05-23 17:36]:
As there is no real justification for it. At this
point getting user space fixed so that it works on older kernels
seems important.
http://article.gmane.org/gmane.linux.kernel.kexec/1534 should fix this.
This fixes the problem in kexec-tools that the patch
http://article.gmane.org/gmane.linux.kernel/685027 tries to fix in kernel.
The fix in userspace is correct.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/kexec.c |8
1 files changed, 8 insertions(+), 0 deletions
* Jamey Sharp [EMAIL PROTECTED] [2008-05-23 15:13]:
On Thu, May 22, 2008 at 6:34 AM, Bernhard Walle [EMAIL PROTECTED] wrote:
* Jamey Sharp [EMAIL PROTECTED] [2008-05-15 22:48]:
OK, I haven't quite gotten around to posting the Windows kernel driver
source that goes with this.
Do you
Hi,
* Armin ranjbar [EMAIL PROTECTED] [2008-05-25 15:19]:
i have a problem with kexec , when i load a panic kernel with kexec -p
which goes successful and panic the kernel using alt+sysrc+c , well ,
nothing happens , system says that triggering a panic and it freezes .
note that the main
* Armin ranjbar [EMAIL PROTECTED] [2008-05-25 17:03]:
Armin ranjbar , System Administrator
i did tried vga=normal , still freezes , different is that the shell
cursor is still blinking , very strange .
no panic like LED flashing , in fact no flashing at all .
That's a hardware cursor, it
unsigned int', but argument 8 has type 'Elf64_Xword'
Tested on i686-pc-linux-gnu.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
index 7d2befe..f01accb 100644
--- a/kexec/crashdump-elf.c
+++ b/kexec/crashdump-elf.c
@@ -4,12 +4,12 @@
#endif
Hi,
* Jamey Sharp [EMAIL PROTECTED] [2008-05-23 15:13]:
I was hoping for more feedback than just code style though. :-)
Of course. I'll give it a try first. I'm not very familar with
Windows programming, though. I'm interested in kexec on Windows because
it might be a nice way to start a
* [EMAIL PROTECTED] (Eric W. Biederman) [2008-05-23 13:14]:
What we need to do is fix /sbin/kexec to pass in the correct
architecture of the kernel for unload as it does for load.
How should it know that it unloads a 32 bit kernel on a 64 bit system?
It doesn't have access to the kernel any
* Lombard, David N [2008-05-13 11:24]:
The problem is that not all boot options are always usable in the next
kernel, in addition to being architecturally specific, it's very
situational. Having written that, a generic framework could be usable.
Yes. I think that the framework to read out
Update: Use the length field of the EDD header. Some BIOSe don't use
the full EDD_DEVICE_PARAM_SIZE bytes, depending on the EDD version.
From: Bernhard Walle [EMAIL PROTECTED]
Subject: [PATCH] Implement EDD support for 32 bit boot
To: kexec@lists.infradead.org
This patch implements EDD support
Hi,
at first thanks for looking at the patch.
* Michael Neuling [EMAIL PROTECTED] [2008-05-09 12:13]:
In message [EMAIL PROTECTED] you wrote:
This patch adds an option --reuse-cmdline for people that are lazy in
typin
g
--append=$(cat /proc/cmdline). The advantage of --reuse-cmdline
.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
doc/linux-i386-zero-page.txt |3 +--
include/x86/x86-linux.h |2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/doc/linux-i386-zero-page.txt
+++ b/doc/linux-i386-zero-page.txt
@@ -75,5 +75,4 @@ OffsetType
problem, discovered in
https://bugzilla.novell.com/show_bug.cgi?id=383210.
The last patch that updates the E820MAX constant is required to use that patch.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
include/x86/x86-linux.h | 39 +-
kexec/arch/i386/x86-linux-setup.c | 227
kernel for dumping.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/kexec.8 |4
1 file changed, 4 deletions(-)
--- a/kexec/kexec.8
+++ b/kexec/kexec.8
@@ -55,10 +55,6 @@ where
.I kernel\-image
is the kernel file that you intend to reboot to.
.PP
-Note: Compressed kernel images
because there was some confusion in
https://bugzilla.novell.com/show_bug.cgi?id=387601.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/kexec.8 | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/kexec/kexec.8
+++ b/kexec/kexec.8
@@ -67,6 +67,17
/autobook_43.html.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
bootstrap | 29 +
1 file changed, 29 insertions(+)
--- /dev/null
+++ b/bootstrap
@@ -0,0 +1,29 @@
+#! /bin/sh
+# bootstrap -- Use this script to create generated files from the CVS dist
+# Copyright (C
in case a
panic kernel is loaded.
If you like the option I can also add it for really all architectures. Tested
only
with x86-bzImage both the kexec and kdump case.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/arch/i386/kexec-bzImage.c | 12 +++-
kexec/arch/i386/kexec-elf
This patch just adds the x86-bzImage type to the manpage.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
kexec/kexec.8 | 35 +++
1 file changed, 35 insertions(+)
--- a/kexec/kexec.8
+++ b/kexec/kexec.8
@@ -206,6 +206,41 @@ Use
as the kernel's initial
* Eric W. Biederman [2008-04-29 10:15]:
Ok. I'm guessing that whatever it is immediately after
the e820 map dump causes the box to go south.
But this is a very good clue that your BIOS just can't
handle being run after the linux kernel has run at
this point. Unfortunately this is common
-by: Bernhard Walle [EMAIL PROTECTED]
---
Documentation/kdump/kdump.txt |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -245,6 +245,8 @@ The syntax is:
crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED
Hi,
* Eric W. Biederman [2008-04-23 07:00]:
Bernhard Walle [EMAIL PROTECTED] writes:
* Jamey Sharp [2008-04-22 16:44]:
On Tue, Apr 22, 2008 at 6:16 AM, Bernhard Walle [EMAIL PROTECTED] wrote:
did anybody try the --real-mode option with current release? I tried
it on two machines
* Jamey Sharp [2008-04-22 16:44]:
On Tue, Apr 22, 2008 at 6:16 AM, Bernhard Walle [EMAIL PROTECTED] wrote:
did anybody try the --real-mode option with current release? I tried
it on two machines, and on one machine it just reboots, on the other
machine it hangs.
I think you're
Hi,
did anybody try the --real-mode option with current release? I tried it
on two machines, and on one machine it just reboots, on the other
machine it hangs.
I use
kexec --serial=0x03f8 --serial-baud=57600 --console-serial \
-l /boot/vmlinuz --initrd=/boot/initrd
* Jay Lan [EMAIL PROTECTED] [2008-03-18 21:45]:
BTW, the SYSRQ_ENABLED in /etc/sysconfig/sysctl is not set
by default. Any bad side effect of setting it?
AFAIR security concerns.
May I ask how RedHat/Fedora handles that?
Bernhard
___
kexec
* Neil Horman [EMAIL PROTECTED] [2008-03-03 15:30]:
Hey all-
Patch to reduce the alignment constraints on ia64 elf core headers.
From what I can see there is no need to align the elf core header structure
to
the EFI_PAGE_SIZE (given that the EFI will never read this data, only the
* Simon Horman [EMAIL PROTECTED] [2008-02-22 10:02]:
On Thu, Feb 21, 2008 at 10:28:33AM +0100, Bernhard Walle wrote:
* Simon Horman [EMAIL PROTECTED] [2008-02-21 10:21]:
On Wed, Feb 20, 2008 at 09:07:55AM +0100, Bernhard Walle wrote:
This patch fixes following compilation warning
* Simon Horman [EMAIL PROTECTED] [2008-02-21 10:21]:
On Wed, Feb 20, 2008 at 09:07:55AM +0100, Bernhard Walle wrote:
This patch fixes following compilation warning:
purgatory/purgatory.c:21: warning: passing argument 2 of 'sha256_update'
makes pointer from integer without a cast
* Simon Horman [EMAIL PROTECTED] [2008-02-21 10:16]:
commit e959e493753c740eb7554bc2191c58b079761e11
Author: Simon Horman [EMAIL PROTECTED]
Only include needed files in distribution tarball
create mode 100644 doc/Makefile
create mode 100644 include/Makefile
create mode 100644
This patch fixes following compilation warning:
purgatory/purgatory.c:21: warning: passing argument 2 of 'sha256_update' makes
pointer from integer without a cast
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
purgatory/purgatory.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
* Simon Horman [EMAIL PROTECTED] [2008-02-19 09:11]:
Hi all,
Sorry for being a bit slow in attending to patches of late.
I think that I have got all of them now, if not, please just drop
me a line.
I have made an RC release which includes a moderate ammount of change
sice 20080219. If no
* Simon Horman [EMAIL PROTECTED] [2008-02-20 02:51]:
Can you fix this? :)
Appologies. This has now been fixed.
Thanks! I also get following error when trying to build
$ make
make: *** No rule to make target
* Sachin P. Sant [EMAIL PROTECTED] [2008-02-05 06:33]:
Bernhard Walle wrote:
* Vivek Goyal [EMAIL PROTECTED] [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Attached
* Vivek Goyal [EMAIL PROTECTED] [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Bernhard
___
kexec mailing list
kexec@lists.infradead.org
* Vivek Goyal [EMAIL PROTECTED] [2008-01-30 22:45]:
No. 2.04 is really old. As per boot.txt, it was introduced in 2.6.14.
Anyway, thinking about it more, Large command lines were introduced in
2.6.21 kernel (for both i386 and x86_64). cmdline_size was introduced
in 2.6.22 (for both i386
* Neil Horman [EMAIL PROTECTED] [2008-01-28 21:53]:
return -1;
}
+ if (setup_header.protocol_version = 0x0206) {
+ if (command_line_len setup_header.cmdline_size) {
+ dbgprintf(Kernel command line too long for kernel!\n);
+
* kevint [EMAIL PROTECTED] [2008-01-10 01:45]:
I am relatively new to kexec, and am running into some problems with
relocations when I try to use kexec to load several different X86_64
kernels. I think this is the correct list to post to, but please point me
in the right direction if it
101 - 200 of 255 matches
Mail list logo
