On Fri, 4 Apr 2014 11:56:07 +0200
Petr Tesarik ptesa...@suse.cz wrote:
Kumagai-san,
this patch was inspired by this post of yours:
http://lists.infradead.org/pipermail/kexec/2013-November/010445.html
Unfortunately, this rewrite never happened, so I took the liberty of
overtaking
Pass the mmd pointer itself instead of the individual fields, so additional
information can be kept in mem_map_data.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
Thanks to the previous commit, __exclude_unnecessary_pages does not
require any specific size of the cycle.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 59 --
1 file changed, 59 deletions(-)
diff --git
will still work
correctly.
Note that clear_bit_on_2nd_bitmap_for_kernel() accepts PFNs outside the
current cyclic range. It willreturn FALSE, so such PFNs are not counted.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 47
support without
having to care about the appropriate size of the cyclic buffer.
Changelog:
* v2:
- Keep excluded regions per mem_map_data
- Process excluded pages in chunks
Petr Tesarik (3):
Pass mmd pointer to __exclude_unnecessary_pages
Generic handling of multi-page exclusions
Get rid
On Fri, 28 Mar 2014 17:46:22 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
On Fri, 28 Mar 2014 12:00:47 +0100
Petr Tesarik ptesa...@suse.cz wrote:
On Thu, 27 Mar 2014 14:54:41 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
[snip]
Here the fixed patch
On Mon, 31 Mar 2014 09:48:05 +
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
[...]
In the first place, we shouldn't truncate max_mapnr
based on dom0's mem_section since there are some domU's
memories on Xen dumps. Now, I think a better way for Xen
is just leaving max_mapnr as
On Thu, 22 Nov 2012 14:26:10 -0800
H. Peter Anvin h...@zytor.com wrote:
Bullshit. This should be a separate domain.
Thanks for top-posting, hpa...
Andrew Cooper andrew.coop...@citrix.com wrote:
On 22/11/12 17:47, H. Peter Anvin wrote:
The other thing that should be considered here is
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in get_machdep_info()
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
On Thu, 27 Mar 2014 14:54:41 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
On Thu, 27 Mar 2014 05:19:06 +
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Michael,
On Wed, 26 Mar 2014 10:55:07 +0100 (a/T)
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
.
Changes in v2:
* Call get_machdep_info() after cache_init(), so it can use readmem(VADDR, ...)
This now works for me after reverting commit ebe2fa3a.
Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable
makedumpfile.c | 35
From: Petr Tesarik p...@tesarici.cz
Xen dumps fail, because the p2m mapping is initialized too late.
The dependency goes like this:
- Xen uses FLATMEM
- get_mm_flatmem() uses info-dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list
From: Petr Tesarik p...@tesarici.cz
Xen dumps fail, because the p2m mapping is initialized too late.
The dependency goes like this:
- Xen uses FLATMEM
- get_mm_flatmem() uses info-dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list
From: Petr Tesarik p...@tesarici.cz
If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the
maximum PFN can be determined from the size of the mapping between PFN
and MFN.
Using this approach, filtering works for Xen kernels without debuginfo
(and even without adding more lines
Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there
are in fact only a few missing pieces. With the following two patches, I was
able to produce a dump even with high dump levels (-d17 and -d31).
Needless to say, this can reduce the size of Dom0 dumps considerably.
Petr
.
Changes in v2:
* Call get_machdep_info() after cache_init(), so it can use readmem(VADDR, ...)
This now works for me after reverting commit ebe2fa3a.
Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable
makedumpfile.c | 35
From: Petr Tesarik p...@tesarici.cz
If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the
maximum PFN can be determined from the size of the mapping between PFN
and MFN.
Using this approach, filtering works for Xen kernels without debuginfo
(and even without adding more lines
On Fri, 28 Mar 2014 17:46:22 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
On Fri, 28 Mar 2014 12:00:47 +0100
Petr Tesarik ptesa...@suse.cz wrote:
[snip]
That's because the bitmap length is calculated in prepare_bitmap_buffer
using info-max_mapnr, but create_1st_bitmap() still
Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there
are in fact only a few missing pieces. With the following two patches, I was
able to produce a dump even with high dump levels (-d17 and -d31).
Needless to say, this can reduce the size of Dom0 dumps considerably.
Petr
()
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index e91583d..d3f5237 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -3128,6 +3128,12 @@ out
If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the
maximum PFN can be determined from the size of the mapping between PFN
and MFN.
Using this approach, filtering works for Xen kernels without debuginfo
(and even without adding more lines to VMCOREINFO).
Signed-off-by: Petr
).
Needless to say, this can reduce the size of Dom0 dumps considerably.
Petr Tesarik (2):
Earlier initialization of dom0_mapnr
Get Dom0 max_pfn using pfn_mfn_frame_list if max_pfn unavailable
makedumpfile.c | 35 ---
1 file changed, 28 insertions(+), 7 deletions
If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the
maximum PFN can be determined from the size of the mapping between PFN
and MFN.
Using this approach, filtering works for Xen kernels without debuginfo
(and even without adding more lines to VMCOREINFO).
Signed-off-by: Petr
()
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index e91583d..d3f5237 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -3128,6 +3128,12 @@ out
that
it covers this case.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 0bd8b55..ea29239 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -7660,7 +7660,7 @@ initial_xen(void
One message may be longer than BUFSIZE. In that case, the output
buffer overflows, causing stack corruption. Solve it by flushing
the buffer when it gets full.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/makedumpfile.c
This patch series addresses several issues with the dump_log_entry()
function.
Petr Tesarik (3):
Fix string append in dump_log_entry()
Prevent buffer overflow in dump_log_entry
Optimize one-character output in dump_log_entry
makedumpfile.c | 19 +--
1 file changed, 13
Using sprintf to copy one character to the output buffer is overkill.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 261e1ad..a98258c 100644
--- a/makedumpfile.c
+++ b
when calling sprintf(), snprintf(), vsprintf(), and vsnprintf().
Depending on the version of gcc(1) used, and the compiler options
employed, calls such as the above will not produce the expected results.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 13 +++--
1
such as the above will not produce the expected results.
The original code is actually miscompiled on openSUSE 13.1.
It's also overkill to call sprintf() for something that can be done
with a simple assignment.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
Thanks, it seems good to me
to call sprintf() for something that can be done
with a simple assignment.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 579be61..013fce7 100644
--- a/makedumpfile.c
On Mon, 24 Feb 2014 11:41:31 -0500
Vivek Goyal vgo...@redhat.com wrote:
On Fri, Feb 21, 2014 at 03:59:10PM +0100, Borislav Petkov wrote:
[...]
...
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index d6629d4..5fddb1b 100644
---
location) is still supported and might be used at
least on some hardware. It is not, but that doesn't mean future BIOSes
may not re-implement something like that.
Sorry for coming late to the party...
Petr Tesarik
___
kexec mailing list
kexec
On Mon, 18 Nov 2013 13:41:02 +0100
Daniel Kiper daniel.ki...@oracle.com wrote:
On Mon, Nov 18, 2013 at 12:05:38PM +, George Dunlap wrote:
On 18/11/13 11:47, Daniel Kiper wrote:
On Mon, Nov 18, 2013 at 11:23:27AM +, David Vrabel wrote:
On 18/11/13 09:29, Jan Beulich wrote:
On
On Fri, 08 Nov 2013 13:27:05 +0800
Jingbai Ma jingbai...@hp.com wrote:
On 11/08/2013 01:21 PM, HATAYAMA Daisuke wrote:
(2013/11/08 14:12), Atsushi Kumagai wrote:
Hello Jingbai,
(2013/11/07 17:58), Jingbai Ma wrote:
On 11/06/2013 10:23 PM, Vivek Goyal wrote:
On Wed, Nov 06, 2013 at
V Mon, 04 Nov 2013 16:37:13 -0800
Jay Lan jay.zen@gmail.com napsáno:
Hi,
It seems the makedumpfile.spec was written for fedora. It
probably would work in rhel, but I was not able to build it
in an sles11sp2 build environment...
The spec file complained it needed
On Tue, 29 Oct 2013 09:53:57 +0900
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
(2013/10/25 20:05), Petr Tesarik wrote:
On Thu, 24 Oct 2013 10:42:12 +0900
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
(2013/10/24 0:51), Vivek Goyal wrote:
On Wed, Oct 23, 2013 at 09:05:06AM
, but then it's confusing to call the sysfs file
initial_apicid.
Unfortunately, all my systems list the same value under apicid and
initial apicid, so I don't know how to test.
Petr Tesarik
___
kexec mailing list
kexec@lists.infradead.org
http
On Wed, 9 Oct 2013 16:20:12 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Fri, Aug 30, 2013 at 08:43:56AM -0700, H. Peter Anvin wrote:
On 08/29/2013 04:51 PM, HATAYAMA Daisuke wrote:
This is not a regression just as Eric explains.
There is also my explanation in the description
On Fri, 20 Sep 2013 09:04:40 -0400 (EDT)
Dave Anderson ander...@redhat.com wrote:
- Original Message -
Hello Dave,
(2013/09/16 0:56), Dave Anderson wrote:
With the advent of LZO and snappy compression support, it would be
helpful if it could be readily determined
The last one (search for a debug vmlinux) is useful in identifying huge
pages with the PG_head/PG-tail flags. There was a patch from Petr
Tesarik
that enables that huge page filtering. I don't think you are taking that
one
as-is, but are reworking it. Seems like Hatayama-san was doing
can help you avoid some dead ends..?
HTH,
Petr Tesarik
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Mon, 16 Apr 2012 11:21:28 +0900
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
Currently, booting up 2nd kernel with multiple CPUs fails in most
cases since it enters 2nd kernel with AP if the crash happens on the
AP. The problem is to signal startup IPI from AP to BSP. Typical
result
On Wed, 6 Feb 2013 16:01:08 +0900
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Petr,
On Thu, 10 Jan 2013 09:48:51 +0900
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Petr,
On Wed, 19 Dec 2012 16:01:25 +0100
Petr Tesarik ptesa...@suse.cz wrote
(), then this
should help.
Stay tuned,
Petr Tesarik
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
V Mon, 3 Dec 2012 15:28:15 +0900
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp napsáno:
Hello Petr,
On Wed, 28 Nov 2012 14:56:58 +0900
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Petr,
On Fri, 24 Aug 2012 17:42:24 +0200
Petr Tesarik ptesa...@suse.cz wrote
V Tue, 27 Nov 2012 15:25:35 -0600
ebied...@xmission.com (Eric W. Biederman) napsáno:
Petr Tesarik ptesa...@suse.cz writes:
To allow filtering of huge pages, makedumpfile must be able to
identify them in the dump. This can be done by checking for the
appropriate page flag, so communicate
Dne Po 3. září 2012 05:42:33 Atsushi Kumagai napsal(a):
Hello Petr,
On Tue, 28 Aug 2012 19:49:49 +0200
Petr Tesarik ptesa...@suse.cz wrote:
Add a simple cache for pages read from the dumpfile.
This is a big win if we read consecutive data from one page, e.g.
page descriptors
- the routine is not able to translate
1G mappings without the change.
The thing with 1G pages is that they are not available on all platforms (AFAIK
only AMD has them).
Anyway, it should be two patches, in fact. Please stay tuned.
Petr Tesarik
SUSE Linux
they might get defined in
a later revision of the specification.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86_64.c | 33 +++--
makedumpfile.h | 21 +
2 files changed, 32 insertions(+), 22 deletions(-)
--- a/arch/x86_64.c
+++ b/arch/x86_64
The remap_init() function lacks a return statement when all goes well.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86.c |1 +
1 file changed, 1 insertion(+)
--- a/arch/x86.c
+++ b/arch/x86.c
@@ -64,6 +64,7 @@ remap_init(void)
}
max_numnodes = n;
+ return
. for vmalloc areas or Xen page frame table data, which are not
contiguous in physical memory.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
Makefile |4 -
cache.c| 119
+
cache.h| 26
makedumpfile.c
Dne Po 27. srpna 2012 18:19:20 Trapp, Norbert napsal(a):
Hello Petr,
-Original Message-
From: Petr Tesarik [mailto:ptesa...@suse.cz]
Sent: Friday, August 24, 2012 5:46 PM
To: kexec@lists.infradead.org
Cc: Trapp, Norbert
Subject: [PATCHv3 0/9] Support Xen versions up to xen
symbol, and Dom0 physical-machine mapping is
initialized in get_machdep_info (called from initial).
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
--- a/makedumpfile.c
+++ b
...@ts.fujitsu.com
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5306,10 +5306,7 @@ get_structure_info_xen(void)
{
SIZE_INIT(page_info, page_info);
OFFSET_INIT
places.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86_64.c | 24 ++--
elf_info.c | 25 -
elf_info.h |2 -
makedumpfile.c | 82
++---
makedumpfile.h | 49
to set up data needed by the generic code, and late arch-specific
initialization to do stuff that depends on data set by the generic code
(currently only the domain_list).
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/ia64.c| 14 +++---
arch/x86.c | 10 --
arch
With early Xen setup, we can move the initialization of xen_phys_start
to the setup routine. This is cleaner, as we can get rid of ifdef'ed
arch-specific code in makedumpfile.c (which should IMO stay generic).
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86.c |9
the address
of struct domain (with high bits chopped for x86-64).
2. For all Xen versions starting with Xen-3.4, the _domain field can be
computed from struct domain address as:
(addr - DIRECTMAP_VIRT_START) PAGE_SHIFT
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86_64.c
norbert.tr...@ts.fujitsu.com
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/ia64.c| 41 ++---
arch/x86.c | 49 ++---
arch/x86_64.c | 49
Norbert's testing, what else do you
need to accept the changes in upstream?
Regards,
Petr Tesarik
SUSE Linux
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
mailing list about the intended hierarchy of the
various PGC_xxx flags.
Petr Tesarik
SUSE Linux
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
, so I'm going to
address it in a subsequent patch set.
Petr Tesarik
SUSE Linux
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
With early Xen setup, we can move the initialization of xen_phys_start
to the setup routine. This is cleaner, as we can get rid of ifdef'ed
arch-specific code in makedumpfile.c (which should IMO stay generic).
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86.c |9
symbol, and Dom0 physical-machine mapping is
initialized in get_machdep_info (called from initial).
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
--- a/makedumpfile.c
+++ b
the address
of struct domain (with high bits chopped for x86-64).
2. For all Xen versions starting with Xen-3.4, the _domain field can be
computed from struct domain address as:
(addr - DIRECTMAP_VIRT_START) PAGE_SHIFT
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86_64.c
to the inner loop and also makes the logic easier
to follow for all Xen versions.
Signed-off-by: Norbert Trapp norbert.tr...@ts.fujitsu.com
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c | 103 +
makedumpfile.h | 25
to set up data needed by the generic code, and late arch-specific
initialization to do stuff that depends on data set by the generic code
(currently only the domain_list).
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/ia64.c| 14 +++---
arch/x86.c | 10 --
arch
...@ts.fujitsu.com
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5306,10 +5306,7 @@ get_structure_info_xen(void)
{
SIZE_INIT(page_info, page_info);
OFFSET_INIT
places.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/x86_64.c | 24 ++--
elf_info.c | 25 -
elf_info.h |2 -
makedumpfile.c | 82 ++---
makedumpfile.h | 49
norbert.tr...@ts.fujitsu.com
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
arch/ia64.c| 41 ++---
arch/x86.c | 49 ++---
arch/x86_64.c | 49
of
--+--+ all physical memory
0x8400|[4T] Reserved for future use |
0x87ff| |
--+--+-
Signed-off-by: Petr Tesarik ptesa...@suse.cz
, makedumpfile is capable of extracting
dmesg from Xen dump files.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
makedumpfile.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2514,6 +2514,8 @@ initialize_bitmap_memory(void)
return
, except the last one, which reflects that the max_pfn
symbol is not exporte by the SLES kernel.
Petr Tesarik
SUSE Linux
Thank you for your work.
Although I haven't seen almost your patchset yet, does your patchset have
a functional overlap with the patchset Norbert sent ?
http
Dne Po 23. července 2012 22:10:59 Daniel Kiper napsal(a):
Hi Petr,
On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
vmcoreinfo file could exists under
to be consistent with all the other arch-dependent code.
Anyway, my patches seem to cover the remaining architectures, although I have
really only tested x86_64...
Petr Tesarik
SUSE Linux
#if defined(__powerpc64__) || defined(__powerpc32__)
MSG(\n);
MSG(Xen is not supported on powerpc.\n
. See
also my side-by-side comparison of the virtual address space. That reminds me
that I initially wrote that comparison as an HTML table and intended to
publish it in the Xensource wiki...
Petr Tesarik
SUSE Linux
___
kexec mailing list
kexec
errors. Accessing
them may in fact cause an MCE in the secondary kernel, which is not good, so
let's skip them here.
Petr Tesarik
SUSE Linux
+ unknown_page_type++;
+ //clear_bit_on_2nd_bitmap(pfn);
+ pfn
'XEN_VMCOREINFO'). If you
keep only the hypervisor note, then e.g. makedumpfile won't be able to use
dumplevel greater than 1, nor will it be able to extract the log buffer.
Petr Tesarik
SUSE Linux
Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
---
kexec/crashdump-elf.c | 33
Dne Po 23. července 2012 14:56:07 Petr Tesarik napsal(a):
Dne Čt 5. července 2012 14:16:35 Daniel Kiper napsal(a):
vmcoreinfo file could exists under /sys/kernel (valid on baremetal only)
and/or under /sys/hypervisor (valid when Xen dom0 is running).
Read only one of them. It means
segments:
0x600400 - 0x6004ef (LOAD 1)
0x6004f4 - 0x6005d1 (LOAD 3)
0x6023fc - 0x6023fc1000 (elfcorehdr)
Note: The crash kernel is loaded at 0x600400 on this machine.
Signed-off-by: Petr Tesarik ptesa...@suse.cz
---
kexec/arch/ia64/crashdump-ia64.c |8
201 - 281 of 281 matches
Mail list logo
