1:46 a.m.
Hi,
I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from the
vmcore with
# crash --osrelease vmcore
unknown
The problem is that there are two notes in the vmcore starting with
"VMCOREINFO":
Elf64_Nhdr:
n_namesz: 11 ("VMCOREINFO")
n_descsz: 1384
n_type: 0 (unused)
OSRELEASE=3.0.101-63-xen
...
Elf64_Nhdr:
n_namesz: 15 ("VMCOREINFO_XEN")
n_descsz: 4068
n_type: 0 (unused)
...
In the function dump_Elf64_Nhdr() I found:
vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
But because the "VMCOREINFO_XEN" ist the second one in the file it wins!
When using
vmcoreinfo = STREQ(buf, "VMCOREINFO");
all is fine and I get:
# crash --osrelease vmcore
3.0.101-63-xen
So my question is: why is STRNEQ() used?
Thanks!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
8:07 a.m.
New subject: Unknown osrelease information in vmcore with xen
----- Original Message -----
Hi,
I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from the vmcore
with
# crash --osrelease vmcore
unknown
The problem is that there are two notes in the vmcore starting with
"VMCOREINFO":
Elf64_Nhdr:
n_namesz: 11 ("VMCOREINFO")
n_descsz: 1384
n_type: 0 (unused)
OSRELEASE=3.0.101-63-xen
...
Elf64_Nhdr:
n_namesz: 15 ("VMCOREINFO_XEN")
n_descsz: 4068
n_type: 0 (unused)
...
In the function dump_Elf64_Nhdr() I found:
vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
But because the "VMCOREINFO_XEN" ist the second one in the file it wins!
When using
vmcoreinfo = STREQ(buf, "VMCOREINFO");
all is fine and I get:
# crash --osrelease vmcore
3.0.101-63-xen
So my question is: why is STRNEQ() used?
Thanks!
Hello Dietmar,
As I recall, I did all of the note name checks that way because the length
of the name string is specified by the note->n_namesz field, and therefore
not necessarily guaranteed to be a NULL-terminated string? In reality,
they're probably will be a NULL there though.
Anyway, I wasn't even familiar with the existence of a VMCOREINFO_XEN note,
so please feel free to post a patch to address it.
Dave
8:29 a.m.
New subject: Unknown osrelease information in vmcore with xen
----- Original Message -----
----- Original Message -----
> Hi,
>
> I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from
> the vmcore with
> # crash --osrelease vmcore
> unknown
>
> The problem is that there are two notes in the vmcore starting with
> "VMCOREINFO":
>
> Elf64_Nhdr:
> n_namesz: 11 ("VMCOREINFO")
> n_descsz: 1384
> n_type: 0 (unused)
> OSRELEASE=3.0.101-63-xen
> ...
> Elf64_Nhdr:
> n_namesz: 15 ("VMCOREINFO_XEN")
> n_descsz: 4068
> n_type: 0 (unused)
> ...
>
> In the function dump_Elf64_Nhdr() I found:
> vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
>
> But because the "VMCOREINFO_XEN" ist the second one in the file it wins!
>
> When using
> vmcoreinfo = STREQ(buf, "VMCOREINFO");
> all is fine and I get:
> # crash --osrelease vmcore
> 3.0.101-63-xen
>
> So my question is: why is STRNEQ() used?
> Thanks!
Hello Dietmar,
As I recall, I did all of the note name checks that way because the length
of the name string is specified by the note->n_namesz field, and therefore
not necessarily guaranteed to be a NULL-terminated string? In reality,
they're probably will be a NULL there though.
Anyway, I wasn't even familiar with the existence of a VMCOREINFO_XEN note,
so please feel free to post a patch to address it.
Dave
This should work, right?:
--- crash-7.1.3/netdump.c.orig
+++ crash-7.1.3/netdump.c
@@ -1940,7 +1940,8 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st
#endif
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
- vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
+ if (!STRNEQ(buf, "VMCOREINFO_XEN"))
+ vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
eraseinfo = STRNEQ(buf, "ERASEINFO");
qemuinfo = STRNEQ(buf, "QEMU");
if (xen_core) {
@@ -2196,7 +2197,8 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st
#endif
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
- vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
+ if (!STRNEQ(buf, "VMCOREINFO_XEN"))
+ vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
eraseinfo = STRNEQ(buf, "ERASEINFO");
qemuinfo = STRNEQ(buf, "QEMU");
if (xen_core) {
Dave
1:35 p.m.
New subject: Unknown osrelease information in vmcore with xen
----- Original Message -----
----- Original Message -----
>
>
> ----- Original Message -----
> > Hi,
> >
> > I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from
> > the vmcore with
> > # crash --osrelease vmcore
> > unknown
> >
> > The problem is that there are two notes in the vmcore starting with
> > "VMCOREINFO":
> >
> > Elf64_Nhdr:
> > n_namesz: 11 ("VMCOREINFO")
> > n_descsz: 1384
> > n_type: 0 (unused)
> > OSRELEASE=3.0.101-63-xen
> > ...
> > Elf64_Nhdr:
> > n_namesz: 15 ("VMCOREINFO_XEN")
> > n_descsz: 4068
> > n_type: 0 (unused)
> > ...
> >
> > In the function dump_Elf64_Nhdr() I found:
> > vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
> >
> > But because the "VMCOREINFO_XEN" ist the second one in the file it
wins!
> >
> > When using
> > vmcoreinfo = STREQ(buf, "VMCOREINFO");
> > all is fine and I get:
> > # crash --osrelease vmcore
> > 3.0.101-63-xen
> >
> > So my question is: why is STRNEQ() used?
> > Thanks!
>
> Hello Dietmar,
>
> As I recall, I did all of the note name checks that way because the length
> of the name string is specified by the note->n_namesz field, and therefore
> not necessarily guaranteed to be a NULL-terminated string? In reality,
> they're probably will be a NULL there though.
>
> Anyway, I wasn't even familiar with the existence of a VMCOREINFO_XEN note,
> so please feel free to post a patch to address it.
>
> Dave
This should work, right?:
--- crash-7.1.3/netdump.c.orig
+++ crash-7.1.3/netdump.c
@@ -1940,7 +1940,8 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st
#endif
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
- vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
+ if (!STRNEQ(buf, "VMCOREINFO_XEN"))
+ vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
eraseinfo = STRNEQ(buf, "ERASEINFO");
qemuinfo = STRNEQ(buf, "QEMU");
if (xen_core) {
@@ -2196,7 +2197,8 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st
#endif
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
- vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
+ if (!STRNEQ(buf, "VMCOREINFO_XEN"))
+ vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
eraseinfo = STRNEQ(buf, "ERASEINFO");
qemuinfo = STRNEQ(buf, "QEMU");
if (xen_core) {
Dave
Actually, the patch above will prevent the VMCOREINFO_XEN strings from being
dumped in readable strings by "help -[nD]" or by "crash -d#". Try the
attached
patch instead, where both VMCOREINFO and VMCOREINFO_XEN string data will be
dumped appropriately.
I do have a couple old RHEL5 xen dom0 dumpfiles that have VMCOREINFO_XEN notes,
but they do not have VMCOREINFO notes. It must be relatively newer Xen kernels
that have both? Anyway, check out the updated patch and let me know.
And BTW, checking the ELF specs, the name string should be NULL-terminated, and
the n_namesz count should include the NULL-byte:
namesz and name
The first namesz bytes in name contain a null-terminated character
representation of the entry's owner and originator.
There's an accompanying diagram example that shows the namesz value counting
the NULL terminator.
However, the reason for STRNEQ() in crash stems from the fact that the
original "netdump" generated ELF vmcores were incorrectly created such
the n_namesz count did not include the NULL, and I believe that the
descriptor data started immediately after the name string.
For example, here's an old 2.6.9-based netdump generated vmcore, where
the name is "CORE", and therefore *should* have a n_namesz of 5 if it
included a NULL terminator:
Elf64_Nhdr:
n_namesz: 4 ("CORE")
n_descsz: 336
n_type: 1 (NT_PRSTATUS)
The correct way would include the NULL-byte as well, as is done with
kdump generated ELF vmcores:
Elf64_Nhdr:
n_namesz: 5 ("CORE")
n_descsz: 336
n_type: 1 (NT_PRSTATUS)
So for backwards-compatibility, I'd prefer to leave the checks using STRNEQ().
Thanks,
Dave
2:07 p.m.
New subject: crash failed to get backtrace in module on powerpc target(e500v2)
----- Original Message -----
Hi Experts:
I met a issue when try to analysis vmcore which was triggered by a error in module on
powerpc target.
BG:
Crash version is 6.1.4, I cross build it with powerpc toolchain, and run it on
p2020(e500v2) target directly.
It show the following error:
/*************************************************************************/
crash> bt
PID: 588 TASK: eed6e880 CPU: 1 COMMAND: "insmod"
R0: c0097cfc R1: eed81e80 R2: eed6e880 R3: eed81db8
R4: 00021000 R5: c07955df R6: 000025d1 R7: c0793bb0
R8: 00001a2f R9: 00000000 R10: 00000020 R11: eed80000
R12: 24000044 R13: 100a73a0 R14: 00000000 R15: 00000000
R16: 00000000 R17: 00000000 R18: 00000000 R19: 00000000
R20: 00000000 R21: 00000000 R22: 00000000 R23: 00000000
R24: 00000000 R25: 00000000 R26: 00028b70 R27: f23ea000
R28: 00000000 R29: eed81db8 R30: c0753178 R31: c0790000
NIP: c05c7e9c MSR: 00021000 OR3: eed81e48 CTR: 00000001
LR: c05c7e9c XER: 20000000 CCR: 24000042 MQ: c0007fdc
DAR: 00000000 DSISR: 00000000 Syscall Result: 00000000
NIP [00000000c05c7e9c] panic
LR [00000000c05c7e9c] panic
#0 [eed81e80] panic at c05c7e9c
bt: ppc_back_trace hit unknown symbol (f23e70b4).
/*************************************************************************/
I doubt if the crash can not worked well on e500v2 target for the moment?
BTW, In my module, module_init will call a function, that function will call panic and
cause kdump, but from the log when issue happen, looks it did not show the right call
trace:
/*************************************************************************/
[eed81e80] [c05c7e94] panic+0x12c/0x1ac
[eed81ed0] [f23e70b4] dummy_cleanup_module+0x0/0x44 [dummy]
[eed81ee0] [f23ea030] dummy_init_module+0x30/0x68 [dummy]
[eed81ef0] [c0002124] do_one_initcall+0x3c/0x1e0
[eed81f20] [c008e698] sys_init_module+0xf8/0x21c
/*************************************************************************/
Do you have some comments on this kind of secne?
Thanks a lot for your valuable time!
Hello James,
I believe that this error is due to the fact that the dummy module's
symbols have not been registered with the kernel, because the module
forced the panic too early. If you do a "sym -M", you probably will
not see the "dummy" module's symbols, and therefore crash cannot resolve
the f23e70b4 address.
After do_one_initcall() is called normally, there is still a lot of further
module initialization to be accomplished. In this case, it is not being done,
and the dummy module's "module" structure has not been fully initialization.
Dave
Best Regards,
James
Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983
6:57 p.m.
New subject: crash failed to get backtrace in module on powerpc target(e500v2)
Hi. Dave:
Got it, thanks very much for your updates!
Best regards!
James
在 2015年12月12日，上午4:11，Dave Anderson <anderson(a)redhat.com> 写道：
----- Original Message -----
>
> Hi Experts:
>
> I met a issue when try to analysis vmcore which was triggered by a error in module on
powerpc target.
>
> BG:
> Crash version is 6.1.4, I cross build it with powerpc toolchain, and run it on
p2020(e500v2) target directly.
>
>
> It show the following error:
> /*************************************************************************/
> crash> bt
> PID: 588 TASK: eed6e880 CPU: 1 COMMAND: "insmod"
> R0: c0097cfc R1: eed81e80 R2: eed6e880 R3: eed81db8
> R4: 00021000 R5: c07955df R6: 000025d1 R7: c0793bb0
> R8: 00001a2f R9: 00000000 R10: 00000020 R11: eed80000
> R12: 24000044 R13: 100a73a0 R14: 00000000 R15: 00000000
> R16: 00000000 R17: 00000000 R18: 00000000 R19: 00000000
> R20: 00000000 R21: 00000000 R22: 00000000 R23: 00000000
> R24: 00000000 R25: 00000000 R26: 00028b70 R27: f23ea000
> R28: 00000000 R29: eed81db8 R30: c0753178 R31: c0790000
> NIP: c05c7e9c MSR: 00021000 OR3: eed81e48 CTR: 00000001
> LR: c05c7e9c XER: 20000000 CCR: 24000042 MQ: c0007fdc
> DAR: 00000000 DSISR: 00000000 Syscall Result: 00000000
> NIP [00000000c05c7e9c] panic
> LR [00000000c05c7e9c] panic
> #0 [eed81e80] panic at c05c7e9c
> bt: ppc_back_trace hit unknown symbol (f23e70b4).
> /*************************************************************************/
>
> I doubt if the crash can not worked well on e500v2 target for the moment?
>
> BTW, In my module, module_init will call a function, that function will call panic
and cause kdump, but from the log when issue happen, looks it did not show the right call
trace:
> /*************************************************************************/
> [eed81e80] [c05c7e94] panic+0x12c/0x1ac
> [eed81ed0] [f23e70b4] dummy_cleanup_module+0x0/0x44 [dummy]
> [eed81ee0] [f23ea030] dummy_init_module+0x30/0x68 [dummy]
> [eed81ef0] [c0002124] do_one_initcall+0x3c/0x1e0
> [eed81f20] [c008e698] sys_init_module+0xf8/0x21c
> /*************************************************************************/
> Do you have some comments on this kind of secne?
>
> Thanks a lot for your valuable time!
Hello James,
I believe that this error is due to the fact that the dummy module's
symbols have not been registered with the kernel, because the module
forced the panic too early. If you do a "sym -M", you probably will
not see the "dummy" module's symbols, and therefore crash cannot resolve
the f23e70b4 address.
After do_one_initcall() is called normally, there is still a lot of further
module initialization to be accomplished. In this case, it is not being done,
and the dummy module's "module" structure has not been fully
initialization.
Dave
> Best Regards,
> James
>
> Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support
> Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
6:59 a.m.
New subject: Unknown osrelease information in vmcore with xen
Hi Dave,
Am Freitag 11 Dezember 2015, 14:35:56 schrieb Dave Anderson:
----- Original Message -----
>
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > > Hi,
> > >
> > > I have a SuSE SLES11 vmcore with xen and tried to read the osrelease from
> > > the vmcore with
> > > # crash --osrelease vmcore
> > > unknown
> > >
> > > The problem is that there are two notes in the vmcore starting with
> > > "VMCOREINFO":
> > >
> > > Elf64_Nhdr:
> > > n_namesz: 11 ("VMCOREINFO")
> > > n_descsz: 1384
> > > n_type: 0 (unused)
> > > OSRELEASE=3.0.101-63-xen
> > > ...
> > > Elf64_Nhdr:
> > > n_namesz: 15 ("VMCOREINFO_XEN")
> > > n_descsz: 4068
> > > n_type: 0 (unused)
> > > ...
> > >
> > > In the function dump_Elf64_Nhdr() I found:
> > > vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
> > >
> > > But because the "VMCOREINFO_XEN" ist the second one in the file
it wins!
> > >
> > > When using
> > > vmcoreinfo = STREQ(buf, "VMCOREINFO");
> > > all is fine and I get:
> > > # crash --osrelease vmcore
> > > 3.0.101-63-xen
> > >
> > > So my question is: why is STRNEQ() used?
> > > Thanks!
> >
> > Hello Dietmar,
> >
> > As I recall, I did all of the note name checks that way because the length
> > of the name string is specified by the note->n_namesz field, and therefore
> > not necessarily guaranteed to be a NULL-terminated string? In reality,
> > they're probably will be a NULL there though.
> >
> > Anyway, I wasn't even familiar with the existence of a VMCOREINFO_XEN
note,
> > so please feel free to post a patch to address it.
> >
> > Dave
>
>
> This should work, right?:
>
> --- crash-7.1.3/netdump.c.orig
> +++ crash-7.1.3/netdump.c
> @@ -1940,7 +1940,8 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st
> #endif
> default:
> xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
> - vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
> + if (!STRNEQ(buf, "VMCOREINFO_XEN"))
> + vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
> eraseinfo = STRNEQ(buf, "ERASEINFO");
> qemuinfo = STRNEQ(buf, "QEMU");
> if (xen_core) {
> @@ -2196,7 +2197,8 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st
> #endif
> default:
> xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
> - vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
> + if (!STRNEQ(buf, "VMCOREINFO_XEN"))
> + vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
> eraseinfo = STRNEQ(buf, "ERASEINFO");
> qemuinfo = STRNEQ(buf, "QEMU");
> if (xen_core) {
>
> Dave
Actually, the patch above will prevent the VMCOREINFO_XEN strings from being
dumped in readable strings by "help -[nD]" or by "crash -d#". Try
the attached
patch instead, where both VMCOREINFO and VMCOREINFO_XEN string data will be
dumped appropriately.
I do have a couple old RHEL5 xen dom0 dumpfiles that have VMCOREINFO_XEN notes,
but they do not have VMCOREINFO notes. It must be relatively newer Xen kernels
that have both? Anyway, check out the updated patch and let me know.
Thanks the patch works very well!
Only a minor nit, now the n_type has changed:
Elf64_Nhdr:
n_namesz: 15 ("VMCOREINFO_XEN")
n_descsz: 4068
n_type: 0 (?)
I'm not familiar enough what should be the right one:
"n_type: 0 (?)" or "n_type: 0 (unused)"
If the second this works for 64 bit:
--- a/netdump.c
+++ b/netdump.c
@@ -2231,6 +2231,8 @@ dump_Elf64_Nhdr(Elf64_Off offset, int store)
} else if (qemuinfo) {
pc->flags2 |= QEMU_MEM_DUMP_ELF;
netdump_print("(QEMUCPUState)\n");
+ } else if (vmcoreinfo_xen) {
+ netdump_print("(unused)\n");
} else
netdump_print("(?)\n");
break;
And BTW, checking the ELF specs, the name string should be NULL-terminated, and
the n_namesz count should include the NULL-byte:
namesz and name
The first namesz bytes in name contain a null-terminated character
representation of the entry's owner and originator.
There's an accompanying diagram example that shows the namesz value counting
the NULL terminator.
However, the reason for STRNEQ() in crash stems from the fact that the
original "netdump" generated ELF vmcores were incorrectly created such
the n_namesz count did not include the NULL, and I believe that the
descriptor data started immediately after the name string.
OK, I understand.
For example, here's an old 2.6.9-based netdump generated vmcore, where
the name is "CORE", and therefore *should* have a n_namesz of 5 if it
included a NULL terminator:
Elf64_Nhdr:
n_namesz: 4 ("CORE")
n_descsz: 336
n_type: 1 (NT_PRSTATUS)
The correct way would include the NULL-byte as well, as is done with
kdump generated ELF vmcores:
Elf64_Nhdr:
n_namesz: 5 ("CORE")
n_descsz: 336
n_type: 1 (NT_PRSTATUS)
So for backwards-compatibility, I'd prefer to leave the checks using STRNEQ().
Yes you are right.
Many thanks!
Dietmar.
Thanks,
Dave
--
Company details: http://ts.fujitsu.com/imprint.html
8:32 a.m.
New subject: Unknown osrelease information in vmcore with xen
----- Original Message -----
Thanks the patch works very well!
Only a minor nit, now the n_type has changed:
Elf64_Nhdr:
n_namesz: 15 ("VMCOREINFO_XEN")
n_descsz: 4068
n_type: 0 (?)
I'm not familiar enough what should be the right one:
"n_type: 0 (?)" or "n_type: 0 (unused)"
If the second this works for 64 bit:
--- a/netdump.c
+++ b/netdump.c
@@ -2231,6 +2231,8 @@ dump_Elf64_Nhdr(Elf64_Off offset, int store)
} else if (qemuinfo) {
pc->flags2 |= QEMU_MEM_DUMP_ELF;
netdump_print("(QEMUCPUState)\n");
+ } else if (vmcoreinfo_xen) {
+ netdump_print("(unused)\n");
} else
netdump_print("(?)\n");
break;
Yes, that is definitely better. I've added it to to both 32 and 64 bit,
and queued the patch for crash-7.1.4:
https://github.com/crash-utility/crash/commit/2515ef355f96da7e6cffad18dc8...
Thanks,
Dave
3270
days inactive
3273
days old
devel@lists.crash-utility.osci.io
7 comments
3 participants
participants (3)
-
Dave Anderson -
Dietmar Hahn -
Liu, Jianbo (James)