* [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-05 12:16 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-07-05 12:16 UTC (permalink / raw)
To: konrad.wilk, horms, olaf, kexec, xen-devel
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 that only one PT_NOTE will be
always created. Remove extra code for second PT_NOTE creation.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
kexec/crashdump-elf.c | 33 +++++++--------------------------
1 files changed, 7 insertions(+), 26 deletions(-)
diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
index 8d82db9..ec66548 100644
--- a/kexec/crashdump-elf.c
+++ b/kexec/crashdump-elf.c
@@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
uint64_t notes_addr, notes_len;
uint64_t vmcoreinfo_addr, vmcoreinfo_len;
int has_vmcoreinfo = 0;
- uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
- int has_vmcoreinfo_xen = 0;
int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
if (xen_present())
@@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
return -1;
}
- if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) == 0) {
- has_vmcoreinfo = 1;
- }
-
- if (xen_present() &&
- get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen) == 0) {
- has_vmcoreinfo_xen = 1;
- }
+ if (xen_present()) {
+ if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+ has_vmcoreinfo = 1;
+ } else
+ if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+ has_vmcoreinfo = 1;
- sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) * sizeof(PHDR) +
+ sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) * sizeof(PHDR) +
ranges * sizeof(PHDR);
/*
@@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
dbgprintf_phdr("vmcoreinfo header", phdr);
}
- if (has_vmcoreinfo_xen) {
- phdr = (PHDR *) bufp;
- bufp += sizeof(PHDR);
- phdr->p_type = PT_NOTE;
- phdr->p_flags = 0;
- phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr_xen;
- phdr->p_vaddr = 0;
- phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len_xen;
- /* Do we need any alignment of segments? */
- phdr->p_align = 0;
-
- (elf->e_phnum)++;
- dbgprintf_phdr("vmcoreinfo_xen header", phdr);
- }
-
/* Setup an PT_LOAD type program header for the region where
* Kernel is mapped if elf_info->kern_size is non-zero.
*/
--
1.5.6.5
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-05 12:16 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-07-05 12:16 UTC (permalink / raw)
To: konrad.wilk, horms, olaf, kexec, xen-devel
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 that only one PT_NOTE will be
always created. Remove extra code for second PT_NOTE creation.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
kexec/crashdump-elf.c | 33 +++++++--------------------------
1 files changed, 7 insertions(+), 26 deletions(-)
diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
index 8d82db9..ec66548 100644
--- a/kexec/crashdump-elf.c
+++ b/kexec/crashdump-elf.c
@@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
uint64_t notes_addr, notes_len;
uint64_t vmcoreinfo_addr, vmcoreinfo_len;
int has_vmcoreinfo = 0;
- uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
- int has_vmcoreinfo_xen = 0;
int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
if (xen_present())
@@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
return -1;
}
- if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) == 0) {
- has_vmcoreinfo = 1;
- }
-
- if (xen_present() &&
- get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen) == 0) {
- has_vmcoreinfo_xen = 1;
- }
+ if (xen_present()) {
+ if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+ has_vmcoreinfo = 1;
+ } else
+ if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+ has_vmcoreinfo = 1;
- sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) * sizeof(PHDR) +
+ sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) * sizeof(PHDR) +
ranges * sizeof(PHDR);
/*
@@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
dbgprintf_phdr("vmcoreinfo header", phdr);
}
- if (has_vmcoreinfo_xen) {
- phdr = (PHDR *) bufp;
- bufp += sizeof(PHDR);
- phdr->p_type = PT_NOTE;
- phdr->p_flags = 0;
- phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr_xen;
- phdr->p_vaddr = 0;
- phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len_xen;
- /* Do we need any alignment of segments? */
- phdr->p_align = 0;
-
- (elf->e_phnum)++;
- dbgprintf_phdr("vmcoreinfo_xen header", phdr);
- }
-
/* Setup an PT_LOAD type program header for the region where
* Kernel is mapped if elf_info->kern_size is non-zero.
*/
--
1.5.6.5
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 34+ messages in thread[parent not found: <20120705121635.GA2007-UojuW/CpjwpdUOLzJiIvSsFoITBeLw/klGfBN0aaEZ+lPcVs/6D9LQ@public.gmane.org>]
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-05 12:16 ` Daniel Kiper
@ 2012-07-06 13:49 ` Simon Horman
-1 siblings, 0 replies; 34+ messages in thread
From: Simon Horman @ 2012-07-06 13:49 UTC (permalink / raw)
To: Daniel Kiper
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
On Thu, Jul 05, 2012 at 02:16:35PM +0200, Daniel Kiper wrote:
> 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 that only one PT_NOTE will be
> always created. Remove extra code for second PT_NOTE creation.
>
> Signed-off-by: Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Thanks, applied.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-06 13:49 ` Simon Horman
0 siblings, 0 replies; 34+ messages in thread
From: Simon Horman @ 2012-07-06 13:49 UTC (permalink / raw)
To: Daniel Kiper; +Cc: olaf, xen-devel, kexec, konrad.wilk
On Thu, Jul 05, 2012 at 02:16:35PM +0200, Daniel Kiper wrote:
> 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 that only one PT_NOTE will be
> always created. Remove extra code for second PT_NOTE creation.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Thanks, applied.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-05 12:16 ` Daniel Kiper
@ 2012-07-23 12:56 ` Petr Tesarik
-1 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2012-07-23 12:56 UTC (permalink / raw)
To: kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR, Daniel Kiper,
horms-/R6kz+dDXgpPR4JQBCEnsQ, olaf-QOLJcTWqO2uzQB+pC5nmwQ,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
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 that only one PT_NOTE will be
> always created. Remove extra code for second PT_NOTE creation.
Hi Daniel,
are you absolutely sure this is the right thing to do? IIUC these two
VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
/sys/hypervisor describes the Xen hypervisor (type '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.kiper@oracle.com>
> ---
> kexec/crashdump-elf.c | 33 +++++++--------------------------
> 1 files changed, 7 insertions(+), 26 deletions(-)
>
> diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
> index 8d82db9..ec66548 100644
> --- a/kexec/crashdump-elf.c
> +++ b/kexec/crashdump-elf.c
> @@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
> uint64_t notes_addr, notes_len;
> uint64_t vmcoreinfo_addr, vmcoreinfo_len;
> int has_vmcoreinfo = 0;
> - uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
> - int has_vmcoreinfo_xen = 0;
> int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
>
> if (xen_present())
> @@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
> return -1;
> }
>
> - if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) == 0) {
> - has_vmcoreinfo = 1;
> - }
> -
> - if (xen_present() &&
> - get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen) == 0) {
> - has_vmcoreinfo_xen = 1;
> - }
> + if (xen_present()) {
> + if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> + has_vmcoreinfo = 1;
> + } else
> + if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> + has_vmcoreinfo = 1;
>
> - sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) *
> sizeof(PHDR) + + sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) *
> sizeof(PHDR) +
> ranges * sizeof(PHDR);
>
> /*
> @@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
> dbgprintf_phdr("vmcoreinfo header", phdr);
> }
>
> - if (has_vmcoreinfo_xen) {
> - phdr = (PHDR *) bufp;
> - bufp += sizeof(PHDR);
> - phdr->p_type = PT_NOTE;
> - phdr->p_flags = 0;
> - phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr_xen;
> - phdr->p_vaddr = 0;
> - phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len_xen;
> - /* Do we need any alignment of segments? */
> - phdr->p_align = 0;
> -
> - (elf->e_phnum)++;
> - dbgprintf_phdr("vmcoreinfo_xen header", phdr);
> - }
> -
> /* Setup an PT_LOAD type program header for the region where
> * Kernel is mapped if elf_info->kern_size is non-zero.
> */
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-23 12:56 ` Petr Tesarik
0 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2012-07-23 12:56 UTC (permalink / raw)
To: kexec; +Cc: xen-devel, Daniel Kiper, horms, olaf, konrad.wilk
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 that only one PT_NOTE will be
> always created. Remove extra code for second PT_NOTE creation.
Hi Daniel,
are you absolutely sure this is the right thing to do? IIUC these two
VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
/sys/hypervisor describes the Xen hypervisor (type '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.kiper@oracle.com>
> ---
> kexec/crashdump-elf.c | 33 +++++++--------------------------
> 1 files changed, 7 insertions(+), 26 deletions(-)
>
> diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
> index 8d82db9..ec66548 100644
> --- a/kexec/crashdump-elf.c
> +++ b/kexec/crashdump-elf.c
> @@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
> uint64_t notes_addr, notes_len;
> uint64_t vmcoreinfo_addr, vmcoreinfo_len;
> int has_vmcoreinfo = 0;
> - uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
> - int has_vmcoreinfo_xen = 0;
> int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
>
> if (xen_present())
> @@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
> return -1;
> }
>
> - if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) == 0) {
> - has_vmcoreinfo = 1;
> - }
> -
> - if (xen_present() &&
> - get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen) == 0) {
> - has_vmcoreinfo_xen = 1;
> - }
> + if (xen_present()) {
> + if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> + has_vmcoreinfo = 1;
> + } else
> + if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> + has_vmcoreinfo = 1;
>
> - sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) *
> sizeof(PHDR) + + sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) *
> sizeof(PHDR) +
> ranges * sizeof(PHDR);
>
> /*
> @@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
> dbgprintf_phdr("vmcoreinfo header", phdr);
> }
>
> - if (has_vmcoreinfo_xen) {
> - phdr = (PHDR *) bufp;
> - bufp += sizeof(PHDR);
> - phdr->p_type = PT_NOTE;
> - phdr->p_flags = 0;
> - phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr_xen;
> - phdr->p_vaddr = 0;
> - phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len_xen;
> - /* Do we need any alignment of segments? */
> - phdr->p_align = 0;
> -
> - (elf->e_phnum)++;
> - dbgprintf_phdr("vmcoreinfo_xen header", phdr);
> - }
> -
> /* Setup an PT_LOAD type program header for the region where
> * Kernel is mapped if elf_info->kern_size is non-zero.
> */
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-23 12:56 ` Petr Tesarik
@ 2012-07-23 13:30 ` Petr Tesarik
-1 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2012-07-23 13:30 UTC (permalink / raw)
To: kexec, horms; +Cc: Daniel Kiper, xen-devel, olaf, konrad.wilk
[-- Attachment #1: Type: Text/Plain, Size: 3951 bytes --]
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 that only one PT_NOTE will be
> > always created. Remove extra code for second PT_NOTE creation.
>
> Hi Daniel,
>
> are you absolutely sure this is the right thing to do? IIUC these two
> VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> /sys/hypervisor describes the Xen hypervisor (type '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.
I've just verified this, and I'm confident we have to keep both notes in the
dump file. Simon, please revert Daniel's patch to avoid regressions.
I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
difference. Note that the VMCOREINFO_XEN note is actually too big, because Xen
doesn't bother to maintain the correct note size in the note header, so it
always spans a complete page minus sizeof(Elf64_Nhdr)...
Regards,
Petr Tesarik
> Petr Tesarik
> SUSE Linux
>
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >
> > kexec/crashdump-elf.c | 33 +++++++--------------------------
> > 1 files changed, 7 insertions(+), 26 deletions(-)
> >
> > diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
> > index 8d82db9..ec66548 100644
> > --- a/kexec/crashdump-elf.c
> > +++ b/kexec/crashdump-elf.c
> > @@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
> >
> > uint64_t notes_addr, notes_len;
> > uint64_t vmcoreinfo_addr, vmcoreinfo_len;
> > int has_vmcoreinfo = 0;
> >
> > - uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
> > - int has_vmcoreinfo_xen = 0;
> >
> > int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
> >
> > if (xen_present())
> >
> > @@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
> >
> > return -1;
> >
> > }
> >
> > - if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) == 0) {
> > - has_vmcoreinfo = 1;
> > - }
> > -
> > - if (xen_present() &&
> > - get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen) ==
0)
> > { - has_vmcoreinfo_xen = 1;
> > - }
> > + if (xen_present()) {
> > + if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> > + has_vmcoreinfo = 1;
> > + } else
> > + if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> > + has_vmcoreinfo = 1;
> >
> > - sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen)
*
> > sizeof(PHDR) + + sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) *
> > sizeof(PHDR) +
> >
> > ranges * sizeof(PHDR);
> >
> > /*
> >
> > @@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
> >
> > dbgprintf_phdr("vmcoreinfo header", phdr);
> >
> > }
> >
> > - if (has_vmcoreinfo_xen) {
> > - phdr = (PHDR *) bufp;
> > - bufp += sizeof(PHDR);
> > - phdr->p_type = PT_NOTE;
> > - phdr->p_flags = 0;
> > - phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr_xen;
> > - phdr->p_vaddr = 0;
> > - phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len_xen;
> > - /* Do we need any alignment of segments? */
> > - phdr->p_align = 0;
> > -
> > - (elf->e_phnum)++;
> > - dbgprintf_phdr("vmcoreinfo_xen header", phdr);
> > - }
> > -
> >
> > /* Setup an PT_LOAD type program header for the region where
> >
> > * Kernel is mapped if elf_info->kern_size is non-zero.
> > */
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
[-- Attachment #2: VMCOREINFO_XEN --]
[-- Type: text/plain, Size: 4068 bytes --]
PAGESIZE=4096
SYMBOL(domain_list)=ffff82c48029e0f0
SYMBOL(frame_table)=ffff82c48020d908
SYMBOL(max_page)=ffff82c4802c1a68
SIZE(page_info)=32
SIZE(domain)=5504
OFFSET(page_info.count_info)=8
OFFSET(page_info._domain)=24
OFFSET(domain.domain_id)=0
OFFSET(domain.next_in_list)=96
SYMBOL(dom_xen)=ffff82c4802c1a78
SYMBOL(dom_io)=ffff82c4802c1a80
SYMBOL(pgd_l4)=ffff82c480294000
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
[-- Attachment #3: VMCOREINFO --]
[-- Type: text/plain, Size: 1268 bytes --]
OSRELEASE=3.0.34-0.7-xen
PAGESIZE=4096
SYMBOL(init_uts_ns)=ffffffff806b2fc0
SYMBOL(node_online_map)=ffffffff8070e968
SYMBOL(swapper_pg_dir)=ffffffff80783000
SYMBOL(_stext)=ffffffff80004000
SYMBOL(vmlist)=ffffffff8082ea40
SYMBOL(mem_map)=ffffffff8082e950
SYMBOL(contig_page_data)=ffffffff80700f80
SIZE(page)=56
SIZE(pglist_data)=6912
SIZE(zone)=1664
SIZE(free_area)=88
SIZE(list_head)=16
SIZE(nodemask_t)=8
OFFSET(page.flags)=0
OFFSET(page._count)=8
OFFSET(page.mapping)=24
OFFSET(page.lru)=40
OFFSET(pglist_data.node_zones)=0
OFFSET(pglist_data.nr_zones)=6744
OFFSET(pglist_data.node_mem_map)=6752
OFFSET(pglist_data.node_start_pfn)=6768
OFFSET(pglist_data.node_spanned_pages)=6784
OFFSET(pglist_data.node_id)=6792
OFFSET(zone.free_area)=88
OFFSET(zone.vm_stat)=1304
OFFSET(zone.spanned_pages)=1576
OFFSET(free_area.free_list)=0
OFFSET(list_head.next)=0
OFFSET(list_head.prev)=8
OFFSET(vm_struct.addr)=8
LENGTH(zone.free_area)=11
SYMBOL(log_buf)=ffffffff806b8470
SYMBOL(log_end)=ffffffff80796ac0
SYMBOL(log_buf_len)=ffffffff806b8464
SYMBOL(logged_chars)=ffffffff807d6bc0
LENGTH(free_area.free_list)=5
NUMBER(NR_FREE_PAGES)=0
NUMBER(PG_lru)=6
NUMBER(PG_private)=12
NUMBER(PG_head)=16
NUMBER(PG_swapcache)=18
SYMBOL(init_level4_pgt)=ffffffff80783000
CRASHTIME=1341922380
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-23 13:30 ` Petr Tesarik
0 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2012-07-23 13:30 UTC (permalink / raw)
To: kexec, horms; +Cc: Daniel Kiper, xen-devel, olaf, konrad.wilk
[-- Attachment #1: Type: Text/Plain, Size: 3951 bytes --]
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 that only one PT_NOTE will be
> > always created. Remove extra code for second PT_NOTE creation.
>
> Hi Daniel,
>
> are you absolutely sure this is the right thing to do? IIUC these two
> VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> /sys/hypervisor describes the Xen hypervisor (type '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.
I've just verified this, and I'm confident we have to keep both notes in the
dump file. Simon, please revert Daniel's patch to avoid regressions.
I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
difference. Note that the VMCOREINFO_XEN note is actually too big, because Xen
doesn't bother to maintain the correct note size in the note header, so it
always spans a complete page minus sizeof(Elf64_Nhdr)...
Regards,
Petr Tesarik
> Petr Tesarik
> SUSE Linux
>
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >
> > kexec/crashdump-elf.c | 33 +++++++--------------------------
> > 1 files changed, 7 insertions(+), 26 deletions(-)
> >
> > diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
> > index 8d82db9..ec66548 100644
> > --- a/kexec/crashdump-elf.c
> > +++ b/kexec/crashdump-elf.c
> > @@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
> >
> > uint64_t notes_addr, notes_len;
> > uint64_t vmcoreinfo_addr, vmcoreinfo_len;
> > int has_vmcoreinfo = 0;
> >
> > - uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
> > - int has_vmcoreinfo_xen = 0;
> >
> > int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
> >
> > if (xen_present())
> >
> > @@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
> >
> > return -1;
> >
> > }
> >
> > - if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) == 0) {
> > - has_vmcoreinfo = 1;
> > - }
> > -
> > - if (xen_present() &&
> > - get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen) ==
0)
> > { - has_vmcoreinfo_xen = 1;
> > - }
> > + if (xen_present()) {
> > + if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> > + has_vmcoreinfo = 1;
> > + } else
> > + if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> > + has_vmcoreinfo = 1;
> >
> > - sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen)
*
> > sizeof(PHDR) + + sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) *
> > sizeof(PHDR) +
> >
> > ranges * sizeof(PHDR);
> >
> > /*
> >
> > @@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
> >
> > dbgprintf_phdr("vmcoreinfo header", phdr);
> >
> > }
> >
> > - if (has_vmcoreinfo_xen) {
> > - phdr = (PHDR *) bufp;
> > - bufp += sizeof(PHDR);
> > - phdr->p_type = PT_NOTE;
> > - phdr->p_flags = 0;
> > - phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr_xen;
> > - phdr->p_vaddr = 0;
> > - phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len_xen;
> > - /* Do we need any alignment of segments? */
> > - phdr->p_align = 0;
> > -
> > - (elf->e_phnum)++;
> > - dbgprintf_phdr("vmcoreinfo_xen header", phdr);
> > - }
> > -
> >
> > /* Setup an PT_LOAD type program header for the region where
> >
> > * Kernel is mapped if elf_info->kern_size is non-zero.
> > */
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
[-- Attachment #2: VMCOREINFO_XEN --]
[-- Type: text/plain, Size: 4068 bytes --]
PAGESIZE=4096
SYMBOL(domain_list)=ffff82c48029e0f0
SYMBOL(frame_table)=ffff82c48020d908
SYMBOL(max_page)=ffff82c4802c1a68
SIZE(page_info)=32
SIZE(domain)=5504
OFFSET(page_info.count_info)=8
OFFSET(page_info._domain)=24
OFFSET(domain.domain_id)=0
OFFSET(domain.next_in_list)=96
SYMBOL(dom_xen)=ffff82c4802c1a78
SYMBOL(dom_io)=ffff82c4802c1a80
SYMBOL(pgd_l4)=ffff82c480294000
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
[-- Attachment #3: VMCOREINFO --]
[-- Type: text/plain, Size: 1268 bytes --]
OSRELEASE=3.0.34-0.7-xen
PAGESIZE=4096
SYMBOL(init_uts_ns)=ffffffff806b2fc0
SYMBOL(node_online_map)=ffffffff8070e968
SYMBOL(swapper_pg_dir)=ffffffff80783000
SYMBOL(_stext)=ffffffff80004000
SYMBOL(vmlist)=ffffffff8082ea40
SYMBOL(mem_map)=ffffffff8082e950
SYMBOL(contig_page_data)=ffffffff80700f80
SIZE(page)=56
SIZE(pglist_data)=6912
SIZE(zone)=1664
SIZE(free_area)=88
SIZE(list_head)=16
SIZE(nodemask_t)=8
OFFSET(page.flags)=0
OFFSET(page._count)=8
OFFSET(page.mapping)=24
OFFSET(page.lru)=40
OFFSET(pglist_data.node_zones)=0
OFFSET(pglist_data.nr_zones)=6744
OFFSET(pglist_data.node_mem_map)=6752
OFFSET(pglist_data.node_start_pfn)=6768
OFFSET(pglist_data.node_spanned_pages)=6784
OFFSET(pglist_data.node_id)=6792
OFFSET(zone.free_area)=88
OFFSET(zone.vm_stat)=1304
OFFSET(zone.spanned_pages)=1576
OFFSET(free_area.free_list)=0
OFFSET(list_head.next)=0
OFFSET(list_head.prev)=8
OFFSET(vm_struct.addr)=8
LENGTH(zone.free_area)=11
SYMBOL(log_buf)=ffffffff806b8470
SYMBOL(log_end)=ffffffff80796ac0
SYMBOL(log_buf_len)=ffffffff806b8464
SYMBOL(logged_chars)=ffffffff807d6bc0
LENGTH(free_area.free_list)=5
NUMBER(NR_FREE_PAGES)=0
NUMBER(PG_lru)=6
NUMBER(PG_private)=12
NUMBER(PG_head)=16
NUMBER(PG_swapcache)=18
SYMBOL(init_level4_pgt)=ffffffff80783000
CRASHTIME=1341922380
[-- Attachment #4: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread[parent not found: <201207231530.55871.ptesarik-AlSwsSmVLrQ@public.gmane.org>]
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-23 13:30 ` Petr Tesarik
@ 2012-07-23 20:10 ` Daniel Kiper
-1 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-07-23 20:10 UTC (permalink / raw)
To: Petr Tesarik
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ, horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
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 /sys/kernel (valid on baremetal only)
> > > and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > Read only one of them. It means that only one PT_NOTE will be
> > > always created. Remove extra code for second PT_NOTE creation.
> >
> > Hi Daniel,
> >
> > are you absolutely sure this is the right thing to do? IIUC these two
> > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > /sys/hypervisor describes the Xen hypervisor (type '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.
>
> I've just verified this, and I'm confident we have to keep both notes in the
> dump file. Simon, please revert Daniel's patch to avoid regressions.
>
> I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> difference. Note that the VMCOREINFO_XEN note is actually too big, because Xen
> doesn't bother to maintain the correct note size in the note header, so it
> always spans a complete page minus sizeof(Elf64_Nhdr)...
[...]
The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
physical address. It breaks /proc/vmcore in crash kernel. That is why I proposed
that fix. Additionally, /sys/kernel/vmcoreinfo is not available under Xen Linux
Ver. 2.6.18. However, I did not do any makedumpfile tests. If you discovered any
issues with my patch please drop me more details about your tests (Xen version,
Linux Kernel version, makedumpfile version, command lines, config files, logs,
etc.). I will be more then happy to fix/improve kexec-tools and makedumpfile.
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-23 20:10 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-07-23 20:10 UTC (permalink / raw)
To: Petr Tesarik; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
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 /sys/kernel (valid on baremetal only)
> > > and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > Read only one of them. It means that only one PT_NOTE will be
> > > always created. Remove extra code for second PT_NOTE creation.
> >
> > Hi Daniel,
> >
> > are you absolutely sure this is the right thing to do? IIUC these two
> > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > /sys/hypervisor describes the Xen hypervisor (type '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.
>
> I've just verified this, and I'm confident we have to keep both notes in the
> dump file. Simon, please revert Daniel's patch to avoid regressions.
>
> I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> difference. Note that the VMCOREINFO_XEN note is actually too big, because Xen
> doesn't bother to maintain the correct note size in the note header, so it
> always spans a complete page minus sizeof(Elf64_Nhdr)...
[...]
The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
physical address. It breaks /proc/vmcore in crash kernel. That is why I proposed
that fix. Additionally, /sys/kernel/vmcoreinfo is not available under Xen Linux
Ver. 2.6.18. However, I did not do any makedumpfile tests. If you discovered any
issues with my patch please drop me more details about your tests (Xen version,
Linux Kernel version, makedumpfile version, command lines, config files, logs,
etc.). I will be more then happy to fix/improve kexec-tools and makedumpfile.
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-23 20:10 ` Daniel Kiper
@ 2012-07-24 8:18 ` Petr Tesarik
-1 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2012-07-24 8:18 UTC (permalink / raw)
To: Daniel Kiper; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
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 /sys/kernel (valid on baremetal
> > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > created. Remove extra code for second PT_NOTE creation.
> > >
> > > Hi Daniel,
> > >
> > > are you absolutely sure this is the right thing to do? IIUC these two
> > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > /sys/hypervisor describes the Xen hypervisor (type '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.
> >
> > I've just verified this, and I'm confident we have to keep both notes in
> > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> >
> > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > because Xen doesn't bother to maintain the correct note size in the note
> > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
>
> [...]
>
> The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> physical address. It breaks /proc/vmcore in crash kernel. That is why I
> proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> If you discovered any issues with my patch please drop me more details
> about your tests (Xen version, Linux Kernel version, makedumpfile version,
> command lines, config files, logs, etc.). I will be more then happy to
> fix/improve kexec-tools and makedumpfile.
Hi Daniel,
well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
I tested with the following combinations:
* xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
* xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
* xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
respectively. All of them work just fine and save both ELF notes into the
dump.
What do you mean by "invalid physical address"? I'm getting the correct
physical address under Xen. Obviously, it must be translated to machine
addresses if you need them from the secondary kernel.
Anyway, let me re-install my test system and send all the necessary
information. What kind of log files are you interested in?
Petr Tesarik
SUSE Linux
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-24 8:18 ` Petr Tesarik
0 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2012-07-24 8:18 UTC (permalink / raw)
To: Daniel Kiper; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
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 /sys/kernel (valid on baremetal
> > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > created. Remove extra code for second PT_NOTE creation.
> > >
> > > Hi Daniel,
> > >
> > > are you absolutely sure this is the right thing to do? IIUC these two
> > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > /sys/hypervisor describes the Xen hypervisor (type '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.
> >
> > I've just verified this, and I'm confident we have to keep both notes in
> > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> >
> > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > because Xen doesn't bother to maintain the correct note size in the note
> > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
>
> [...]
>
> The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> physical address. It breaks /proc/vmcore in crash kernel. That is why I
> proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> If you discovered any issues with my patch please drop me more details
> about your tests (Xen version, Linux Kernel version, makedumpfile version,
> command lines, config files, logs, etc.). I will be more then happy to
> fix/improve kexec-tools and makedumpfile.
Hi Daniel,
well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
I tested with the following combinations:
* xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
* xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
* xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
respectively. All of them work just fine and save both ELF notes into the
dump.
What do you mean by "invalid physical address"? I'm getting the correct
physical address under Xen. Obviously, it must be translated to machine
addresses if you need them from the secondary kernel.
Anyway, let me re-install my test system and send all the necessary
information. What kind of log files are you interested in?
Petr Tesarik
SUSE Linux
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <201207241018.35292.ptesarik-AlSwsSmVLrQ@public.gmane.org>]
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-24 8:18 ` Petr Tesarik
@ 2012-07-24 13:54 ` Daniel Kiper
-1 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-07-24 13:54 UTC (permalink / raw)
To: Petr Tesarik
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ, horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> 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 /sys/kernel (valid on baremetal
> > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > created. Remove extra code for second PT_NOTE creation.
> > > >
> > > > Hi Daniel,
> > > >
> > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > >
> > > I've just verified this, and I'm confident we have to keep both notes in
> > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > >
> > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > because Xen doesn't bother to maintain the correct note size in the note
> > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> >
> > [...]
> >
> > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > If you discovered any issues with my patch please drop me more details
> > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > command lines, config files, logs, etc.). I will be more then happy to
> > fix/improve kexec-tools and makedumpfile.
>
> Hi Daniel,
>
> well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
Yep.
> commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> I tested with the following combinations:
>
> * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
>
> These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> respectively. All of them work just fine and save both ELF notes into the
> dump.
Could you test current kexec-tools development version and
latest makedumpfile version on latest SLES version?
> What do you mean by "invalid physical address"? I'm getting the correct
> physical address under Xen. Obviously, it must be translated to machine
> addresses if you need them from the secondary kernel.
Correct vmcoreinfo address should be established by calling
HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
Address exposed by /sys/kernel/vmcoreinfo is calculated in other way.
/sys/hypervisor/vmcoreinfo does it correctly (in older implementations
and in my new upstream implementation which I am going to post shortly).
> Anyway, let me re-install my test system and send all the necessary
> information. What kind of log files are you interested in?
If you spot any error in any logfile which in your opinion
is relevent to our testes please send me it.
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-07-24 13:54 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-07-24 13:54 UTC (permalink / raw)
To: Petr Tesarik; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> 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 /sys/kernel (valid on baremetal
> > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > created. Remove extra code for second PT_NOTE creation.
> > > >
> > > > Hi Daniel,
> > > >
> > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > >
> > > I've just verified this, and I'm confident we have to keep both notes in
> > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > >
> > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > because Xen doesn't bother to maintain the correct note size in the note
> > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> >
> > [...]
> >
> > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > If you discovered any issues with my patch please drop me more details
> > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > command lines, config files, logs, etc.). I will be more then happy to
> > fix/improve kexec-tools and makedumpfile.
>
> Hi Daniel,
>
> well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
Yep.
> commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> I tested with the following combinations:
>
> * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
>
> These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> respectively. All of them work just fine and save both ELF notes into the
> dump.
Could you test current kexec-tools development version and
latest makedumpfile version on latest SLES version?
> What do you mean by "invalid physical address"? I'm getting the correct
> physical address under Xen. Obviously, it must be translated to machine
> addresses if you need them from the secondary kernel.
Correct vmcoreinfo address should be established by calling
HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
Address exposed by /sys/kernel/vmcoreinfo is calculated in other way.
/sys/hypervisor/vmcoreinfo does it correctly (in older implementations
and in my new upstream implementation which I am going to post shortly).
> Anyway, let me re-install my test system and send all the necessary
> information. What kind of log files are you interested in?
If you spot any error in any logfile which in your opinion
is relevent to our testes please send me it.
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <20120724135410.GA2230-UojuW/CpjwpdUOLzJiIvSsFoITBeLw/klGfBN0aaEZ+lPcVs/6D9LQ@public.gmane.org>]
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-24 13:54 ` Daniel Kiper
@ 2012-08-02 3:06 ` Simon Horman
-1 siblings, 0 replies; 34+ messages in thread
From: Simon Horman @ 2012-08-02 3:06 UTC (permalink / raw)
To: Daniel Kiper
Cc: kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
olaf-QOLJcTWqO2uzQB+pC5nmwQ,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR, Petr Tesarik,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
On Tue, Jul 24, 2012 at 03:54:10PM +0200, Daniel Kiper wrote:
> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > 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 /sys/kernel (valid on baremetal
> > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > >
> > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > >
> > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > >
> > > [...]
> > >
> > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > If you discovered any issues with my patch please drop me more details
> > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > command lines, config files, logs, etc.). I will be more then happy to
> > > fix/improve kexec-tools and makedumpfile.
> >
> > Hi Daniel,
> >
> > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
>
> Yep.
>
> > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
>
> Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
>
> > I tested with the following combinations:
> >
> > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> >
> > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > respectively. All of them work just fine and save both ELF notes into the
> > dump.
>
> Could you test current kexec-tools development version and
> latest makedumpfile version on latest SLES version?
>
> > What do you mean by "invalid physical address"? I'm getting the correct
> > physical address under Xen. Obviously, it must be translated to machine
> > addresses if you need them from the secondary kernel.
>
> Correct vmcoreinfo address should be established by calling
> HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
> Address exposed by /sys/kernel/vmcoreinfo is calculated in other way.
> /sys/hypervisor/vmcoreinfo does it correctly (in older implementations
> and in my new upstream implementation which I am going to post shortly).
>
> > Anyway, let me re-install my test system and send all the necessary
> > information. What kind of log files are you interested in?
>
> If you spot any error in any logfile which in your opinion
> is relevent to our testes please send me it.
Hi,
is there any consensus on what to do here?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-08-02 3:06 ` Simon Horman
0 siblings, 0 replies; 34+ messages in thread
From: Simon Horman @ 2012-08-02 3:06 UTC (permalink / raw)
To: Daniel Kiper; +Cc: kexec, olaf, xen-devel, Petr Tesarik, konrad.wilk
On Tue, Jul 24, 2012 at 03:54:10PM +0200, Daniel Kiper wrote:
> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > 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 /sys/kernel (valid on baremetal
> > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > >
> > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > >
> > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > >
> > > [...]
> > >
> > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > If you discovered any issues with my patch please drop me more details
> > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > command lines, config files, logs, etc.). I will be more then happy to
> > > fix/improve kexec-tools and makedumpfile.
> >
> > Hi Daniel,
> >
> > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
>
> Yep.
>
> > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
>
> Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
>
> > I tested with the following combinations:
> >
> > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> >
> > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > respectively. All of them work just fine and save both ELF notes into the
> > dump.
>
> Could you test current kexec-tools development version and
> latest makedumpfile version on latest SLES version?
>
> > What do you mean by "invalid physical address"? I'm getting the correct
> > physical address under Xen. Obviously, it must be translated to machine
> > addresses if you need them from the secondary kernel.
>
> Correct vmcoreinfo address should be established by calling
> HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
> Address exposed by /sys/kernel/vmcoreinfo is calculated in other way.
> /sys/hypervisor/vmcoreinfo does it correctly (in older implementations
> and in my new upstream implementation which I am going to post shortly).
>
> > Anyway, let me re-install my test system and send all the necessary
> > information. What kind of log files are you interested in?
>
> If you spot any error in any logfile which in your opinion
> is relevent to our testes please send me it.
Hi,
is there any consensus on what to do here?
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-07-24 13:54 ` Daniel Kiper
@ 2014-11-13 15:51 ` Petr Tesarik
-1 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2014-11-13 15:51 UTC (permalink / raw)
To: Daniel Kiper
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ, horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
Hi all,
this thread got somehow forgotten because of vacations...
Anyway, read below.
On Tue, 24 Jul 2012 15:54:10 +0200
Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > 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 /sys/kernel (valid on baremetal
> > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > >
> > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > >
> > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > >
> > > [...]
> > >
> > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > If you discovered any issues with my patch please drop me more details
> > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > command lines, config files, logs, etc.). I will be more then happy to
> > > fix/improve kexec-tools and makedumpfile.
> >
> > Hi Daniel,
> >
> > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
>
> Yep.
>
> > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
>
> Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
>
> > I tested with the following combinations:
> >
> > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> >
> > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > respectively. All of them work just fine and save both ELF notes into the
> > dump.
>
> Could you test current kexec-tools development version and
> latest makedumpfile version on latest SLES version?
And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
kexec-tools 2.0.5, makedumpfile 1.5.6).
In the secondary kernel, makedumpfile complains that VMCOREINFO is not
stored in /proc/vmcore:
bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
Switched running mode from cyclic to non-cyclic,
because the cyclic mode doesn't support Xen.
/proc/vmcore doesn't contain vmcoreinfo.
Specify '-x' option or '-i' option.
Commandline parameter is invalid.
Try `makedumpfile --help' for more information.
makedumpfile Failed.
Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
everything works just fine.
> > What do you mean by "invalid physical address"? I'm getting the correct
> > physical address under Xen. Obviously, it must be translated to machine
> > addresses if you need them from the secondary kernel.
>
> Correct vmcoreinfo address should be established by calling
> HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
The addresses I get from /sys/kernel/vmcoreinfo and
from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
when a non-Xen kernel is used for dumping, everything works as expected.
I am well aware that the Xen implementation in SLES differs
substantially from mainline, but it seems to me that:
1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
filtering, and
2. both sysfs files should report machine addresses, because the current
p2m mapping is lost forever when the hypervisor executes the secondary
kernel, so physical addresses are pretty useless.
I'm reverting the patch for the SLES distro, but I'd like to reach some
kind of consensus with the community, too.
Petr T
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2014-11-13 15:51 ` Petr Tesarik
0 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2014-11-13 15:51 UTC (permalink / raw)
To: Daniel Kiper; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
Hi all,
this thread got somehow forgotten because of vacations...
Anyway, read below.
On Tue, 24 Jul 2012 15:54:10 +0200
Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > 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 /sys/kernel (valid on baremetal
> > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > >
> > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > >
> > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > >
> > > [...]
> > >
> > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > If you discovered any issues with my patch please drop me more details
> > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > command lines, config files, logs, etc.). I will be more then happy to
> > > fix/improve kexec-tools and makedumpfile.
> >
> > Hi Daniel,
> >
> > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
>
> Yep.
>
> > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
>
> Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
>
> > I tested with the following combinations:
> >
> > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> >
> > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > respectively. All of them work just fine and save both ELF notes into the
> > dump.
>
> Could you test current kexec-tools development version and
> latest makedumpfile version on latest SLES version?
And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
kexec-tools 2.0.5, makedumpfile 1.5.6).
In the secondary kernel, makedumpfile complains that VMCOREINFO is not
stored in /proc/vmcore:
bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
Switched running mode from cyclic to non-cyclic,
because the cyclic mode doesn't support Xen.
/proc/vmcore doesn't contain vmcoreinfo.
Specify '-x' option or '-i' option.
Commandline parameter is invalid.
Try `makedumpfile --help' for more information.
makedumpfile Failed.
Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
everything works just fine.
> > What do you mean by "invalid physical address"? I'm getting the correct
> > physical address under Xen. Obviously, it must be translated to machine
> > addresses if you need them from the secondary kernel.
>
> Correct vmcoreinfo address should be established by calling
> HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
The addresses I get from /sys/kernel/vmcoreinfo and
from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
when a non-Xen kernel is used for dumping, everything works as expected.
I am well aware that the Xen implementation in SLES differs
substantially from mainline, but it seems to me that:
1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
filtering, and
2. both sysfs files should report machine addresses, because the current
p2m mapping is lost forever when the hypervisor executes the secondary
kernel, so physical addresses are pretty useless.
I'm reverting the patch for the SLES distro, but I'd like to reach some
kind of consensus with the community, too.
Petr T
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread[parent not found: <20141113165148.4343b45e-7L324ngwNA8VI8jrpt9EEQ@public.gmane.org>]
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2014-11-13 15:51 ` Petr Tesarik
@ 2014-11-13 17:22 ` Daniel Kiper
-1 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2014-11-13 17:22 UTC (permalink / raw)
To: Petr Tesarik
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ, horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
Hi Petr,
On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> Hi all,
>
> this thread got somehow forgotten because of vacations...
> Anyway, read below.
>
> On Tue, 24 Jul 2012 15:54:10 +0200
> Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>
> > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > 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 /sys/kernel (valid on baremetal
> > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > >
> > > > > > Hi Daniel,
> > > > > >
> > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > > >
> > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > >
> > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > >
> > > > [...]
> > > >
> > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > If you discovered any issues with my patch please drop me more details
> > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > fix/improve kexec-tools and makedumpfile.
> > >
> > > Hi Daniel,
> > >
> > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> >
> > Yep.
> >
> > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> >
> > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> >
> > > I tested with the following combinations:
> > >
> > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > >
> > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > respectively. All of them work just fine and save both ELF notes into the
> > > dump.
> >
> > Could you test current kexec-tools development version and
> > latest makedumpfile version on latest SLES version?
>
> And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> kexec-tools 2.0.5, makedumpfile 1.5.6).
>
> In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> stored in /proc/vmcore:
>
> bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> Switched running mode from cyclic to non-cyclic,
> because the cyclic mode doesn't support Xen.
> /proc/vmcore doesn't contain vmcoreinfo.
> Specify '-x' option or '-i' option.
> Commandline parameter is invalid.
> Try `makedumpfile --help' for more information.
>
> makedumpfile Failed.
>
> Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> everything works just fine.
>
> > > What do you mean by "invalid physical address"? I'm getting the correct
> > > physical address under Xen. Obviously, it must be translated to machine
> > > addresses if you need them from the secondary kernel.
> >
> > Correct vmcoreinfo address should be established by calling
> > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
>
> The addresses I get from /sys/kernel/vmcoreinfo and
> from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> when a non-Xen kernel is used for dumping, everything works as expected.
>
> I am well aware that the Xen implementation in SLES differs
> substantially from mainline, but it seems to me that:
>
> 1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
> filtering, and
> 2. both sysfs files should report machine addresses, because the current
> p2m mapping is lost forever when the hypervisor executes the secondary
> kernel, so physical addresses are pretty useless.
>
> I'm reverting the patch for the SLES distro, but I'd like to reach some
> kind of consensus with the community, too.
This reminds me something. I saw that kind of thing when I was working on
makedumpfile once. I have this issue on my TODO list. However, currently
I am working on EFI and multiboot2 stuff and I am not able to take a
look at it. I will do that after releasing first version of patches.
Probably in the middle of December. Is it OK for you?
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2014-11-13 17:22 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2014-11-13 17:22 UTC (permalink / raw)
To: Petr Tesarik; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
Hi Petr,
On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> Hi all,
>
> this thread got somehow forgotten because of vacations...
> Anyway, read below.
>
> On Tue, 24 Jul 2012 15:54:10 +0200
> Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > 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 /sys/kernel (valid on baremetal
> > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > >
> > > > > > Hi Daniel,
> > > > > >
> > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > > >
> > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > >
> > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > >
> > > > [...]
> > > >
> > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > If you discovered any issues with my patch please drop me more details
> > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > fix/improve kexec-tools and makedumpfile.
> > >
> > > Hi Daniel,
> > >
> > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> >
> > Yep.
> >
> > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> >
> > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> >
> > > I tested with the following combinations:
> > >
> > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > >
> > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > respectively. All of them work just fine and save both ELF notes into the
> > > dump.
> >
> > Could you test current kexec-tools development version and
> > latest makedumpfile version on latest SLES version?
>
> And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> kexec-tools 2.0.5, makedumpfile 1.5.6).
>
> In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> stored in /proc/vmcore:
>
> bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> Switched running mode from cyclic to non-cyclic,
> because the cyclic mode doesn't support Xen.
> /proc/vmcore doesn't contain vmcoreinfo.
> Specify '-x' option or '-i' option.
> Commandline parameter is invalid.
> Try `makedumpfile --help' for more information.
>
> makedumpfile Failed.
>
> Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> everything works just fine.
>
> > > What do you mean by "invalid physical address"? I'm getting the correct
> > > physical address under Xen. Obviously, it must be translated to machine
> > > addresses if you need them from the secondary kernel.
> >
> > Correct vmcoreinfo address should be established by calling
> > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
>
> The addresses I get from /sys/kernel/vmcoreinfo and
> from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> when a non-Xen kernel is used for dumping, everything works as expected.
>
> I am well aware that the Xen implementation in SLES differs
> substantially from mainline, but it seems to me that:
>
> 1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
> filtering, and
> 2. both sysfs files should report machine addresses, because the current
> p2m mapping is lost forever when the hypervisor executes the secondary
> kernel, so physical addresses are pretty useless.
>
> I'm reverting the patch for the SLES distro, but I'd like to reach some
> kind of consensus with the community, too.
This reminds me something. I saw that kind of thing when I was working on
makedumpfile once. I have this issue on my TODO list. However, currently
I am working on EFI and multiboot2 stuff and I am not able to take a
look at it. I will do that after releasing first version of patches.
Probably in the middle of December. Is it OK for you?
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <20141113172217.GD6522-fJNZiO034lp9pOct4yEdx/3oZC3j2Omk@public.gmane.org>]
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2014-11-13 17:22 ` Daniel Kiper
@ 2014-11-13 18:14 ` Petr Tesarik
-1 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2014-11-13 18:14 UTC (permalink / raw)
To: Daniel Kiper
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ, horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
On Thu, 13 Nov 2014 18:22:17 +0100
Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> Hi Petr,
>
> On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> > Hi all,
> >
> > this thread got somehow forgotten because of vacations...
> > Anyway, read below.
> >
> > On Tue, 24 Jul 2012 15:54:10 +0200
> > Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > > 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 /sys/kernel (valid on baremetal
> > > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > > >
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > > > >
> > > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > > >
> > > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > > >
> > > > > [...]
> > > > >
> > > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > > If you discovered any issues with my patch please drop me more details
> > > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > > fix/improve kexec-tools and makedumpfile.
> > > >
> > > > Hi Daniel,
> > > >
> > > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> > >
> > > Yep.
> > >
> > > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> > >
> > > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> > >
> > > > I tested with the following combinations:
> > > >
> > > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > > >
> > > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > > respectively. All of them work just fine and save both ELF notes into the
> > > > dump.
> > >
> > > Could you test current kexec-tools development version and
> > > latest makedumpfile version on latest SLES version?
> >
> > And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> > kexec-tools 2.0.5, makedumpfile 1.5.6).
> >
> > In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> > stored in /proc/vmcore:
> >
> > bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> > Switched running mode from cyclic to non-cyclic,
> > because the cyclic mode doesn't support Xen.
> > /proc/vmcore doesn't contain vmcoreinfo.
> > Specify '-x' option or '-i' option.
> > Commandline parameter is invalid.
> > Try `makedumpfile --help' for more information.
> >
> > makedumpfile Failed.
> >
> > Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> > everything works just fine.
> >
> > > > What do you mean by "invalid physical address"? I'm getting the correct
> > > > physical address under Xen. Obviously, it must be translated to machine
> > > > addresses if you need them from the secondary kernel.
> > >
> > > Correct vmcoreinfo address should be established by calling
> > > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
> >
> > The addresses I get from /sys/kernel/vmcoreinfo and
> > from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> > when a non-Xen kernel is used for dumping, everything works as expected.
> >
> > I am well aware that the Xen implementation in SLES differs
> > substantially from mainline, but it seems to me that:
> >
> > 1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
> > filtering, and
> > 2. both sysfs files should report machine addresses, because the current
> > p2m mapping is lost forever when the hypervisor executes the secondary
> > kernel, so physical addresses are pretty useless.
> >
> > I'm reverting the patch for the SLES distro, but I'd like to reach some
> > kind of consensus with the community, too.
>
> This reminds me something. I saw that kind of thing when I was working on
> makedumpfile once. I have this issue on my TODO list. However, currently
> I am working on EFI and multiboot2 stuff and I am not able to take a
> look at it. I will do that after releasing first version of patches.
> Probably in the middle of December. Is it OK for you?
Since this issue has waited two years now, I think it can also wait
another month or two. ;-)
Thanks,
Petr T
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2014-11-13 18:14 ` Petr Tesarik
0 siblings, 0 replies; 34+ messages in thread
From: Petr Tesarik @ 2014-11-13 18:14 UTC (permalink / raw)
To: Daniel Kiper; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
On Thu, 13 Nov 2014 18:22:17 +0100
Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Hi Petr,
>
> On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> > Hi all,
> >
> > this thread got somehow forgotten because of vacations...
> > Anyway, read below.
> >
> > On Tue, 24 Jul 2012 15:54:10 +0200
> > Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > > > 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 /sys/kernel (valid on baremetal
> > > > > > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > > > > > > Read only one of them. It means that only one PT_NOTE will be always
> > > > > > > > created. Remove extra code for second PT_NOTE creation.
> > > > > > >
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > are you absolutely sure this is the right thing to do? IIUC these two
> > > > > > > VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> > > > > > > describes the Dom0 kernel (type 'VMCOREINFO'), while the one from
> > > > > > > /sys/hypervisor describes the Xen hypervisor (type '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.
> > > > > >
> > > > > > I've just verified this, and I'm confident we have to keep both notes in
> > > > > > the dump file. Simon, please revert Daniel's patch to avoid regressions.
> > > > > >
> > > > > > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
> > > > > > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > > > > > because Xen doesn't bother to maintain the correct note size in the note
> > > > > > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> > > > >
> > > > > [...]
> > > > >
> > > > > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> > > > > physical address. It breaks /proc/vmcore in crash kernel. That is why I
> > > > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> > > > > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> > > > > If you discovered any issues with my patch please drop me more details
> > > > > about your tests (Xen version, Linux Kernel version, makedumpfile version,
> > > > > command lines, config files, logs, etc.). I will be more then happy to
> > > > > fix/improve kexec-tools and makedumpfile.
> > > >
> > > > Hi Daniel,
> > > >
> > > > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the
> > > > VMCOREINFO infrastructure was not present in 2.6.18. It was added later with
> > >
> > > Yep.
> > >
> > > > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
> > >
> > > Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> > >
> > > > I tested with the following combinations:
> > > >
> > > > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> > > > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
> > > >
> > > > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > > > respectively. All of them work just fine and save both ELF notes into the
> > > > dump.
> > >
> > > Could you test current kexec-tools development version and
> > > latest makedumpfile version on latest SLES version?
> >
> > And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28,
> > kexec-tools 2.0.5, makedumpfile 1.5.6).
> >
> > In the secondary kernel, makedumpfile complains that VMCOREINFO is not
> > stored in /proc/vmcore:
> >
> > bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf
> > Switched running mode from cyclic to non-cyclic,
> > because the cyclic mode doesn't support Xen.
> > /proc/vmcore doesn't contain vmcoreinfo.
> > Specify '-x' option or '-i' option.
> > Commandline parameter is invalid.
> > Try `makedumpfile --help' for more information.
> >
> > makedumpfile Failed.
> >
> > Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and
> > everything works just fine.
> >
> > > > What do you mean by "invalid physical address"? I'm getting the correct
> > > > physical address under Xen. Obviously, it must be translated to machine
> > > > addresses if you need them from the secondary kernel.
> > >
> > > Correct vmcoreinfo address should be established by calling
> > > HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
> >
> > The addresses I get from /sys/kernel/vmcoreinfo and
> > from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so
> > when a non-Xen kernel is used for dumping, everything works as expected.
> >
> > I am well aware that the Xen implementation in SLES differs
> > substantially from mainline, but it seems to me that:
> >
> > 1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile
> > filtering, and
> > 2. both sysfs files should report machine addresses, because the current
> > p2m mapping is lost forever when the hypervisor executes the secondary
> > kernel, so physical addresses are pretty useless.
> >
> > I'm reverting the patch for the SLES distro, but I'd like to reach some
> > kind of consensus with the community, too.
>
> This reminds me something. I saw that kind of thing when I was working on
> makedumpfile once. I have this issue on my TODO list. However, currently
> I am working on EFI and multiboot2 stuff and I am not able to take a
> look at it. I will do that after releasing first version of patches.
> Probably in the middle of December. Is it OK for you?
Since this issue has waited two years now, I think it can also wait
another month or two. ;-)
Thanks,
Petr T
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2014-11-13 15:51 ` Petr Tesarik
@ 2014-12-19 20:21 ` Daniel Kiper
-1 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2014-12-19 20:21 UTC (permalink / raw)
To: Petr Tesarik
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ, horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
Hi Petr,
On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> Hi all,
>
> this thread got somehow forgotten because of vacations...
> Anyway, read below.
[...]
Due to delays in EFI + GRUB2 + Xen project I must postpone
work on this a bit longer than I expected. I will check
what is going on immediately after releasing first version
of patches for above mentioned project. It looks that it
will happen at the beginning of next year.
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2014-12-19 20:21 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2014-12-19 20:21 UTC (permalink / raw)
To: Petr Tesarik; +Cc: olaf, horms, kexec, xen-devel, konrad.wilk
Hi Petr,
On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote:
> Hi all,
>
> this thread got somehow forgotten because of vacations...
> Anyway, read below.
[...]
Due to delays in EFI + GRUB2 + Xen project I must postpone
work on this a bit longer than I expected. I will check
what is going on immediately after releasing first version
of patches for above mentioned project. It looks that it
will happen at the beginning of next year.
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-08-02 13:18 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-08-02 13:18 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ
Cc: ptesarik-AlSwsSmVLrQ, olaf-QOLJcTWqO2uzQB+pC5nmwQ,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
Hi Simon,
[...]
> > If you spot any error in any logfile which in your opinion
> > is relevent to our testes please send me it.
>
> Hi,
>
> is there any consensus on what to do here?
As I know Petr was going to do some tests.
I have not received any reply from him till now.
Maybe he is busy or on vacation.
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-08-02 13:27 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-08-02 13:27 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ
Cc: ptesarik-AlSwsSmVLrQ, olaf-QOLJcTWqO2uzQB+pC5nmwQ,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
Hi,
> > > If you spot any error in any logfile which in your opinion
> > > is relevent to our testes please send me it.
> >
> > Hi,
> >
> > is there any consensus on what to do here?
>
> As I know Petr was going to do some tests.
> I have not received any reply from him till now.
> Maybe he is busy or on vacation.
According to automatic reply he is on vacation until 13/08/2012.
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-08-02 13:27 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-08-02 13:27 UTC (permalink / raw)
To: horms; +Cc: ptesarik, olaf, xen-devel, kexec, konrad.wilk
Hi,
> > > If you spot any error in any logfile which in your opinion
> > > is relevent to our testes please send me it.
> >
> > Hi,
> >
> > is there any consensus on what to do here?
>
> As I know Petr was going to do some tests.
> I have not received any reply from him till now.
> Maybe he is busy or on vacation.
According to automatic reply he is on vacation until 13/08/2012.
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
2012-08-02 13:27 ` Daniel Kiper
@ 2012-08-06 8:27 ` Simon Horman
-1 siblings, 0 replies; 34+ messages in thread
From: Simon Horman @ 2012-08-06 8:27 UTC (permalink / raw)
To: Daniel Kiper
Cc: kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
olaf-QOLJcTWqO2uzQB+pC5nmwQ,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR, ptesarik-AlSwsSmVLrQ,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
On Thu, Aug 02, 2012 at 06:27:24AM -0700, Daniel Kiper wrote:
> Hi,
>
> > > > If you spot any error in any logfile which in your opinion
> > > > is relevent to our testes please send me it.
> > >
> > > Hi,
> > >
> > > is there any consensus on what to do here?
> >
> > As I know Petr was going to do some tests.
> > I have not received any reply from him till now.
> > Maybe he is busy or on vacation.
>
> According to automatic reply he is on vacation until 13/08/2012.
Thanks. I guess we should wait then.
Incidently, I will be on vacation for a week from the 13th.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-08-06 8:27 ` Simon Horman
0 siblings, 0 replies; 34+ messages in thread
From: Simon Horman @ 2012-08-06 8:27 UTC (permalink / raw)
To: Daniel Kiper; +Cc: kexec, olaf, xen-devel, ptesarik, konrad.wilk
On Thu, Aug 02, 2012 at 06:27:24AM -0700, Daniel Kiper wrote:
> Hi,
>
> > > > If you spot any error in any logfile which in your opinion
> > > > is relevent to our testes please send me it.
> > >
> > > Hi,
> > >
> > > is there any consensus on what to do here?
> >
> > As I know Petr was going to do some tests.
> > I have not received any reply from him till now.
> > Maybe he is busy or on vacation.
>
> According to automatic reply he is on vacation until 13/08/2012.
Thanks. I guess we should wait then.
Incidently, I will be on vacation for a week from the 13th.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-08-06 9:32 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-08-06 9:32 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ
Cc: ptesarik-AlSwsSmVLrQ, olaf-QOLJcTWqO2uzQB+pC5nmwQ,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
Hi,
[...]
> > > As I know Petr was going to do some tests.
> > > I have not received any reply from him till now.
> > > Maybe he is busy or on vacation.
> >
> > According to automatic reply he is on vacation until 13/08/2012.
>
> Thanks. I guess we should wait then.
>
> Incidently, I will be on vacation for a week from the 13th.
I am too but for three weeks. However, I will be reading
email from time to time.
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-08-06 9:32 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-08-06 9:32 UTC (permalink / raw)
To: horms; +Cc: ptesarik, olaf, xen-devel, kexec, konrad.wilk
Hi,
[...]
> > > As I know Petr was going to do some tests.
> > > I have not received any reply from him till now.
> > > Maybe he is busy or on vacation.
> >
> > According to automatic reply he is on vacation until 13/08/2012.
>
> Thanks. I guess we should wait then.
>
> Incidently, I will be on vacation for a week from the 13th.
I am too but for three weeks. However, I will be reading
email from time to time.
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-09-10 12:06 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-09-10 12:06 UTC (permalink / raw)
To: ptesarik-AlSwsSmVLrQ
Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
horms-/R6kz+dDXgpPR4JQBCEnsQ, konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA
Hi Petr,
[...]
> > > As I know Petr was going to do some tests.
> > > I have not received any reply from him till now.
> > > Maybe he is busy or on vacation.
> >
> > According to automatic reply he is on vacation until 13/08/2012.
>
> Thanks. I guess we should wait then.
Have you done some tests of this patch?
Did you find any issues with it?
Daniel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] kexec-tools: Read always one vmcoreinfo file
@ 2012-09-10 12:06 ` Daniel Kiper
0 siblings, 0 replies; 34+ messages in thread
From: Daniel Kiper @ 2012-09-10 12:06 UTC (permalink / raw)
To: ptesarik; +Cc: olaf, xen-devel, kexec, horms, konrad.wilk
Hi Petr,
[...]
> > > As I know Petr was going to do some tests.
> > > I have not received any reply from him till now.
> > > Maybe he is busy or on vacation.
> >
> > According to automatic reply he is on vacation until 13/08/2012.
>
> Thanks. I guess we should wait then.
Have you done some tests of this patch?
Did you find any issues with it?
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2014-12-19 20:22 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-05 12:16 [PATCH] kexec-tools: Read always one vmcoreinfo file Daniel Kiper
2012-07-05 12:16 ` Daniel Kiper
[not found] ` <20120705121635.GA2007-UojuW/CpjwpdUOLzJiIvSsFoITBeLw/klGfBN0aaEZ+lPcVs/6D9LQ@public.gmane.org>
2012-07-06 13:49 ` Simon Horman
2012-07-06 13:49 ` Simon Horman
2012-07-23 12:56 ` Petr Tesarik
2012-07-23 12:56 ` Petr Tesarik
2012-07-23 13:30 ` Petr Tesarik
2012-07-23 13:30 ` Petr Tesarik
[not found] ` <201207231530.55871.ptesarik-AlSwsSmVLrQ@public.gmane.org>
2012-07-23 20:10 ` Daniel Kiper
2012-07-23 20:10 ` Daniel Kiper
2012-07-24 8:18 ` Petr Tesarik
2012-07-24 8:18 ` Petr Tesarik
[not found] ` <201207241018.35292.ptesarik-AlSwsSmVLrQ@public.gmane.org>
2012-07-24 13:54 ` Daniel Kiper
2012-07-24 13:54 ` Daniel Kiper
[not found] ` <20120724135410.GA2230-UojuW/CpjwpdUOLzJiIvSsFoITBeLw/klGfBN0aaEZ+lPcVs/6D9LQ@public.gmane.org>
2012-08-02 3:06 ` Simon Horman
2012-08-02 3:06 ` Simon Horman
2014-11-13 15:51 ` Petr Tesarik
2014-11-13 15:51 ` Petr Tesarik
[not found] ` <20141113165148.4343b45e-7L324ngwNA8VI8jrpt9EEQ@public.gmane.org>
2014-11-13 17:22 ` Daniel Kiper
2014-11-13 17:22 ` Daniel Kiper
[not found] ` <20141113172217.GD6522-fJNZiO034lp9pOct4yEdx/3oZC3j2Omk@public.gmane.org>
2014-11-13 18:14 ` Petr Tesarik
2014-11-13 18:14 ` Petr Tesarik
2014-12-19 20:21 ` Daniel Kiper
2014-12-19 20:21 ` Daniel Kiper
2012-08-02 13:18 Daniel Kiper
2012-08-02 13:18 ` Daniel Kiper
2012-08-02 13:27 Daniel Kiper
2012-08-02 13:27 ` Daniel Kiper
2012-08-06 8:27 ` Simon Horman
2012-08-06 8:27 ` Simon Horman
2012-08-06 9:32 Daniel Kiper
2012-08-06 9:32 ` Daniel Kiper
2012-09-10 12:06 Daniel Kiper
2012-09-10 12:06 ` Daniel Kiper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.