[PATCH] x86_64: Fix that Particular kvaddr is converted to wrong paddr (RHEL6 x86_64)
by Nakajima Akira
I didn't check XEN HYPER MODE, I don't have XEN.
If we need similar statement "if (kvaddr < MODULES_END)"
please add inside in "if (XEN_HYPER_MODE())" (1859@x86_64_kvtop)
>From ed300b74998e0923313e4fd14b9a41e305942b44 Mon Sep 17 00:00:00 2001
From: Nakajima Akira <nakajima.akira(a)nttcom.co.jp>
Date: Tue, 22 Dec 2015 15:46:42 +0900
Subject: [PATCH] Fix that particular kvaddr is converted to wrong paddr
BUG INFO
Particular kvaddr is converted to wrong paddr.
You can see this bug on RHEL6_x86_64. (at present only RHEL6)
(I checked RHEL5, RHEL7, Fedora21, Fedora23)
from /proc/kallsyms
ffffffffff6008c0 D __jiffies
/////////// wrong ///////////
crash> vtop ffffffffff6008c0
VIRTUAL PHYSICAL
ffffffffff6008c0 7f6008c0
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea00000623b8 1c11000 0 0 1 20000000000400 reserved
crash> rd ffffffffff6008c0
ffffffffff6008c0: 0000000000000000 ........
/////////// correct ///////////
crash> vtop ffffffffff6008c0
VIRTUAL PHYSICAL
ffffffffff6008c0 1c118c0
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea00000623b8 1c11000 0 0 1 20000000000400 reserved
crash> rd ffffffffff6008c0
ffffffffff6008c0: 00000000ffffe43a :.......
Reported-by: Nakajima Akira <nakajima.akira(a)nttcom.co.jp>
Signed-off-by: Nakajima Akira <nakajima.akira(a)nttcom.co.jp>
---
x86_64.c | 28 +++++++++++++++-------------
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/x86_64.c b/x86_64.c
index ff6fdd5..dab4d43 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -1872,19 +1872,21 @@ x86_64_kvtop(struct task_context *tc, ulong kvaddr, physaddr_t *paddr, int verbo
fprintf(fp, "PAGE DIRECTORY: %lx\n", *pml4);
}
} else {
- if (!vt->vmalloc_start) {
- *paddr = x86_64_VTOP(kvaddr);
- return TRUE;
- }
-
- if (!IS_VMALLOC_ADDR(kvaddr)) {
- *paddr = x86_64_VTOP(kvaddr);
- if (!verbose)
- return TRUE;
- }
-
- if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
- return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+ if (kvaddr < MODULES_END) {
+ if (!vt->vmalloc_start) {
+ *paddr = x86_64_VTOP(kvaddr);
+ return TRUE;
+ }
+
+ if (!IS_VMALLOC_ADDR(kvaddr)) {
+ *paddr = x86_64_VTOP(kvaddr);
+ if (!verbose)
+ return TRUE;
+ }
+
+ if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
+ return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+ }
/*
* pgd = pgd_offset_k(addr);
--
1.7.1
8 years, 11 months
if it's normal to get into kdb shell when run crash
by Liu, Jianbo (James)
Hi Experts:
Sorry for disturbing you again.
When I run crash to debug vmcore, if kernel enable kgdb, it will get into kdb shell directly not crash shell, althrough I can get into crash via execute two go command in kdb shell, not sure if it's normal, do you have some comments on it?
When I disnable kgdb in kernel, there will not be this kind of issue, if there is some compatibility problem between kgdb and crash tool?
Thanks for your time and happen new year!!
/****************************************/
root@localhost:~/coredump>sh testcoredump.sh; sh startcoredump.sh
segment[0].mem:0x2000000 memsz:9183232
segment[1].mem:0x28c2000 memsz:65536
segment[2].mem:0x28d2000 memsz:4096
segment[3].mem:0x28d3000 memsz:28672
segment[4].mem:0x2ff5000 memsz:45056
SysRq : Trigger a crash
Entering kdb (current=0xdb17f900, pid 822) on processor 1 Oops: (null)
due to oops @ 0xc0348f64
NIP: c0348f64 LR: c034974c CTR: c0348f50
REGS: db18ddc0 TRAP: 0300 Not tainted (2.6.34.15-grsec-WR4.3.0.0_cgl)
MSR: 00021202 <ME,CE,DE> CR: 20242444 XER: 00000000
DEAR: 00000000, ESR: 00800000
TASK = db17f900[822] 'sh' THREAD: db18c000 CPU: 1
GPR00: 00000001 db18de70 db17f900 00000063 00000000 ffffffff c035e930 00000000
GPR08: 00008000 00000000 00000054 118c6000 20242444 100b84b8 100b0828 100b0904
GPR16: 00000000 00000000 00000000 1006d2d0 00000000 100cc220 1006b530 00000000
GPR24: 00000001 c0780d24 00029202 c0780e08 c0770000 00000000 c08578a4 00000063
NIP [c0348f64] sysrq_handle_crash+0x14/0x20
LR [c034974c] __handle_sysrq+0xcc/0x1d0
Call Trace:
[db18de70] [c0349734] __handle_sysrq+0xb4/0x1d0 (unreliable)
[db18dea0] [c03498ac] write_sysrq_trigger+0x5c/0x70
[db18deb0] [c01662f0] proc_reg_write+0x80/0xc0
[db18dee0] [c010ec50] vfs_write+0xc0/0x170
[db18df00] [c010ee80] sys_write+0x50/0x110
[db18df40] [c0011d58] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xff16ba4
LR = 0xfebad5c
Instruction dump:
[1]more>
39600003 7d605f9e 556b103a 7c005b78 98090003 4e800020 60000000 38000001
3d20c07a 90092170 7c0004ac 39200000 <98090000> 4e800020 60000000 3803ffd0
[1]kdb>
[1]kdb> go
Catastrophic error detected
kdb_continue_catastrophic=0, type go a second time if you really want to continue
[1]kdb> go
Catastrophic error detected
kdb_continue_catastrophic=0, attempting to continue
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=4 LTT NESTING LEVEL : 0
P2041 RDB
last sysfs file: /sys/devices/system/cpu/cpu3/crash_notes
Modules linked in:
NIP: c0348f64 LR: c034974c CTR: c0348f50
REGS: db18ddc0 TRAP: 0300 Not tainted (2.6.34.15-grsec-WR4.3.0.0_cgl)
MSR: 00021202 <ME,CE,DE> CR: 20242444 XER: 00000000
DEAR: 00000000, ESR: 00800000
TASK = db17f900[822] 'sh' THREAD: db18c000 CPU: 1
GPR00: 00000001 db18de70 db17f900 00000063 00000000 ffffffff c035e930 00000000
GPR08: 00008000 00000000 00000054 118c6000 20242444 100b84b8 100b0828 100b0904
GPR16: 00000000 00000000 00000000 1006d2d0 00000000 100cc220 1006b530 00000000
GPR24: 00000001 c0780d24 00029202 c0780e08 c0770000 00000000 c08578a4 00000063
NIP [c0348f64] sysrq_handle_crash+0x14/0x20
LR [c034974c] __handle_sysrq+0xcc/0x1d0
Call Trace:
[db18de70] [c0349734] __handle_sysrq+0xb4/0x1d0 (unreliable)
[db18dea0] [c03498ac] write_sysrq_trigger+0x5c/0x70
[db18deb0] [c01662f0] proc_reg_write+0x80/0xc0
[db18dee0] [c010ec50] vfs_write+0xc0/0x170
[db18df00] [c010ee80] sys_write+0x50/0x110
[db18df40] [c0011d58] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xff16ba4
LR = 0xfebad5c
Instruction dump:
39600003 7d605f9e 556b103a 7c005b78 98090003 4e800020 60000000 38000001
3d20c07a 90092170 7c0004ac 39200000 <98090000> 4e800020 60000000 3803ffd0
Sending IPI to other cpus...
Bye!
Using P2041 RDB machine description
......
/**********************/
Best Regards,
James
Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983
Manage your support account:
https://support.windriver.com
Ask a Technical Question
https://ask.windriver.com
Submit a Service Request
https://windriver.force.com/support
8 years, 11 months
arm64: bug report: segfault
by Andrew Jones
Hi Dave,
When crash gets a prstatus for an AArch32 (compat) user mode stack frame,
but assumes it can look at prstatus->sp for the stack pointer, and
prstatus->sp has a stale AArch64 kernel address in it, then crash
segfaults.
This is because the stack pointer isn't a user stack address, and thus
crash expects the stack to include at least two frames, which would mean
fp is non-zero, but in this case it's not[1], and that leads to the
calculation of a bad stack pointer (see arm64.c:1209), which then gets
used as an offset into the stack buffer (see arm64.c:1001), overflowing
it.
The patch[2] I just sent resolves this issue for me, but only because
it no longer tries to use prstatus->sp. We should probably still look
into fixing this in another way, such as making sure fp is non-zero, as
dumps can have all sorts of corruption breaking our assumptions.
Thanks,
drew
[1] The dump was captured with QEMU, which doesn't require a real crash,
i.e. panic() being called in the guest kernel, thus cpus can actually
be in user mode, rather than in the 64-bit cpu-stop IPI handler, or
other crashing kernel code.
[2] https://www.redhat.com/archives/crash-utility/2015-December/msg00024.html
9 years
[PATCH] Do not create arch-specific p2m mapping for ELF xen dumps
by Petr Tesarik
Hello Dave,
Let me send you a cleanup/fix for Xen DomU dumps.
When opening a Xen DomU dump without auto-translated addresses (e.g.
from an x86_64 PV domain), a mapping between physical and machine
pages is needed. An xc_core dump file does not contain this mapping,
so it must be created by arch-specific code from the dumped data.
This (and only this) is the job of the machdep->xendump_p2m_create
callback, which is called if the XC_CORE_P2M_CREATE flag is set. ELF
files contain the mapping in a separate section (".xen_p2m"), so this
arch-specific code is not needed and should not be run.
On the other hand, XC_CORE_P2M_CREATE also triggers the initialization
of the elf_index_pfn array. I believe this should be in fact controlled
by XC_CORE_PFN_CREATE, because the flag is not used for anything else.
I found this issue thanks to a Xen DomU ELF dump file that contained an
invalid CR3 value, which could not be used to translate kvaddr to maddr.
Without the patch, session initialization fails with these messages:
crash: cannot find mfn 0 (0x0) in page index
crash: cannot read/find pud page
Signed-off-by: Petr Tesarik <ptesarik(a)suse.com>
9 years
[ANNOUNCE] crash version 7.1.4 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
The master branch serves as a development branch that will contain all
patches that are queued for the next release:
$ git clone git://github.com/crash-utility/crash.git
Changelog:
- Fix for the ARM64 "vtop" command when translating kernel virtual
addresses within a 2MB or 512MB huge page in which the PGD or PMD
contains software-defined PTE bits. Without the patch, the "PAGE:"
address value will show the software-defined bits, the command will
not display the related page structure translation, and will end with
the message "WARNING: sparsemem: invalid section number: <number>".
(Johan.Erlandsson(a)sonymobile.com, anderson(a)redhat.com)
- Fix for the X86_64 "bt" command in Linux 4.2 and later kernels
that are configured with both CONFIG_HAVE_COPY_THREAD_TLS and
CONFIG_FRAME_POINTER. Without the patch, the fact that the kernel
was compiled with framepointers is not recognized, which may result
in backtraces containing stale frame references.
(anderson(a)redhat.com)
- Fix for the "dis" command to support three new x86 instruction
extensions that have been added to the Intel instruction set for
hardware platforms that support them. The newly-added instructions
"clflushopt", "clwb", and "pcommit" prepend 0x66 as a prefix byte to
the "clflush", "xsaveopt" and "sfence" instructions respectively.
Without the patch:
"clflushopt" is disassembled as: "data16" followed by "clflush"
"clwb" is disassembled as: "data16" followed by "xsaveopt"
"pcommit" is disassembled as: "data16" followed by "sfence"
The "clflushopt" instruction was introduced in Linux 3.15 in the
clflushopt() function. The "clwb" and "pcommit" instructions were
introduced in Linux 4.1 in the clwb() and pcommit_sfence() functions.
(anderson(a)redhat.com)
- Fix for the extensions/trace.c extension module for Linux 4.2 and
later kernels. Without the patch, the module fails to load, with
the message "failed to init the offset, struct:ftrace_event_call,
member:list".
(anderson(a)redhat.com)
- For many years, Xen Dom0 dumps could only be saved in ELF format.
Since makedumpfile commit 349a0ed1, it is now possible to save Xen
dumps in compressed kdump format. This patch set adds support for
these files. Two new files, xen_dom0.c and xen_dom0.h, have been
added to provide the common functionality required by both ELF and
compressed kdump formats.
(ptesarik(a)suse.cz)
- Since Linux v4.1, specifically, "MIPS: Rearrange PTE bits into fixed
positions.", commit be0c37c985eddc46d0d67543898c086f60460e2e, the
MIPS PTE bits are at fixed locations. Since they are macros in the
kernel, this patch adds an explicit kernel version check in order to
determine and set their values.
(rabinv(a)axis.com)
- Display a machine-type mismatch warning if a little-endian PPC64
compressed kdump created by makedumpfile(8) is used as an argument
with a non-PPC64 crash utility binary. Without the patch, the
dumpfile is accepted, and the session subsequently fails with a
message indicating that that the vmlinux and dumpfile do not match.
(anderson(a)redhat.com)
- Fix for bitmap-handling in SADUMP dumpfiles, which associate each bit
in a bitmap with a physical page in the reverse order that is used
in kdump-compressed format. The bug had not been detected for a long
time because bitmaps in SADUMP formats consist mostly of 0x00 and
0xff excluding a very limited amount of memory space for firmware.
(indou.takao(a)jp.fujitsu.com, d.hatayama(a)jp.fujitsu.com)
- Fix for the behavior of the --zero_excluded option when used with
SADUMP dumpfiles. Without the patch, the behavior of --zero_excluded
option is the opposite to what is expected: reads of filtered pages
return successfully with zero-filled memory, while reads of filtered
filtered pages fail when --zero_excluded option has been specified.
(d.hatayama(a)jp.fujitsu.com)
- Fix for the "kmem -i" command in Linux 2.6.27 and later kernels to
prevent the possibility that an arbitrary address may be accessed
when calculating the number of total huge pages. Without the patch,
the command's "COMMIT LIMIT" and "COMMITTED" values may be invalid.
(atomlin(a)redhat.com)
- Added recognition of the new DUMP_DH_EXCLUDED_VMEMMAP flag in the
header of compressed kdumps, which is set by the new -e option to
the makedumpfile(8) facility. The -e option excludes kernel pages
that contain nothing but kernel page structures for pages that are
not being included in the dump. If the bit is set in the dumpfile,
the crash utility will issue a warning that the dumpfile is known to
be incomplete during initialization, just prior to the system banner
display.
(anderson(a)redhat.com)
- Fix for the handling of compound pages in Linux 4.4 and later kernels,
which contain this kernel commit:
commit 1d798ca3f16437c71ff63e36597ff07f9c12e4d6
mm: make compound_head() robust
The commit above removes the PG_tail and PG_compound page.flags bits
and the page.first_page member, and introduces a page.compound_head
member, which is a pointer to the head page and whose bit 0 acts as
the tail flag. Without the patch, a SLAB or SLUB warning message
that indicates "cannot determine how compound pages are linked" is
displayed during initialization, and any command that tracks compound
pages will be affected.
(anderson(a)redhat.com)
- Fix for the handling of dynamically-sized task_struct structures in
Linux 4.2 and later kernels, which contain these commits:
commit 5aaeb5c01c5b6c0be7b7aadbf3ace9f3a4458c3d
x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and
use it on x86
commit 0c8c0f03e3a292e031596484275c14cf39c0ab7a
x86/fpu, sched: Dynamically allocate 'struct fpu'
Without the patch, when running on a filtered kdump dumpfile, it is
possible that error messages like this will be seen when gathering
the tasks running on a system: "crash: page excluded: kernel virtual
address: <task_struct address> type: "fill_task_struct".
(ats-kumagai(a)wm.jp.nec.com)
- Fix for the "kmem -s <address>" command in Linux 3.13 and later
kernels configured with CONFIG_SLAB. Without the patch, if the
address argument is contained within an object in a tail page of a
multi-page slab, the command fails with the message "kmem: address
is not allocated in slab subsystem: <address>". Furthermore, in
Linux 4.4 and later kernels configured with CONFIG_SLAB, addresses
that are contained within an object in a tail page of a multi-page
slab will not be marked by their slab cache name by the "rd -S" and
"bt -F" commands.
(anderson(a)redhat.com)
- Fix for a segmentation violation when attempting to run live on a
a system without the crash.ko memory driver, and whose kernel was
configured with CONFIG_STRICT_DEVMEM. Without the patch, if any
-d<value> is entered on the command line, the crash session fails
during initialization.
(dmair(a)suse.com)
- Update for the determination of the ARM64 page size for kernels
containing this Linux 4.4 commit:
commit 9d372c9fab34cd8803141871195141995f85c7f7
arm64: Add page size to the kernel image header
Without the patch, the kernel page size is calculated by looking
at the size of the "swapper_pg_dir" page directory. With this
update, the page size can be determined by checking a flag built
into the kernel image header, available in the "_kernel_flags_le"
absolute symbol.
(drjones(a)redhat.com)
- Fix for the handling of ARM and ARM64 QEMU-generated ELF dumpfiles
and compressed kdump clones. The patch utilizes the NT_PRSTATUS
notes in the dumpfile headers instead of reading them from the
kernel's "crash_notes", which are not initialized when QEMU generates
a dumpfile. Without the patch, these warning messages are displayed
during session initialization:
WARNING: invalid note (n_type != NT_PRSTATUS)
WARNING: cannot retrieve registers for active tasks
and running "bt" on an active task causes a segmentation violation.
(drjones(a)redhat.com)
- Update to the previous QEMU-specific patch to handle kdump dumpfiles
which have offline cpus, and therefore will not contain associated
NT_PRSTATUS notes in the dumpfile header. Without the patch, if
there are any offline cpus, a segmentation violation is generated
during session initialization.
(anderson(a)redhat.com)
- The s390 stand-alone dump tools may write the kernel memory directly
to a block device. When running the crash utility against such a
block device, a misleading warning message such as this is displayed:
WARNING: /dev/sda1: may be truncated or incomplete
PT_LOAD p_offset: 16384
p_filesz: 5497558138880
bytes required: 5497558155264
dumpfile size: 0
With the patch, the warning message above will be replaced by a note
using this format:
NOTE: /dev/sda1: No dump complete check for block devices
(holzheu(a)linux.vnet.ibm.com)
- Map CTRL-l to clear the screen while in vi insertion mode. Without
the patch, it displays "^L".
(kwalker(a)redhat.com)
- Introduced a general-purpose handler to register data structures that
the kernel has dynamically downsized from the size indicated by the
debuginfo data. At this time, only "kmem_cache" and "task_struct"
structures that have been downsized are registered, but others may be
added in the future. If a downsized data structure is passed to gdb
for display, gdb will request a read of the "full" data structure,
which may flow into a memory region that was either filtered by
makedumpfile(8), or perhaps into non-existent memory, thereby killing
the generating command immediately due to a partial read. With this
patch, commands such as "struct" and "task" that reference downsized
data structures will have their reads flagged to return successfully
if partial read error occurs.
(anderson(a)redhat.com)
- Fix for Linux 3.18 and later 32-bit ARM kernels that are configured
with CONFIG_SLAB which contain percpu array_cache structures that
were allocated with vmalloc(). Without the patch, during session
initialization there will be error messages that indicate "crash:
kmem_cache: <vaddr>: invalid array_cache pointer: <vaddr>", and
during runtime, the "kmem -[sS]" commands will show kmem_cache lines
that marked as "[INVALID/CORRUPTED]".
(anderson(a)redhat.com)
- Added a new "list -l <offset>" option that can only be used in
conjunction with "-s", and requires that the "start" address is the
address of a list_head, or other similar list linkage structure whose
first member points to the next linkage structure. The "-l <offset>"
argument is the offset of the embedded list linkage structure in the
specified "-s" data structure; it can be either a number of bytes or
expressed in "struct.member" format.
(anderson(a)redhat.com)
- Enhanced the debug-only display of the first kernel data items read
during session initialization. This includes the system's cpu maps,
xtime, and utsname data. These require at least "-d1" as a command
line option value, and are primarily useful as an aide for debugging
suspect dumpfiles that fail during session initialization.
(anderson(a)redhat.com)
- Added "print_array" as a new internal variable that may be turned
on/off with the "set" command. When set to "on", gdb's printing of
arrays will be set to "pretty", so that the display of each array
element will consume one line.
(anderson(a)redhat.com)
- Introduction of the "sys -i" option, which displays the kernel's DMI
identification string data if available.
(atomlin(a)redhat.com, anderson(a)redhat.com)
- Fix for "crash --osrelease" on Xen kernels that have both VMCOREINFO
and VMCOREINFO_XEN ELF notes. Without the patch, the command returns
"(unknown)".
(anderson(a)redhat.com, dietmar.hahn(a)ts.fujitsu.com)
9 years
Unknown osrelease information in vmcore with xen
by Dietmar Hahn
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
9 years
crash failed to get backtrace in module on powerpc target(e500v2)
by Liu, Jianbo (James)
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!
Best Regards,
James
Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983
Manage your support account:
https://support.windriver.com
Ask a Technical Question
https://ask.windriver.com
Submit a Service Request
https://windriver.force.com/support
9 years
Re: [Crash-utility] [PATCH] sys: Introduce -i option to dump dmi_ident data
by Dave Anderson
----- Original Message -----
> Aaron and Buland,
>
> I was just about to check this in when I thought that maybe it could
> be a bit more informative than just "dmi_ident[#]: <string>", given
> that the output could also incorporate the enum name/index, as is done
> with a few other crash commands:
>
> crash> dmi_field
> enum dmi_field {
> DMI_NONE = 0
> DMI_BIOS_VENDOR = 1
> DMI_BIOS_VERSION = 2
> DMI_BIOS_DATE = 3
> DMI_SYS_VENDOR = 4
> DMI_PRODUCT_NAME = 5
> DMI_PRODUCT_VERSION = 6
> DMI_PRODUCT_SERIAL = 7
> DMI_PRODUCT_UUID = 8
> DMI_BOARD_VENDOR = 9
> DMI_BOARD_NAME = 10
> DMI_BOARD_VERSION = 11
> DMI_BOARD_SERIAL = 12
> DMI_BOARD_ASSET_TAG = 13
> DMI_CHASSIS_VENDOR = 14
> DMI_CHASSIS_TYPE = 15
> DMI_CHASSIS_VERSION = 16
> DMI_CHASSIS_SERIAL = 17
> DMI_CHASSIS_ASSET_TAG = 18
> DMI_STRING_MAX = 19
> };
>
> Although, gdb doesn't have the dmi_field enum data available like the
> above in really old kernels, so in those rare cases it could only be
> done as you have. Maybe there could be an index_to_DMI_field() function
> that returns the string above, or just a number string if it can't do
> the translation?
>
> Dave
The attached patch is what I'm thinking. On a Lenovo laptop it looks like:
crash> sys -i
DMI_BIOS_VENDOR: LENOVO
DMI_BIOS_VERSION: G4ET37WW (1.12 )
DMI_BIOS_DATE: 05/29/2012
DMI_SYS_VENDOR: LENOVO
DMI_PRODUCT_NAME: 2429BQ1
DMI_PRODUCT_VERSION: ThinkPad T530
DMI_PRODUCT_SERIAL: R9R91HZ
DMI_PRODUCT_UUID: 568DFA01-5180-11CB-B851-BD06085ADDB0
DMI_BOARD_VENDOR: LENOVO
DMI_BOARD_NAME: 2429BQ1
DMI_BOARD_VERSION: Not Available
DMI_BOARD_SERIAL: 1ZLV127F17M
DMI_BOARD_ASSET_TAG: Not Available
DMI_CHASSIS_VENDOR: LENOVO
DMI_CHASSIS_TYPE: 10
DMI_CHASSIS_VERSION: Not Available
DMI_CHASSIS_SERIAL: R9R91HZ
DMI_CHASSIS_ASSET_TAG: RH0004111
crash>
A recent HP kernel looks like this though:
crash> sys -i
DMI_BIOS_VENDOR: Hewlett-Packard
DMI_BIOS_VERSION: 786F7 v01.05
DMI_BIOS_DATE: 04/25/2008
DMI_SYS_VENDOR: Hewlett-Packard
DMI_PRODUCT_NAME: HP xw4550 Workstation
DMI_PRODUCT_VERSION:
DMI_PRODUCT_SERIAL: BAL1010051
DMI_PRODUCT_UUID: 308A59FA-9B77-DE11-BBDA-C486CC82001C
DMI_BOARD_VENDOR: Hewlett-Packard
DMI_BOARD_NAME: 0AC8h
DMI_BOARD_VERSION:
DMI_BOARD_SERIAL: BAL1010051
DMI_BOARD_ASSET_TAG:
DMI_CHASSIS_VENDOR: Hewlett-Packard
DMI_CHASSIS_TYPE: 6
DMI_CHASSIS_VERSION:
DMI_CHASSIS_SERIAL: BAL1010051
DMI_CHASSIS_ASSET_TAG:
crash>
when the "empty" entries are not NULL pointers, but rather pointers
to NULL strings or strings with spaces in them:
crash> p dmi_ident
dmi_ident = $1 =
{0x0, 0xffffffff8203b000 "Hewlett-Packard", 0xffffffff8203b010 "786F7 v01.05", 0xffffffff8203b020 "04/25/2008", 0xffffffff8203b02c "Hewlett-Packard", 0xffffffff8203b03c "HP xw4550 Workstation", 0xffffffff8203b054 " ", 0xffffffff8203b058 "BAL1010051", 0xffffffff8203b064 "308A59FA-9B77-DE11-BBDA-C486CC82001C", 0xffffffff8203b08c "Hewlett-Packard", 0xffffffff8203b09c "0AC8h", 0xffffffff8203b0a4 "", 0xffffffff8203b0a8 "BAL1010051", 0xffffffff8203b0b4 "", 0xffffffff8203b0b8 "Hewlett-Packard", 0xffffffff8203b0c8 "6", 0xffffffff8203b0cc "", 0xffffffff8203b0d0 "BAL1010051", 0xffffffff8203b0dc " "}
crash>
Do you think those should should be just dropped, or shown as above?
Dave
9 years
Re: [Crash-utility] [PATCH] help: Introduce -i option to dump dmi_ident[] data
by Dave Anderson
Hi Aaron,
This kind of kernel/machine specific information has no place in the "help" command, which is wholly concerned with crash utility internal debug related information.
It's probably not worthy of its own command, so maybe it could be a "sys" or "mach" option?
Dave
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Aaron Tomlin <atomlin(a)redhat.com>
Date: 12/05/2015 12:41 PM (GMT-05:00)
To: crash-utility(a)redhat.com
Cc: milos(a)redhat.com, bsingh(a)redhat.com
Subject: [Crash-utility] [PATCH] help: Introduce -i option to dump
dmi_ident[] data
This patch introduces a '-i' option to the 'help' command to allow the user
to conveniently display the DMI (Desktop Management Interface) table,
if available. For example:
crash> help -i
dmi_ident[1]: LENOVO
dmi_ident[2]: GIET75WW (2.25 )
dmi_ident[3]: 06/24/2014
dmi_ident[4]: LENOVO
dmi_ident[5]: 20AMS22U0C
dmi_ident[6]: ThinkPad X240
dmi_ident[7]: PC00CDZE
dmi_ident[8]: 01338439-0853-CB11-8EBB-CE1D1FC1CBC0
dmi_ident[9]: LENOVO
dmi_ident[10]: 20AMS22U0C
dmi_ident[11]: Not Defined
dmi_ident[12]: L1HF47E00T3
dmi_ident[13]: Not Available
dmi_ident[14]: LENOVO
dmi_ident[15]: 10
dmi_ident[16]: Not Available
dmi_ident[17]: PC00CDZE
dmi_ident[18]: No Asset Information
crash>
Suggested-by: Buland Singh <bsingh(a)redhat.com>
Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
---
help.c | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/help.c b/help.c
index 883ddd0..fb1d518 100644
--- a/help.c
+++ b/help.c
@@ -32,6 +32,7 @@ static char *output_info[];
static char *input_info[];
static char *README[];
static void dump_registers(void);
+static void dump_dmi_info(void);
#define GPLv2 2
#define GPLv3 3
@@ -523,7 +524,7 @@ cmd_help(void)
oflag = 0;
while ((c = getopt(argcnt, args,
- "efNDdmM:ngcaBbHhkKsvVoptTzLxOr")) != EOF) {
+ "efNDdmM:ngcaBbHhkKsvVoptTzLxOri")) != EOF) {
switch(c)
{
case 'e':
@@ -638,6 +639,7 @@ cmd_help(void)
fprintf(fp, " -f - filesys table\n");
fprintf(fp, " -h - hash_table data\n");
fprintf(fp, " -H - hash_table data (verbose)\n");
+ fprintf(fp, " -i - dump dmi_ident data\n");
fprintf(fp, " -k - kernel_table\n");
fprintf(fp, " -K - kernel_table (verbose)\n");
fprintf(fp, " -L - LKCD page cache environment\n");
@@ -663,6 +665,10 @@ cmd_help(void)
dump_registers();
return;
+ case 'i':
+ dump_dmi_info();
+ return;
+
default:
argerrs++;
break;
@@ -707,6 +713,32 @@ dump_registers(void)
ACTIVE() ? "a live system" : "this dumpfile type");
}
+static void
+dump_dmi_info(void)
+{
+ int i, len;
+ ulong dmi_ident_p, vaddr;
+ char buf[BUFSIZE];
+
+ if (!kernel_symbol_exists("dmi_ident")) {
+ error(INFO, "dmi_ident does not exist in this kernel\n");
+ }
+
+ dmi_ident_p = symbol_value("dmi_ident");
+ len = get_array_length("dmi_ident", NULL, 0);
+
+ for (i = 0; i < len; i++) {
+ readmem(dmi_ident_p + (sizeof(void *) * i),
+ KVADDR, &vaddr, sizeof(void *),
+ "dmi_ident", FAULT_ON_ERROR);
+
+ if (!vaddr)
+ continue;
+ read_string(vaddr, buf, BUFSIZE-1);
+ fprintf(fp, " dmi_ident[%d]: %s\n", i, buf);
+ }
+}
+
/*
* Format and display the help menu.
*/
@@ -991,6 +1023,7 @@ char *help_help[] = {
" -f - filesys table",
" -h - hash_table data",
" -H - hash_table data (verbose)",
+" -i - dump dmi_ident data",
" -k - kernel_table",
" -K - kernel_table (verbose)",
" -L - LKCD page cache environment",
--
2.4.3
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
9 years
