Hello,
Le 23/01/2013 02:19, Atsushi Kumagai a écrit :
Hello Louis,
On Tue, 22 Jan 2013 14:52:09 +0100
Bouchard Louis louis.bouch...@canonical.com wrote:
Hello Kumagai-san,
Following a suggestion from Dave Anderson, I have tested the
makedumpfile --dump-dmesg option. After some
On Wednesday, January 30, 2013 06:40:46 AM H. Peter Anvin wrote:
The right thing to do as I have discussed with the people involved is to
modify the memory map data structure to have a new memory type ID for
memory which is to be dumped. That eliminates the need to put all this
info into the
From: Yinghai Lu ying...@kernel.org
memmap=exactmap will throw away all original, but also until then
user defined (through other provided memmap= parameters) areas.
That means all memmap= boot parameters passed before a memmap=exactmap
parameter are not recognized.
Without this fix:
memmap=x@y
Once again, what is wrong about this... the semantics are consistent, and
breaking them when long established makes no sense.
Thomas Renninger tr...@suse.de wrote:
From: Yinghai Lu ying...@kernel.org
memmap=exactmap will throw away all original, but also until then
user defined (through other
This functionality will be picked up by later memmap= boot
parameter options. Originally E820_USABLE declared memory (used by the
productive, but crashed kernel) will get converted to the new
E820_RESERVED_KDUMP type.
The memory area where the kdump kernel resides (passed via memmap=X@Y
by
kdump voided the whole original e820 map and half way made
it up via memmap= options passed via kdump boot params again.
But this is conceptionally wrong. The whole original memory ranges
which are declared reserved, ACPI data/nvs or however are not usable
must stay the same and get honored by
I am NAKing 1/3 and think you seriously need to explain your design choice for
the rest. Unnecessarily complex is not an explanation, it is a cop-out.
Thomas Renninger tr...@suse.de wrote:
The sent patches are against latest x86-tip origin/mm2 branch
(3.8.0-rc5) based.
Please consider to
On Wednesday, January 30, 2013 05:16:22 PM H. Peter Anvin wrote:
I am NAKing 1/3 and think you seriously need to explain your design
choice for the rest. Unnecessarily complex is not an explanation, it
is a cop-out.
Ok, 1/3 should not go in because it changes boot param processing
which works
On 01/30/2013 08:39 AM, Thomas Renninger wrote:
This:
- heavily cleans up the unnecesary reserved memory passing via memmap=
- still provides a clean way of passing a valid e820 table through
boot structures (no Linux kernel made up e820 type passing)
- Keeps complexity as low as possible
- Original Message -
Bouchard Louis louis.bouch...@canonical.com wrote:
I now have what looks like a working patch for this issue. Thank to Dave
Anderson (crash) and Eric Biederman (vmcore-dmesg) for having chewed
most of the work for me.
My only remaining problem is to be able
On Wed, Jan 30, 2013 at 8:52 AM, H. Peter Anvin h...@zytor.com wrote:
The e820 map is fundamentally what you care about, and it has to be passed
correctly anyway -- or your changes are utterly broken. The modifications
that have to be performed (from RAM to KDUMP) is trivial.
I have to admit
H. Peter Anvin h...@zytor.com writes:
I have to admit to being rather confused as to the separation of various bits
of
kdump between the host kernel and various user-space components, but the whole
use of the command line to pass the memory map seems just broken in light of
everything that
set LOADER_TYPE_KEXEC
Signed-off-by: Yinghai Lu ying...@kernel.org
---
include/x86/x86-linux.h |1 +
kexec/arch/i386/x86-linux-setup.c |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/x86/x86-linux.h b/include/x86/x86-linux.h
index 8f7a797..ea11042
We need to keep space for bss, heap/stack before command line.
otherwise command_line will be cleared by kernel 16bit init code.
also need to set 32bit start in real_mode header, kernel 16bit code
need to jump there.
Also don't touch regs16 if --real-mode is not specified.
Signed-off-by:
kexec bzImage path setup data is shared with real-mode path, and
setup_header is copied together with setup_code.
Later 32bit just use whole area as boot_params for real_mode_data.
but those area for boot_params around setup_header is
not cleaned that will leave some field in boot_param as
Now we have limit kdump reserved under 896M, because kexec has the limitation.
and also bzImage need to stay under 4g.
kernel parts changes get into tip tree now and could be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm2
here patches are for kexec tools to
will use ext_ramdisk_image/size, and xloadflags to put
ramdisk and bzImage high for 64bit.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
include/x86/x86-linux.h | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/include/x86/x86-linux.h
kernel could have that in /proc/iomem, will use it for kdump kernel
for dma32
Signed-off-by: Yinghai Lu ying...@kernel.org
---
kexec/arch/i386/crashdump-x86.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/kexec/arch/i386/crashdump-x86.c
need to check xloadflags to see the bzImage is for 64bit relocatable.
-v2: add kexec-bzImage64.c according to Eric.
-v3: don't need to purgatory under 2g after Eric's change to purgatory code.
-v4: use locate_hole find position first then add_buffer... suggested by Eric
add buffer for kernel
We could put ramdisk/cmdline above for bzImage on 64bit for protocol 2.12.
-v2: change ext_... handling to way that eric like.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
kexec/arch/i386/x86-linux-setup.c | 36 +++-
kexec/arch/i386/x86-linux-setup.h | 15
My kdump initrd failed in mounting root disk.
The system runs sles11sp2 and
kexec-tools-2.0.0-53.43.10.
I saw the scripts executed in initrd contain debug like this:
[ $debug ] echo
How do I turn on the debug switch when creating the kdump
initrd?
Thanks,
Jay
On 01/30/2013 01:25 PM, Yinghai Lu wrote:
+static void clean_boot_params(unsigned char *real_mode, unsigned long size)
+{
+ unsigned long end;
+
+ /* clear value before header */
+ memset(real_mode, 0, 0x1f1);
+ /* clear value after setup_header */
+ end =
H. Peter Anvin h...@zytor.com writes:
On 01/30/2013 10:52 AM, Eric W. Biederman wrote:
H. Peter Anvin h...@zytor.com writes:
I have to admit to being rather confused as to the separation of various
bits of
kdump between the host kernel and various user-space components, but the
whole
On Wed, Jan 30, 2013 at 1:34 PM, H. Peter Anvin h...@zytor.com wrote:
On 01/30/2013 01:25 PM, Yinghai Lu wrote:
+static void clean_boot_params(unsigned char *real_mode, unsigned long size)
+{
+ unsigned long end;
+
+ /* clear value before header */
+ memset(real_mode, 0,
On 01/30/2013 01:57 PM, Eric W. Biederman wrote:
Yes, those seem to be the options, and we're currently discussing which one.
The second seems to make more sense to me. The kexec tools build the
memory map anyway, and it makes sense to me at least to just build a
memory map with the
On 01/30/2013 02:09 PM, Yinghai Lu wrote:
yes.
how about clear all and copy only setup_header?
that looks more readable.
Yes, and that is the recommended procedure anyway.
-hpa
___
kexec mailing list
kexec@lists.infradead.org
H. Peter Anvin h...@zytor.com writes:
On 01/30/2013 01:57 PM, Eric W. Biederman wrote:
Yes, those seem to be the options, and we're currently discussing which one.
The second seems to make more sense to me. The kexec tools build the
memory map anyway, and it makes sense to me at least to
On 01/30/2013 02:29 PM, Eric W. Biederman wrote:
I think I would prefer that to call that new type RESERVED_MEM or
RESERVED_CACHABLE. Being more specific is fine but dumpable certainly
doesn't bring to mind what we are saying. Especially since we already
communicate which areas were memory
On Wed, Jan 30, 2013 at 2:41 PM, H. Peter Anvin h...@zytor.com wrote:
On 01/30/2013 02:29 PM, Eric W. Biederman wrote:
The bigger question is if we need a separate value from the current
E820_RESERVED_KERN. Since it is always easier to have multiple values
with the same semantics than it is
On 01/30/2013 04:15 PM, Thomas Renninger wrote:
I guess both ways are a huge enhancement compared to what we have now.
Which approach to finally take should not matter that much, but because
of above I still prefer to go this way:
- Pass a kernel command line option that just changes the
On Wednesday, January 30, 2013 02:29:04 PM Eric W. Biederman wrote:
H. Peter Anvin h...@zytor.com writes:
On 01/30/2013 01:57 PM, Eric W. Biederman wrote:
Yes, those seem to be the options, and we're currently discussing which
one.
The second seems to make more sense to me. The kexec
31 matches
Mail list logo
