Re: [Crash-utility] Kernel Crash Analysis on Android
by Shankar, AmarX
Hi Dave,
Thanks for your info regarding kexec tool.
I am unable to download kexec from below link.
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-too...
It says HTTP 404 Page Not Found.
Could you please guide me on this?
Thanks & Regards,
Amar Shankar
> On Wed, Mar 21, 2012 at 06:00:00PM +0000, Shankar, AmarX wrote:
>
> > I want to do kernel crash Analysis on Android Merrifield Target.
> >
> > Could someone please help me how to do it?
>
> Merrifield is pretty much similar than Medfield, e.g it has x86 core. So I
> guess you can follow the instructions how to setup kdump on x86 (see
> Documentation/kdump/kdump.txt) unless you already have that configured.
>
> crash should support this directly presuming you have vmlinux/vmcore files to
> feed it. You can configure crash to support x86 on x86_64 host by running:
>
> % make target=X86
> & make
>
> (or something along those lines).
Right -- just the first make command will suffice, i.e., when running
on an x86_64 host:
$ wget http://people.redhat.com/anderson/crash-6.0.4.tar.gz
$ tar xzf crash-6.0.4.tar.gz
...
$ cd crash-6.0.4
$ make target=X86
...
$ ./crash <path-to>/vmlinux <path-to>/vmcore
Dave
From: Shankar, AmarX
Sent: Wednesday, March 21, 2012 11:30 PM
To: 'crash-utility(a)redhat.com'
Subject: Kernel Crash Analysis on Android
Hi,
I want to do kernel crash Analysis on Android Merrifield Target.
Could someone please help me how to do it?
Thanks & Regards,
Amar Shankar
1 year
[PATCH] kmem, snap: iomem/ioport display and vmcore snapshot support
by HATAYAMA Daisuke
Some days ago I was in a situation that I had to convert vmcore in
kvmdump format into ELF since some extension module we have locally
can be used only on relatively old crash utility, around version 4,
but such old crash utility cannot handle kvmdump format.
To do the conversion in handy, I used snap command with some modifications
so that it tries to use iomem information in vmcore instead of host's
/proc/iomem. This patch is its cleaned-up version.
In this development, I naturally got down to also making an interface
for an access to resource objects, and so together with the snap
command's patch, I also extended kmem command for iomem/ioport
support. Actually:
kmem -r displays /proc/iomem
crash> kmem -r
00000000-0000ffff : reserved
00010000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c7fff : Video ROM
...
and kmem -R displays /proc/ioport
crash> kmem -R
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
...
Looking into old version of kernel source code back, resource structure
has been unchanged since linux-2.4.0. I borrowed the way of walking on
resouce tree in this patch from the lastest v3.3-rc series, but I
guess the logic is also applicable to old kernels. I expect Dave's
regression testsuite.
Also, there would be another command more sutable for iomem/ioport.
If necessay, I'll repost the patch.
---
HATAYAMA Daisuke (4):
Add vmcore snapshot support
Add kmem -r and -R options
Add dump iomem/ioport functions; a helper for resource objects
Add a helper function for iterating resource objects
defs.h | 9 ++++
extensions/snap.c | 54 ++++++++++++++++++++++-
help.c | 2 +
memory.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 180 insertions(+), 7 deletions(-)
--
Thanks.
HATAYAMA Daisuke
1 year
Re: [Crash-utility] question about phys_base
by Dave Anderson
----- Original Message -----
> >
> > OK, so then I don't understand what you mean by "may be the same"?
> >
> > You didn't answer my original question, but if I understand you correctly,
> > it would be impossible for the qemu host to create a PT_LOAD segment that
> > describes an x86_64 guest's __START_KERNEL_map region, because the host
> > doesn't know that what kind of kernel the guest is running.
>
> Yes. Even if the guest is linux, it is still impossible to do it. Because
> the guest maybe in the second kernel.
>
> qemu-dump walks all guest's page table and collect virtual address and
> physical address mapping. If the page is not used by guest, the virtual is set
> to 0. I create PT_LOAD according to such mapping. So if the guest is linux,
> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
> But the information stored in PT_LOAD maybe for the second kernel. If crash
> uses it, crash will see the second kernel, not the first kernel.
Just to be clear -- what do you mean by the "second" kernel? Do you
mean that a guest kernel crashed guest, and did a kdump operation,
and that second kdump kernel failed somehow, and now you're trying
to do a "virsh dump" on the kdump kernel?
Dave
1 year
question about phys_base
by Wen Congyang
Hi, Dave
I am implementing a new dump command in the qemu. The vmcore's
format is elf(like kdump). And I try to provide phys_base in
the PT_LOAD. But if the os uses the first vcpu do kdump, the
value of phys_base is wrong.
I find a function x86_64_virt_phys_base() in crash's code.
Is it OK to call this function first? If the function
successes, we do not calculate phys_base according to PT_LOAD.
Thanks
Wen Congyang
1 year
[PATCH] runq: search current task's runqueue explicitly
by HATAYAMA Daisuke
Currently, runq sub-command doesn't consider CFS runqueue's current
task removed from CFS runqueue. Due to this, the remaining CFS
runqueus that follow the current task's is not displayed. This patch
fixes this by making runq sub-command search current task's runqueue
explicitly.
Note that CFS runqueue exists for each task group, and so does CFS
runqueue's current task, and the above search needs to be done
recursively.
Test
====
On vmcore I made 7 task groups:
root group --- A --- AA --- AAA
+ +- AAB
|
+- AB --- ABA
+- ABB
and then I ran three CPU bound tasks, which is exactly the same as
int main(void) { for (;;) continue; return 0; }
for each task group, including root group; so total 24 tasks. For
readability, I annotated each task name with its belonging group name.
For example, loop.ABA belongs to task group ABA.
Look at CPU0 collumn below. [before] lacks 8 tasks and [after]
successfully shows all tasks on the runqueue, which is identical to
the result of [sched debug] that is expected to ouput correct result.
I'll send this vmcore later.
[before]
crash> runq | cat
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
<cut>
[after]
crash_fix> runq
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
<cut>
[sched debug]
crash> runq -d
CPU 0
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
<cut>
Diff stat
=========
defs.h | 1 +
task.c | 37 +++++++++++++++++--------------------
2 files changed, 18 insertions(+), 20 deletions(-)
Thanks.
HATAYAMA, Daisuke
1 year
[RFC] makedumpfile, crash: LZO compression support
by HATAYAMA Daisuke
Hello,
This is a RFC patch set that adds LZO compression support to
makedumpfile and crash utility. LZO is as good as in size but by far
better in speed than ZLIB, leading to reducing down time during
generation of crash dump and refiltering.
How to build:
1. Get LZO library, which is provided as lzo-devel package on recent
linux distributions, and is also available on author's website:
http://www.oberhumer.com/opensource/lzo/.
2. Apply the patch set to makedumpfile v1.4.0 and crash v6.0.0.
3. Build both using make. But for crash, do the following now:
$ make CFLAGS="-llzo2"
How to use:
I've newly used -l option for lzo compression in this patch. So for
example, do as follows:
$ makedumpfile -l vmcore dumpfile
$ crash vmlinux dumpfile
Request of configure-like feature for crash utility:
I would like configure-like feature on crash utility for users to
select wheather to add LZO feature actually or not in build-time,
that is: ./configure --enable-lzo or ./configure --disable-lzo.
The reason is that support staff often downloads and installs the
latest version of crash utility on machines where lzo library is not
provided.
Looking at the source code, it looks to me that crash does some kind
of configuration processing in a local manner, around configure.c,
and I guess it's difficult to use autoconf tools directly.
Or is there another better way?
Performance Comparison:
Sample Data
Ideally, I must have measured the performance for many enough
vmcores generated from machines that was actually running, but now
I don't have enough sample vmcores, I couldn't do so. So this
comparison doesn't answer question on I/O time improvement. This
is TODO for now.
Instead, I choosed worst and best cases regarding compression
ratio and speed only. Specifically, the former is /dev/urandom and
the latter is /dev/zero.
I get the sample data of 10MB, 100MB and 1GB by doing like this:
$ dd bs=4096 count=$((1024*1024*1024/4096)) if=/dev/urandom of=urandom.1GB
How to measure
Then I performed compression for each block, 4096 bytes, and
measured total compression time and output size. See attached
mycompress.c.
Result
See attached file result.txt.
Discussion
For both kinds of data, lzo's compression was considerably quicker
than zlib's. Compression ratio is about 37% for urandom data, and
about 8.5% for zero data. Actual situation of physical memory
would be in between the two cases, and so I guess average
compression time ratio is between 37% and 8.5%.
Although beyond the topic of this patch set, we can estimate worst
compression time on more data size since compression is performed
block size wise and the compression time increases
linearly. Estimated worst time on 2TB memory is about 15 hours for
lzo and about 40 hours for zlib. In this case, compressed data
size is larger than the original, so they are really not used,
compression time is fully meaningless. I think compression must be
done in parallel, and I'll post such patch later.
Diffstat
* makedumpfile
diskdump_mod.h | 3 +-
makedumpfile.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++------
makedumpfile.h | 12 +++++++
3 files changed, 101 insertions(+), 12 deletions(-)
* crash
defs.h | 1 +
diskdump.c | 20 +++++++++++++++++++-
diskdump.h | 3 ++-
3 files changed, 22 insertions(+), 2 deletions(-)
TODO
* evaluation including I/O time using actual vmcores
Thanks.
HATAYAMA, Daisuke
1 year
Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
by tachibana＠mxm.nes.nec.co.jp
Hi Hatayama-san,
On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>
> >
> >
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >>
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >>
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >>
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.
I think it's not bad to support sadump by makedumpfile. However I have
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has
dumped small?
- It isn't possible to support the same form as kdump-compressed format
now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore
(or a header of kdump-compressed format) is added by an extension of
makedumpfile, do you need to modify sadump?
Thanks
tachibana
> >
> > Sure, yes, the crash utility can always support another dumpfile format.
> >
>
> Thanks. It helps a lot.
>
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"? I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
>
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
>
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
>
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
>
> Again, thanks a lot for the positive answer.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> _______________________________________________
> kexec mailing list
> kexec(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
1 year
Problem in bt for ARM64
by Karlsson, Jan
Hi Dave
I have experienced some problems in the bt command for ARM64. It seems that the test in arm64_print_exception_frame in arm64.c if the task is running in 32 or 64-bit mode in userland does not work. It "always" becomes 32-bit mode. Example:
crash> bt 1
PID: 1 TASK: ffffffe1f90f8000 CPU: 2 COMMAND: "init"
#0 [ffffffe1f9103c80] __switch_to at ffffff85b6a862f8
#1 [ffffffe1f9103ca0] __schedule at ffffff85b7b0d9b0
#2 [ffffffe1f9103d00] schedule at ffffff85b7b0df28
#3 [ffffffe1f9103d20] schedule_hrtimeout_range_clock at ffffff85b7b11308
#4 [ffffffe1f9103da0] schedule_hrtimeout_range at ffffff85b7b11320
#5 [ffffffe1f9103db0] sys_epoll_wait at ffffff85b6c394c8
#6 [ffffffe1f9103e70] sys_epoll_pwait at ffffff85b6c396fc
#7 [ffffffe1f9103ed0] el0_svc_naked at ffffff85b6a8312c
PC: 00000004 LR: 00000000 SP: 00000000 PSTATE: 00000016
X12: 00546694 X11: 3431206c616e6769 X10: 00546338 X9: 00000000
X8: 00000112 X7: dfdab819254dd1e8 X6: 00000016 X5: 0000000a
X4: 00000031 X3: 00000008 X2: 00000000 X1: ffffffff
X0: 00000001
The register values are:
r0: 4 r1: 7ff0b27f90
r2: 1 r3: ffffffff
r4: 0 r5: 8
r6: 31 r7: a
r8: 16 r9: dfdab819254dd1e8
r10: 112 r11: 0
r12: 546338 r13: 3431206c616e6769
r14: 546694 r15: 0
r16: 0 r17: f04245b7
r18: 51f2a993 r19: 5783c0
r20: 415254 r21: 527a5c
r22: 527e04 r23: ffffffff
r24: ffffffff r25: 576000
r26: 578000 r27: 578000
r28: 3e8 fp: 7ff0b27ec0
lr: 4f4f24 sp: 7ff0b27eb0
pc: 4fb8d4 psr: 40000000
I have unfortunately not had the time to look for a solution, so I just want to report what I have seen. The kernel running in the example above is 4.4.74 and I have seen the same problem for a 4.9.40 kernel.
Jan
7 years, 1 month
[ANNOUNCE] crash version 7.2.0 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
The github 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 "snap.so" extension module to pass the KASLR relocation
offset value in the ELF header for x86_64 kernels that are compiled
with CONFIG_RANDOMIZE_BASE. Without the patch, it is necessary to
use the "--kaslr=<offset>" command line option, or the session
fails with the message "WARNING: cannot read linux_banner string",
followed by "crash: vmlinux and vmcore do not match!".
(anderson(a)redhat.com)
- The native gdb "disassemble" command fails if the kernel has been
compiled with CONFIG_RANDOMIZE_BASE because the embedded gdb module
still operates under the assumption that the (non-relocated) text
locations in the vmlinux file are correct. The error message that
is issued is somewhat confusing, indicating "No function contains
specified address". This patch simply clarifies the error message
to indicate "crash: the gdb "disassemble" command is prohibited
because the kernel text was relocated by KASLR; use the crash "dis"
command instead."
(anderson(a)redhat.com)
- Fix for the "mach -m" command in Linux 4.9 and later kernels that
contain commit 475339684ef19e46f4702e2d185a869a5c454688, titled
"x86/e820: Prepare e280 code for switch to dynamic storage", in
which the "e820" symbol was changed from a static e820map structure
to a pointer to an e820map structure. Without the patch, the
command either displays just the header, or the header with several
nonsensical entries.
(anderson(a)redhat.com)
- Fix for Linux 4.10 and later kdump dumpfiles, or kernels that have
backported commit 401721ecd1dcb0a428aa5d6832ee05ffbdbffbbe, titled
"kexec: export the value of phys_base instead of symbol address".
Without the patch, if the x86_64 "phys_base" value in the VMCOREINFO
note is a negative decimal number, the crash session fails during
session intialization with a "page excluded" or "seek error" when
reading "page_offset_base".
(anderson(a)redhat.com)
- Fix for the PPC64 "pte" command. Without the patch, if the target
PTE references a present page, the physical address is incorrect.
(anderson(a)redhat.com)
- Fix for a 32-bit MIPS compilation error if glibc-2.25 or later has
been installed on the host build machine. Without the patch, the
build fails with the error message "mips-linux-nat.c:157:1: error:
conflicting types for 'ps_get_thread_area'".
(dengke.du(a)windriver.com)
- Fix for the validity check of S390X virtual addresses for 5-level
page tables where user space memory is mapped above 8 Petabytes.
Without the patch, "rd -u" fails and indicates "invalid user virtual
address", and "vtop -u" indicates that the address is "(not mapped)".
(zaslonko(a)linux.vnet.ibm.com)
- Crash 7.1.5 commit c3413456599161cabc4e910a0ae91dfe5eec3c21 (xen: Add
support for dom0 with Linux kernel 3.19 and newer) from Daniel Kiper
implemented support for Xen dom0 vmcores after Linux 3.19 kernel
commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to
linear virtual mapped sparse p2m list). This patch can be deemed
subsequent to Daniel's patch, and implements support Xen PV domU
dumpfiles for Linux 3.19 and later kernels.
(honglei.wang@oracle com)
- Fix for the "dis" command to detect duplicate symbols in the case
of a "symbol+offset" argument where the duplicates are not contiguous
in the symbol list. Without the patch, the first of multiple symbol
instances is used in the address evaluation. With the patch, the
command will fail with the error message "dis: <symbol+offset>:
duplicate text symbols found:", followed by a list of the duplicate
symbols, and their file and line numbers if available.
(anderson(a)redhat.com)
- Enhancement to the error reporting mechanism for the "kmem -[sS]"
options. When a fatal error is encountered while gathering basic
CONFIG_SLUB statistics, it is possible that the slab cache name
is not displayed in the error message, and the line containing
the slab cache name, address, etc., is not displayed at all. With
this patch, an extra error message indicating "kmem: <cache-name>:
cannot gather relevant slab data" will be displayed under the
fatal error message; and under that, the CACHE address, cache NAME,
OBJSIZE, and SSIZE columns will be displayed, but with "?" under
the ALLOCATED, TOTAL, and SLABS columns.
(anderson(a)redhat.com)
- Fix to prevent the "tree -t radix" option from failing when it
encounters duplicate entries in a radix_tree_node[slots] array.
Without the patch, if a duplicate slot entry is found, the command
fails with the message "tree: duplicate tree entry: radix_tree_node:
<node address> slots[<index>]: <entry>\n". (The error can
be prevented if the command is preceded by "set hash off".) However,
certain radix trees contain duplicate entries by design, such as the
"pgmap_radix" radix tree, in which a radix_tree_node may contain
multiple instances of the same page_map structure. With the patch,
checks will only be made for duplicate radix_tree_node structures.
(anderson(a)redhat.com)
- First phase of future support for x86_64 5-level page tables. New
sets of virtual memory offsets have been #define'd and helper macros
and placeholder functions for the p4d page tables have been added.
The only functional changes with this patchset are dynamically-set
PGDIR_SHIFT and PHYSICAL_MASK_SHIFT values that are based upon the
kernel configuration.
(anderson(a)redhat.com)
- Fix for a build failure. Without the patch, if the build is done by
a user whose username cannot be determined from the user ID number,
the build fails immediately with a segmentation fault.
(sargun(a)sargun.me, anderson(a)redhat.com)
- Fix for Linux 4.13-rc0 commit 7fd8329ba502ef76dd91db561c7aed696b2c7720
"x86/boot/64: Rename init_level4_pgt and early_level4_pgt". Without
the patch, the crash session fails during initialization with the
error message "crash: cannot resolve "init_level4_pgt".
(anderson(a)redhat.com)
- The internal "build_data" string contains the compile-time date,
the user id of the builder, and the build machine hostname, and is
viewable by the "crash --buildinfo" command line option or by the
"help -B" option during runtime. This patch replaces that string
data with "reproducible build" if the SOURCE_DATE_EPOCH environment
variable contains a value string when the crash binary is compiled.
(bwiedemann(a)suse.de)
- Fix for Linux 4.13-rc1 commit 2d070eab2e8270c8a84d480bb91e4f739315f03d
"mm: consider zone which is not fully populated to have holes".
Without the patch, SPARSEMEM page struct addresses are incorrectly
calculated because a new section state, and an associated flag bit,
has been added to the low bits of the mem_section.section_mem_map
address; the extra bit is erroneously passed back as part of the
section_mem_map and resultant page struct address, leading to
errors in commands such as "kmem -p", "kmem -s", "kmem -n", and any
other command that translates a physical address to its page struct
address.
(anderson(a)redhat.com)
- Enhancement to the S390X "vtop" command to display page table walk
information, adding output showing the following page table contents:
"Region-First-Table Entry" (RFTE)
"Region-Second-Table Entry" (RSTE)
"Region-Third-Table Entry" (RTTE)
"Segment Table Entry" (STE)
"Page Table Entry" (PTE)
"Read address of page" (PAGE)
Depending on the size of the address space, the page tables can start
at different levels. For example:
crash> vtop 3ff8000c000
VIRTUAL PHYSICAL
3ff8000c000 2e3832000
PAGE DIRECTORY: 0000000000aaa000
RTTE: 0000000000aadff8 => 00000002e3c00007
STE: 00000002e3c00000 => 00000002e3df7000
PTE: 00000002e3df7060 => 00000002e383203d
PAGE: 00000002e3832000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
3d10b8e0c80 2e3832000 0 0 1 7fffc0000000000
(holzheu(a)linux.vnet.ibm.com)
- Fix the s390dbf time stamps for S390X kernel versions 4.11 and 4.14.
With kernel commit ea417aa8a38bc7db ("s390/debug: make debug event
time stamps relative to the boot TOD clock") for s390dbf time is
stored relative to the kernel boot time. In order to still show
absolute time since 1970 we have to detect those kernels and re-add
the boot time before printing the records. We can use the
tod_to_timeval() symbol to check for those kernels because the
patch has removed the symbol. With kernel commit 6e2ef5e4f6cc5734
("s390/time: add support for the TOD clock epoch extension")
the symbol name for storing the boot time has changed from
"sched_clock_base_cc" to "tod_clock_base". This commit is currently
on the s390 features branch and will be integrated in Linux 4.14.
(holzheu(a)linux.vnet.ibm.com)
- Further enhancement to the S390X "vtop" command to translate the
binary values of the hardware flags for region, segment and page
table entries. For example:
crash> vtop -u 0x60000000000000
VIRTUAL PHYSICAL
60000000000000 5b50a000
PAGE DIRECTORY: 000000005cea0000
RFTE: 000000005cea0018 => 000000006612400f (flags = 00f)
flags in binary : P=0; TF=00; I=0; TT=11; TL=11
RSTE: 0000000066124000 => 000000005d91800b (flags = 00b)
flags in binary : P=0; TF=00; I=0; TT=10; TL=11
RTTE: 000000005d918000 => 000000006615c007 (flags = 007)
flags in binary : FC=0; P=0; TF=00; I=0; CR=0; TT=01; TL=11
STE: 000000006615c000 => 000000005ce48800 (flags = 800)
flags in binary : FC=0; P=0; I=0; CS=0; TT=00
PTE: 000000005ce48800 => 000000005b50a03f (flags = 03f)
flags in binary : I=0; P=0
PAGE: 000000005b50a000
or for large pages:
crash> vtop -k 0x3d100000000
VIRTUAL PHYSICAL
3d100000000 77c00000
PAGE DIRECTORY: 0000000001210000
RTTE: 0000000001213d10 => 0000000077dc4007 (flags = 007)
flags in binary : FC=0; P=0; TF=00; I=0; CR=0; TT=01; TL=11
STE: 0000000077dc4000 => 0000000077c03403 (flags = 03403)
flags in binary : AV=0, ACC=0011; F=0; FC=1; P=0; I=0; CS=0; TT=00
(zaslonko(a)linux.vnet.ibm.com)
- PPC64 kernel commit 2f18d533757da3899f4bedab0b2c051b080079dc lowered
the max real address to 53 bits. Without this patch, the warning
message "WARNING: cannot access vmalloc'd module memory" appears
during initialization, and any command that attempts to read a
vmalloc'd kernel virtual address will fail and display "read error"
messages.
(hbathini(a)linux.vnet.ibm.com)
- Display the KASLR relocation value warning message whenever it is
in use. Without the patch, the message may not get displayed
if the --kaslr option is used, or if the dumpfile is a vmcore
generated by the current snap.so extension module, which now
exports the relocation value in the header.
(anderson(a)redhat.com)
- Fix to prevent an initialization-time failure when running a live
session on a host system that does not have a "/usr/src" directory.
Without the patch, the session fails with the message "*** Error in
'crash': free(): invalid pointer: <address> ***".
(Lei Chen)
- Fix for the ARM64 "bt" command's display of the user mode exception
frame at the top of the stack in Linux 4.7 and later kernels.
Without the patch, the contents of the user mode exception frame are
invalid due to the miscalculation of the starting address of the
pt_regs structure on the kernel stack.
(anderson(a)redhat.com)
- Integrated support for usage of the Linux 4.14 ORC unwinder by the
x86_64 "bt" command. Kernels configured with CONFIG_ORC_UNWINDER
contain .orc_unwind and .orc_unwind_ip sections that can be queried
to determine the stack frame size of any text address within a kernel
function. For kernels not configured with CONFIG_FRAME_POINTER,
the crash utility does frame size calculation by disassembling a
function from its beginning to the specified text address, counting
the push, pop, and add/sub rsp instructions, accounting for retq
instructions that occur in the middle of a function. With this patch,
access to the new ORC sections has been plugged into the existing
frame size calculator, resulting in a more efficient and accurate
manner of determining frame sizes, and as a result, more accurate
backtraces.
(anderson(a)redhat.com)
- Fix for the ARM64 "bt" command when run against Linux 4.14-rc1.
Without the patch, a message indicating "crash: builtin stackframe.sp
offset incorrect!" is issued during session initialization, and the
"bt" command fails with the error message "bt: invalid structure
member offset: task_struct_thread_context_sp".
(anderson(a)redhat.com)
- For for the "task -R <member>" option on Linux 4.13 and later kernels
where the task_struct contains a "randomized_struct_fields_start" to
"randomized_struct_fields_end" section. Without the patch, a member
argument that is inside the randomized section is not found.
(anderson(a)redhat.com)
- Fix for the "snap.so" extension module to pass the value of the ARM64
"kimage_voffset" value in the ELF header. Without the patch, it is
necessary to use the "--machdep kvimage_offset=<value>" command line
option, or the session fails with the message "crash: vmlinux and
vmcore do not match!".
(anderson(a)redhat.com)
7 years, 1 month
