[PATCH] crash/s390x: Fix CPU timer and clock comparator output for bt -a
by Michael Holzheu
Hello Dave,
The output of CPU timer and clock comparator has always been incorrect
because:
- We added S390X_WORD_SIZE (8) instead of 4 to get the second word
- We did not left shift the clock comparator by 8
So fix this by getting the complete 64 bit values and by shifting the
clock comparator correctly.
Signed-off-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
---
s390x.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/s390x.c
+++ b/s390x.c
@@ -1343,14 +1343,16 @@ s390x_print_lowcore(char* lc, struct bt_
fprintf(fp," -prefix : %#010lx\n", tmp[0]);
ptr = lc + MEMBER_OFFSET(lc_struct, "cpu_timer_save_area");
- tmp[0]=UINT(ptr);
- tmp[1]=UINT(ptr + S390X_WORD_SIZE);
- fprintf(fp," -cpu timer: %#010lx %#010lx\n", tmp[0],tmp[1]);
+ tmp[0]=ULONG(ptr);
+ fprintf(fp," -cpu timer: %#018lx\n", tmp[0]);
ptr = lc + MEMBER_OFFSET(lc_struct, "clock_comp_save_area");
- tmp[0]=UINT(ptr);
- tmp[1]=UINT(ptr + S390X_WORD_SIZE);
- fprintf(fp," -clock cmp: %#010lx %#010lx\n", tmp[0], tmp[1]);
+ /*
+ * Shift clock comparator by 8 because we got bit positions 0-55
+ * in byte 1 to 8. The first byte is always zero.
+ */
+ tmp[0]=ULONG(ptr) << 8;
+ fprintf(fp," -clock cmp: %#018lx\n", tmp[0]);
fprintf(fp," -general registers:\n");
ptr = lc + MEMBER_OFFSET(lc_struct, "gpregs_save_area");
10 years, 2 months
crash 7.0.8 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 handling of 32-bit ELF xendump dumpfiles if the guest
was configured with more than 4GB of memory. Without the patch, the
crash session may fail during initialization with the error message
"crash: vmlinux and <dumpfile> do not match!".
(dslutz(a)verizon.com)
- Fix for file-handling errors when a compressed vmlinux.debug file
is followed by a vmlinux file on the crash command line. When the
crash session ends, two errors will occur:
(1) the vmlinux file will be deleted
(2) the temporary uncompressed version of the vmlinux.debug file
will remain in /var/tmp
This problem also occurs in the highly unlikely case where a
compressed vmlinux file is followed by a vmlinux.debug file on the
command line, and the uncompressed temporary version of the vmlinux
file is larger than the vmlinux.debug file. In that case:
(1) the vmlinux.debug file will be deleted
(2) the temporary uncompressed version of the vmlinux file
will remain in /var/tmp
(dmair(a)suse.com)
- Fix for the "search -t" option if the system has 2064 or more tasks.
Without the patch, the command fails with a dump of the crash utility
memory allocation statistics, ending with "search: cannot allocate
any more memory!".
(anderson(a)redhat.com)
- Fix for the "mod -S" command to find the debuginfo data for Red Hat
"kpatch" modules. Without the patch, the command would display
"mod: cannot find or load object file for <kpatch-module> module".
(anderson(a)redhat.com)
- Deprecated the "mount -f" option for Linux 3.13 and later kernels
containing commit eee5cc2702929fd41cce28058dc6d6717f723f87, which
removed the super_block.s_files list_head member and the open files
list that it contained. Without the patch, the command option fails
with the error message "mount: invalid structure member offset:
super_block_s_files"
(anderson(a)redhat.com)
- If a compressed kdump is damaged/truncated such that the bitmap data
in the dumpfile header is not contained within the file, attempts
to analyze it with a vmlinux file, or using the "crash --osrelease"
or "crash --log" options with just the vmcore, will result in the
crash utility spinning forever, endlessly performing reads of 0 bytes
from the file without recognizing the EOF condition.
(dwysocha(a)redhat.com)
- Fix for an ARM64 compilation failure of the embedded gdb file
"aarch-linux-nat.c" in the Fedora fc21 rawhide environment, which
uses glibc-headers-2.19.90-24.fc21.
(anderson(a)redhat.com)
- Document the reason behind the deprecation of the "mount -f" option
for Linux 3.13 and later kernels if the option is attempted, and in
the "help mount" output, similar to the deprecated "mount -d" option.
(anderson(a)redhat.com)
- During initialization, reject useless ARM64 "(A)" absolute symbols
that begin with "__crc_". Without the patch, several thousand of
them may be displayed by "sym -l" prior to the first kernel virtual
address symbol.
(anderson(a)redhat.com)
- When running against an ARM64 dumpfile created with the "snap.so"
extension module, do not attempt to read the crash_notes. Since the
dumpfile was taken while running on a live system, the crash_notes,
if configured into the kernel, would not contain valid data. Without
the patch, the message "WARNING: could not retrieve crash_notes" is
displayed during session initialization.
(anderson(a)redhat.com)
- Determine the various ARM64 kernel virtual address ranges using the
kernel's VA_BITS value. It currently is hardwired in the kernel to
one of two values depending upon whether 4K or 64K pages are
configured. However, there are plans to support 16K paqes, to make
VA_BITS a configurable value, and to make the number of page-table
levels configurable. Towards that end, the crash utility has been
changed to determine the VA_BITS value based upon known kernel
virtual addresses, and to then calculate the relevant kernel virtual
address ranges on that value instead of hardwiring them based upon
the page size.
(anderson(a)redhat.com)
- Enhancement to the "kmem -S" option for Linux 3.2 and later kernels
configured with CONFIG_SLUB to display the address of each per-cpu
kmem_cache_cpu address and the contents of its per-cpu partial list.
(qiaonuohan(a)cn.fujitsu.com)
- If an ARM or ARM64 dumpfile does not contain the register sets of
the active tasks in the kernel's per-cpu crash_notes, there is an
initialization-time warning message indicating "could not retrieve
crash_notes". It has been changed to a more meaningful warning
message indicating "cannot retrieve registers for active tasks".
(anderson(a)redhat.com)
- Implement support for ARM and ARM64 raw RAM dumpfiles. One or
more "ramdump" files may be entered on the crash command line
in an ordered pair format consisting of the RAM dump filename
and the starting physical address expressed in hexadecimal,
connected with an ampersand:
$ crash vmlinux ramdump@address [ramdump@address]
A temporary ELF header will be created in /var/tmp, and the
combination of the header and the ramdump file(s) will be handled
like a normal ELF vmcore. The ELF header will only exist during
the crash session. If desired, an optional "-o <filename>"
may be entered to create a permanent ELF vmcore file from the
ramdump file(s).
(vinayakm.list(a)gmail.com, paawan1982(a)yahoo.com, anderson(a)redhat.com)
- Fix for the "help -[nD]" ELF header translation to recognize the
EM_ARM and EM_AARCH values as "e_machine" types, and ELFOSABI_LINUX
as an "e_ident[EI_OSABI]" type. Without the patch, the e_machine
translation would show "40 (unsupported)" for 32-bit ARM, or
"183 (unsupported)" on ARM64; and the ELFOSABI_LINUX type would
be translated as "3 (?)".
(anderson(a)redhat.com)
- Re-run a command in the history list by entering an "!" followed by
the number identifying the command. However, unlike the similar "r"
pseudo-command, if the number is a command name in the user's PATH,
maintain the current behavior and execute that command.
(anderson(a)redhat.com)
- Fix to recognize that the live system "crash.ko" memory driver may
be compressed and named "crash.ko.xz". Without the patch, the driver
is not recognized and loaded, and as a result the /dev/mem driver
and/or /proc/kcore will be tried as the live memory source.
(anderson(a)redhat.com)
- On a live system during session initialization, delay the first read
error message (typically when reading the "cpu_possible_mask") until
it is confirmed that all of the following are true:
(1) /dev/crash does not exist, and
(2) /dev/mem is restricted via CONFIG_STRICT_DEVMEM, and
(3) /proc/kcore cannot be read/accessed.
The "kernel may be configured with CONFIG_STRICT_DEVMEM" and
the "trying /proc/kcore as an alternative" messages will still
be displayed when appropriate. The read error message be displayed
only if all three live memory read options fail.
(anderson(a)redhat.com)
- Fortify the validity verification of the data structures traversed
by the "kmem [-sS]" options for kernels configured with CONFIG_SLUB.
Without the patch, the contents of several structure members are not
validated, and may generate bogus or never-ending output, typically
seen when running the commands on a "live dump" where the dumpfile
was taken while the kernel was still running. The patch aborts the
relevant parts of per-kmem_cache output when invalid data is
encountered or if an object list contains duplicate entries, and
error messages have been enhanced to more accurately describe the
issues encountered.
(anderson(a)redhat.com)
- Implement support for the ppc64le PPC64 little-endian architecture.
Since this required a large number of patches to be applied to
architecture-neutral files in the gdb-7.6 tree, the changes are
only applied if the host build system is a ppc64le.
(ptesarik(a)suse.cz, normand(a)linux.vnet.ibm.com)
- Fix for SMP active task register-gathering from "kvmdump" dumpfiles
that were created with a cpu version id of 12 or greater that contain
additional XSAVE related fields in their cpu device headers. Without
the patch, active tasks running on cpus above 0 may have truncated
backtraces.
(uobergfe(a)redhat.com)
- Maintain backwards-compatibility for "kvmdump" dumpfiles that were
created by older development versions of KVM tools in which the
cpu version id was 12, but the cpu device headers did not contain
the additional XSAVE related fields.
(uobergfe(a)redhat.com)
- Address a "ps" command performance degradation that was introduced by
a crash-7.0.4 patch which added per-thread task_struct.rss_stat page
counts to the task's mm_struct.rss_stat page counts in order to show
an accurate/synchronized RSS value. Without the patch, the "ps"
command performance would degrade as the number of tasks increased,
most notably when there were thousands of tasks.
(panfy.fnst(a)cn.fujitsu.com, anderson(a)redhat.com)
10 years, 2 months
[PATCH] crash-gcore-command extension module: ARM64 support
by Dave Anderson
Hello Daisuke,
Attached is a patch to introduce support for the ARM64 architecture
for the gcore extension module.
The patch is fairly straight-forward other than the fact that on
ARM64 machines, the chain of headers included from the crash utility's
"defs.h" looks like this:
/usr/include/crash/defs.h
/usr/include/signal.h
/usr/include/sys/ucontext.h
/usr/include/sys/procfs.h
The <sys/procfs.h> file defines several of the ELF-related structures that
are hard-coded in gcore_defs.h, causing compile failures due to duplicate
structure declarations.
Note that the <sys/ucontext.h> file on the other three architectures does
not #include <sys/procfs.h> so there are no conflicts. It would be possible
to move all architectures to include <sys/procfs.h>, but for example, that
would also bring in the <sys/user.h> definition of the user_regs_struct,
which in turn causes a myriad of register name mismatches in gcore_x86.c.
So for the sake of simplicity, wherever there is an ARM64-only duplicate
structure or definition in gcore_defs.h, I've encapsulated them by:
#if defined(X86) || defined(X86_64) || defined(ARM)
Also, there are two generic fixes, one where the gcore module fails on
Linux 3.11 and later kernels due to a structure member name change,
and another that changes the getopt() return variable to an "int" instead
of a "char".
Here are the details:
gcore.mk:
- Introduce ARM64 as a supported architecture
- Add libgcore/gcore_arm64 to GCORE_CFILES
gcore.c:
- In cmd_gcore() change "c" type to "int" to correctly match
the return type of getopt(); without it, the while loop
spins indefinitely on ARM64.
- In gcore_offset_table_init(), account for the Linux 3.11
structure member name-change from ns_proxy.pid_ns to
ns_proxy.pid_ns_for_children; without it, the gcore command
fails during initialization.
libgcore/gcore_defs.h:
- Add ARM64 ELF- and REGSET_VIEW-related #defines required for
each architecture.
- Account for variable page sizes in ARM64.
- Restrict the hard-coded ELF_NGREG, elf_siginfo, elf_prstatus,
__kernel_old_uid_t and __kernel_old_gid_t, and elf_prsinfo
definitions to X86, X86_64 and ARM architectures.
- Add ARM64 thread_struct_fpsmid_state and thread_struct_tp_value
offsets to gcore_offset_table.
libgcore/gcore_coredump.c:
- In fill_prstatus_note(), account for the ARM64 usage of
"user_pt_regs" structure instead of the "user_regs_struct"
used by the other architectures.
libgcore/gcore_arm64.c:
- Implement ARM64-specific user_regset and user_regset_view
structures and all required support functions.
Please accept these changes into an new package version.
Thanks,
Dave
10 years, 2 months
Re: [Crash-utility] Heads-up re: ppc64le support in crash-7.0.8
by Dave Anderson
Petr,
Are the sources different the openSUSE patches?
Dave
Sent from my Verizon Wireless 4G LTE smartphone
<div>-------- Original message --------</div><div>From: Petr Tesarik <ptesarik(a)suse.cz> </div><div>Date:09/04/2014 12:27 PM (GMT-05:00) </div><div>To: Dave Anderson <anderson(a)redhat.com> </div><div>Cc: "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com> </div><div>Subject: Re: [Crash-utility] Heads-up re: ppc64le support in crash-7.0.8 </div><div>
</div>On Thu, 4 Sep 2014 12:19:15 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
> Petr, Michel, et al,
Hi Dave et al.,
FWIW the upcoming SUSE Linux Enterprise Server 12 release will ship a
crash utility that works on ppc64le, and I think IBM has already tested
it successfully. I'll see how I can make the latest sources available on
a public site.
Petr Tesarik
> I'm currently working on adding ppc64le support for the next upstream
> crash release. I'm working from a Fedora bugzilla filed by Michel Normand,
> where he that applied the "crash-gdb-7.6.series" set of patches from the openSUSE
> distribution. Thanks Michel for doing the initial legwork using the Fedora
> tree.
>
> For the upstream crash utility repo, I do not want to carry the set of 9 patches
> individually, but similar to the singular gdb-7.6.patch, I plan to concatenate
> them into a singular gdb-7.6-ppc64le-support.patch.
>
> Ideally the contents of the 9 patch files could be added to the gdb-7.6.patch,
> and I may do that in the future.
>
> However, just the crash-gdb-7.6-bound_minimal_symbol.patch in the 9-part set
> is so large and intrusive (touching dozens of arch-neutral files) that
> I am paranoid about breaking something, or altering behavior for the
> other architectures. So I plan to take a more cautious route for now,
> and only apply the gdb-7.6-ppc64le-support.patch if the build host is
> ppc64le.
>
> Thanks,
> Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
10 years, 2 months
Heads-up re: ppc64le support in crash-7.0.8
by Dave Anderson
Petr, Michel, et al,
I'm currently working on adding ppc64le support for the next upstream
crash release. I'm working from a Fedora bugzilla filed by Michel Normand,
where he that applied the "crash-gdb-7.6.series" set of patches from the openSUSE
distribution. Thanks Michel for doing the initial legwork using the Fedora
tree.
For the upstream crash utility repo, I do not want to carry the set of 9 patches
individually, but similar to the singular gdb-7.6.patch, I plan to concatenate
them into a singular gdb-7.6-ppc64le-support.patch.
Ideally the contents of the 9 patch files could be added to the gdb-7.6.patch,
and I may do that in the future.
However, just the crash-gdb-7.6-bound_minimal_symbol.patch in the 9-part set
is so large and intrusive (touching dozens of arch-neutral files) that
I am paranoid about breaking something, or altering behavior for the
other architectures. So I plan to take a more cautious route for now,
and only apply the gdb-7.6-ppc64le-support.patch if the build host is
ppc64le.
Thanks,
Dave
10 years, 2 months
