[PATCH] crash: ARM: fix bug on paddr_to_pfn converting
by Liu Hua
Hi Dave,
When parsing vmcore generated by ARM linux, Crash utility does
"phys to pfn" converting using this:
" (paddr - machdep->machspec->phys_base) >> dd->block_shift;"
First it minuses offset of the memory, and then does right shift.
But I glanced over kernel codes(2.6.34 - 3.15). I found nothing
to support the rationality of this type converting for ARM linux.
And without this patch, the crash utility can not parse my vmcores.
Also I can not get the commit messages because this code added before
crash-7.0.4. So, What's your purpose to introduce this? Is this patch
necessary for crash utility ? Or should I do some addtional work for
compatibility?
(BTW,makedumpfile also has this type problem.)
Thanks,
Liu Hua
Signed-off-by: Liu Hua <sdu.liu(a)huawei.com>
---
diskdump.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/diskdump.c b/diskdump.c
index e230c1f..1d72364 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -914,15 +914,7 @@ page_is_cached(physaddr_t paddr)
static ulong
paddr_to_pfn(physaddr_t paddr)
{
-#ifdef ARM
- /*
- * In ARM, PFN 0 means first page in kernel direct-mapped view.
- * This is also first page in mem_map as well.
- */
- return (paddr - machdep->machspec->phys_base) >> dd->block_shift;
-#else
return paddr >> dd->block_shift;
-#endif
}
/*
--
1.9.0
10 years, 2 months
[PATCH v2 0/4] some bugfixs for ARM
by Liu Hua
Hi Dave,
In this patch series, I introduce support for cpu_active_mask.
And I use MAX(get_cpus_online(),get_cpus_active()) to get CPU
number for ARM platform.
The last patch changes NR_CPUS to fit ARM linux's config.
Thanks,
Liu Hua
changes from v1:
-----------------------------------------------
-changed some macros related to cpu map
-use MAX(get_cpus_online(),get_cpus_active()) as online CPU
number
Liu Hua (4):
crash: change some marcos related to cpu map
crash: support cpu_active_mask
crash: ARM: get online CPUs from cpu_active_mask
crash: ARM: change NR_CPUS to 32
arm.c | 2 +-
defs.h | 12 +++++-----
diskdump.c | 4 ++--
kernel.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++----------
netdump.c | 4 ++--
ppc.c | 2 +-
ppc64.c | 14 +++++++-----
s390.c | 4 ++--
s390x.c | 4 ++--
9 files changed, 89 insertions(+), 33 deletions(-)
--
1.9.0
10 years, 2 months
[PATCH] Make bt -a accept a CPU as an argument
by Aaron Tomlin
Currently 'bt -a' displays the stack traces of the active task on each
CPU. This patch makes it possible to specify a CPU as an argument.
Multiple CPU arguments may be specified. If no argument is given
the default behaviour is maintained.
For example:
Display the stack trace of the active task on CPU 0 and 1:
crash> bt -a 0 1
PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
#0 [ffff880002207e90] crash_nmi_callback at ffffffff8102fee6
#1 [ffff880002207ea0] notifier_call_chain at ffffffff8152d525
#2 [ffff880002207ee0] atomic_notifier_call_chain at ffffffff8152d58a
#3 [ffff880002207ef0] notify_die at ffffffff810a155e
#4 [ffff880002207f20] do_nmi at ffffffff8152b1eb
#5 [ffff880002207f50] nmi at ffffffff8152aab0
[exception RIP: native_safe_halt+0xb]
RIP: ffffffff8103eacb RSP: ffffffff81a01ea8 RFLAGS: 00000296
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff81de5228
RBP: ffffffff81a01ea8 R8: 0000000000000000 R9: 0000000000000000
R10: 0012099429a6bea3 R11: 0000000000000000 R12: ffffffff81c066c0
R13: 0000000000000000 R14: ffffffffffffffff R15: ffffffff81de1000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <NMI exception stack> ---
#6 [ffffffff81a01ea8] native_safe_halt at ffffffff8103eacb
#7 [ffffffff81a01eb0] default_idle at ffffffff810167bd
#8 [ffffffff81a01ed0] cpu_idle at ffffffff81009fc6
PID: 38 TASK: ffff88003eaae040 CPU: 1 COMMAND: "khungtaskd"
#0 [ffff88003ad97ce8] machine_kexec at ffffffff81038f3b
#1 [ffff88003ad97d48] crash_kexec at ffffffff810c5da2
#2 [ffff88003ad97e18] panic at ffffffff8152721a
#3 [ffff88003ad97e98] watchdog at ffffffff810e6346
#4 [ffff88003ad97ee8] kthread at ffffffff8109af06
#5 [ffff88003ad97f48] kernel_thread at ffffffff8100c20a
Signed-off-by: Aaron Tomlin <atomlin(a)redhat.com>
---
help.c | 37 ++++++++++++++++++++++++++++++++++---
kernel.c | 26 +++++++++++++++++++++++---
2 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/help.c b/help.c
index 91f22c3..62af23a 100644
--- a/help.c
+++ b/help.c
@@ -1704,11 +1704,13 @@ NULL
char *help_bt[] = {
"bt",
"backtrace",
-"[-a|-g|-r|-t|-T|-l|-e|-E|-f|-F|-o|-O] [-R ref] [-s [-x|d]] [-I ip] [-S sp]"
+"[-a [cpu]|-g|-r|-t|-T|-l|-e|-E|-f|-F|-o|-O] [-R ref] [-s [-x|d]] [-I ip] [-S sp]"
"\n [pid | task]",
" Display a kernel stack backtrace. If no arguments are given, the stack",
" trace of the current context will be displayed.\n",
-" -a displays the stack traces of the active task on each CPU.",
+" -a display the stack trace of the active task on a given CPU.",
+" Multiple CPU arguments may be specified. If no arguments are given",
+" the stack trace of the active task on each CPU is shown.",
" (only applicable to crash dumps)",
#ifdef GDB_5_3
" -g use gdb stack trace code. (alpha only)",
@@ -1766,7 +1768,36 @@ char *help_bt[] = {
" or display a stale frame reference. When in doubt as to the accuracy of a",
" backtrace, the -t or -T options may help fill in the blanks.\n",
"EXAMPLES",
-" Display the stack trace of the active task(s) when the kernel panicked:\n",
+" Display the stack trace of the active task on CPU 0 and 1:\n",
+" %s> bt -a 0 1",
+" PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: \"swapper\"",
+" #0 [ffff880002207e90] crash_nmi_callback at ffffffff8102fee6",
+" #1 [ffff880002207ea0] notifier_call_chain at ffffffff8152d525",
+" #2 [ffff880002207ee0] atomic_notifier_call_chain at ffffffff8152d58a",
+" #3 [ffff880002207ef0] notify_die at ffffffff810a155e",
+" #4 [ffff880002207f20] do_nmi at ffffffff8152b1eb",
+" #5 [ffff880002207f50] nmi at ffffffff8152aab0",
+" [exception RIP: native_safe_halt+0xb]",
+" RIP: ffffffff8103eacb RSP: ffffffff81a01ea8 RFLAGS: 00000296",
+" RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000",
+" RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff81de5228",
+" RBP: ffffffff81a01ea8 R8: 0000000000000000 R9: 0000000000000000",
+" R10: 0012099429a6bea3 R11: 0000000000000000 R12: ffffffff81c066c0",
+" R13: 0000000000000000 R14: ffffffffffffffff R15: ffffffff81de1000",
+" ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018",
+" --- <NMI exception stack> ---",
+" #6 [ffffffff81a01ea8] native_safe_halt at ffffffff8103eacb",
+" #7 [ffffffff81a01eb0] default_idle at ffffffff810167bd",
+" #8 [ffffffff81a01ed0] cpu_idle at ffffffff81009fc6",
+" ",
+" PID: 38 TASK: ffff88003eaae040 CPU: 1 COMMAND: \"khungtaskd\"",
+" #0 [ffff88003ad97ce8] machine_kexec at ffffffff81038f3b",
+" #1 [ffff88003ad97d48] crash_kexec at ffffffff810c5da2",
+" #2 [ffff88003ad97e18] panic at ffffffff8152721a",
+" #3 [ffff88003ad97e98] watchdog at ffffffff810e6346",
+" #4 [ffff88003ad97ee8] kthread at ffffffff8109af06",
+" #5 [ffff88003ad97f48] kernel_thread at ffffffff8100c20a",
+"\n Display the stack trace of the active task(s) when the kernel panicked:\n",
" %s> bt -a",
" PID: 286 TASK: c0b3a000 CPU: 0 COMMAND: \"in.rlogind\"",
" #0 [c0b3be90] crash_save_current_state at c011aed0",
diff --git a/kernel.c b/kernel.c
index cdc53eb..6b3e25b 100644
--- a/kernel.c
+++ b/kernel.c
@@ -1972,15 +1972,15 @@ cmd_bt(void)
int i, c;
ulong value;
struct task_context *tc;
- int count, subsequent, active;
+ int count, subsequent, active, cpu;
struct stack_hook hook;
struct bt_info bt_info, bt_setup, *bt;
struct reference reference;
char *refptr;
- ulong tgid;
+ ulong tgid, task;
tc = NULL;
- subsequent = active = count = 0;
+ subsequent = active = count = cpu = 0;
hook.eip = hook.esp = 0;
refptr = 0;
bt = &bt_info;
@@ -2232,6 +2232,26 @@ cmd_bt(void)
error(FATAL,
"-a option cannot be used with the -g option\n");
+ while (args[optind]) {
+ cpu = dtoi(args[optind], FAULT_ON_ERROR, NULL);
+ if (cpu >= kt->cpus) {
+ error(FATAL, "invalid cpu number: system has only %d cpu%s\n",
+ kt->cpus, kt->cpus > 1 ? "s" : "");
+ return;
+ }
+ if ((task = get_active_task(cpu)))
+ tc = task_to_context(task);
+ else {
+ error(FATAL, "cannot determine active task on cpu %ld\n", cpu);
+ return;
+ }
+ DO_TASK_BACKTRACE();
+
+ optind++;
+ if (!args[optind])
+ return;
+ }
+
for (c = 0; c < NR_CPUS; c++) {
if (setjmp(pc->foreach_loop_env)) {
pc->flags &= ~IN_FOREACH;
--
1.9.0
10 years, 2 months
[PATCH 0/3] some bugfix for ARM platform
by Liu Hua
Hi Dave,
When using crash utility to parse vmcores generated by ARM
linux. It could not work as what I excepted.
So I fix the following bugs.
The first and second make crash know the number of "online"
CPUs. And the third makes it support more CPUS.
Thanks,
Liu HUa
Liu Hua (3):
crash: add fuction get_cpus_active
crash: ARM: get online CPUs from cpu_active_mask
crash: ARM : change NR_CPUS to 32
arm.c | 2 +-
defs.h | 3 ++-
kernel.c | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 2 deletions(-)
--
1.9.0
10 years, 2 months
[PATCH] extension: get socket receive queue into a file
by Qiao Nuohan
syslog() can be used to send messages to the system logger, and a socket is
used to do the deliverying. So such a situation may be existed that the message
is sent to the socket, but not received by syslogd yet. This module is used to
dump the messages left in the socket.
This module has been tested on RHEL5/6 x86/x64. The following program is used
to generate a kdump core that got log messages left in socket.
1. compile the following c program to a.out
<cut>
int main(int argc, char **argv)
{
char buf[256];
int i = 0;
for (i = 0; i < 1; i++) {
openlog("syslog", LOG_CONS , 0);
sprintf(buf, "[TEST] a very long test message is appropriate, but I do "
"not know such a message (No.%d)\n", i);
syslog(LOG_INFO, buf);
closelog();
}
return 0;
}
<cut>
2. run the following bash code to panic and generate a kdump core
<cut>
i=0
while [[ $i -lt 1000 ]];do
./a.out &
echo $i
i=$((i+1))
done
echo c > /proc/sysrq-trigger
i=0
while [[ $i -lt 1000 ]];do
./a.out &
echo $i
i=$((i+1))
done
<cut>
3. run crash with the vmcore generated in step 2 and load sockq module. Then
run command like below to get left log message
<cut>
crash> ps | grep syslog
1121 1 0 ffff880037ac2080 IN 0.2 249080 1740 rsyslogd
1123 1 1 ffff880037a00040 RU 0.2 249080 1740 rsyslogd
1124 1 1 ffff8800375f9540 IN 0.2 249080 1740 rsyslogd
crash> files 1121
PID: 1121 TASK: ffff880037ac2080 CPU: 0 COMMAND: "rsyslogd"
ROOT: / CWD: /
FD FILE DENTRY INODE TYPE PATH
0 ffff88003e0d0b40 ffff88003ef29a80 ffff88003ef8c688 SOCK
1 ffff88003d8f1140 ffff88003efc3800 ffff88003d3d44c0 REG /var/log/messages
2 ffff88003d859180 ffff88003efadb40 ffff88003d3d40c0 REG /var/log/secure
3 ffff88003d8590c0 ffff88003ef29b40 ffff88003ef917f8 REG /proc/kmsg
4 ffff88003dfd1b40 ffff88003d1a7500 ffff88003d004cc0 REG /var/log/maillog
5 ffff88003dee7180 ffff88003d0b6980 ffff88003d0048c0 REG /var/log/cron
crash> sockq ffff88003e0d0b40 out
crash> cat out
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.48)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.44)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.12)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.13)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.21)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.21)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.18)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.1)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.18)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.18)
<14>Apr 17 16:32:56 syslog: [TEST] a very long test message is appropriate, but I do not know such a message (No.2)
crash>
<cut>
Signed-off-by: Qiao Nuohan <qiaonuohan(a)cn.fujitsu.com>
---
extensions/sockq.c | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 203 insertions(+)
create mode 100644 extensions/sockq.c
diff --git a/extensions/sockq.c b/extensions/sockq.c
new file mode 100644
index 0000000..3784413
--- /dev/null
+++ b/extensions/sockq.c
@@ -0,0 +1,203 @@
+/* sockq.c - sockq extension module for crash
+ *
+ * Copyright (C) 2014 FUJITSU LIMITED
+ * Author: Qiao Nuohan <qiaonuohan(a)cn.fujitsu.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "defs.h" /* From the crash source top-level directory */
+
+void sockq_init(void); /* constructor function */
+void sockq_fini(void); /* destructor function (optional) */
+
+void cmd_sockq(void); /* Declare the commands and their help data. */
+char *help_sockq[];
+
+static struct command_table_entry command_table[] = {
+ { "sockq", cmd_sockq, help_sockq, 0}, /* One or more commands, */
+ { NULL }, /* terminated by NULL, */
+};
+
+char *help_sockq[] = {
+"sockq", /* command name */
+"get socket receive queue into a file", /* short description */
+"file_address outfile", /* argument synopsis */
+
+" This command gets the data from the socket receive queue.",
+" ",
+" file_address A hexadecimal value of socket's file structure address.",
+" outfile A name of output file. If the file already exists,",
+" it is overwritten.",
+NULL
+};
+
+void __attribute__((constructor))
+sockq_init(void) /* Register the command set. */
+{
+ register_extension(command_table);
+}
+
+/*
+ * This function is called if the shared object is unloaded.
+ * If desired, perform any cleanups here.
+ */
+void __attribute__((destructor))
+sockq_fini(void) { }
+
+static int
+get_member_data(ulonglong addr, char *name, char *member, void* buf)
+{
+ ulong member_offset;
+
+ member_offset = MEMBER_OFFSET(name, member);
+
+ if (!readmem(addr + member_offset, KVADDR, buf,
+ MEMBER_SIZE(name, member), name, FAULT_ON_ERROR))
+ return FALSE;
+
+ return TRUE;
+}
+
+/*
+ * write receive data in the specified file
+ */
+static int
+write_data(int fd, char *buf, ulong addr, ulong size)
+{
+ ulong wsize;
+
+ while (size > 0) {
+ /* size of the buffer is pagesize */
+ wsize = (size > PAGESIZE()) ? PAGESIZE() : size;
+
+ if (!readmem(addr, KVADDR, buf, wsize, "vaddr", FAULT_ON_ERROR)) {
+ fprintf(fp, "cannot read data from packet buffer\n");
+ return 1;
+ }
+
+ if (write(fd, buf, wsize) < 0) {
+ fprintf(fp, "cannot write data in a file\n");
+ return 1;
+ }
+
+ addr += wsize;
+ size -= wsize;
+ }
+
+ return 0;
+}
+
+int
+do_sockq(ulong file_addr, char *output_file, int fd)
+{
+ int rc = 1;
+ ulong pd, sk;
+ uint qlen;
+ char *buf = NULL;
+ ulong next, head;
+ unsigned int len;
+ ulong wnext;
+
+ if (!get_member_data(file_addr, "file", "private_data", &pd)) {
+ fprintf(fp, "cannot get private_datad of file structure\n");
+ goto cleanup;
+ }
+
+ if (!get_member_data(pd, "socket", "sk", &sk)) {
+ fprintf(fp, "cannot get sk of socket structure\n");
+ goto cleanup;
+ }
+
+ if (!get_member_data(sk + MEMBER_OFFSET("sock", "sk_receive_queue"),
+ "sk_buff_head", "next", &next)) {
+ fprintf(fp, "cannot get the first queue of sock structure\n");
+ goto cleanup;
+ }
+
+ if (!get_member_data(sk + MEMBER_OFFSET("sock", "sk_receive_queue"),
+ "sk_buff_head", "qlen", &qlen)) {
+ fprintf(fp, "cannot get the number of queue list\n");
+ goto cleanup;
+ }
+
+ /* create a output file */
+ if (output_file != NULL &&
+ (fd = open(output_file,
+ O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR)) < 0) {
+ fprintf(fp, "cannot create %s\n", output_file);
+ goto cleanup;
+ }
+
+ if (qlen == 0) {
+ /* receive queue is empty */
+ rc = 0;
+ goto cleanup;
+ }
+
+ /* get work area */
+ buf = GETBUF(PAGESIZE());
+
+ while (qlen-- > 0) {
+ /* get packet buffer are info */
+ if (!get_member_data(next, "sk_buff", "head", &head)) {
+ fprintf(fp, "cannot head of sk_buff structure\n");
+ goto cleanup;
+ }
+
+ if (!get_member_data(next, "sk_buff", "len", &len)) {
+ fprintf(fp, "cannot tail of sk_buff structure\n");
+ goto cleanup;
+ }
+
+ /* write data in the output file */
+ if (write_data(fd, buf, head, len))
+ goto cleanup;
+
+ /* next receive queue */
+ wnext = next;
+ if (!get_member_data(wnext, "sk_buff", "next", &next)) {
+ fprintf(fp, "cannot get next of sk_buff structure\n");
+ goto cleanup;
+ }
+ }
+
+ /* all process normally ends */
+ rc = 0;
+
+cleanup:
+ if (output_file != NULL)
+ close(fd);
+ if (buf)
+ FREEBUF(buf);
+
+ return rc;
+}
+
+void
+cmd_sockq(void)
+{
+ ulong file_addr;
+
+ if (argcnt != 3)
+ cmd_usage(pc->curcmd, SYNOPSIS);
+
+ optind++;
+ file_addr = htol(args[optind], FAULT_ON_ERROR, NULL);
+
+ optind++;
+ if (strlen(args[optind]) > PATH_MAX) {
+ fprintf(fp, "cannot create specified output file\n");
+ return;
+ }
+
+ do_sockq(file_addr, args[optind], -1);
+}
--
1.8.5.3
10 years, 2 months
[ANNOUNCE] crash 7.0.6 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
Note that the github "crash-crash-..." tar/zip file naming issue has been
fixed with this release.
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
It should also be noted that although the initial ARM64 support was put
in place back in the crash-7.0.1 timeframe, this is the first release
that has been developed/tested on actual ARM64 hardware. As a result,
almost half of the following crash-7.0.6 patches are ARM64-related.
Changelog:
- Fix for custom X86_64 kernels that change the declaration of the
context_switch() function so that it is not an inline function.
Without the patch, the message "crash: cannot determine thread return
address" is displayed during invocation, and backtraces of blocked
tasks may have missing or invalid frames.
(ahonig(a)google.com)
- Fix to prevent a possible invocation-time error on Linux 3.7 and
later kernels configured with CONFIG_SLAB, running against vmcore
files filtered with the makedumpfile(8) facility. Without the
patch, the message "crash: page excluded: kernel virtual address:
<address> type: kmem_cache buffer" is immediately followed by
the message "crash: unable to initialize kmem slab cache subsystem".
Because of a kernel data structure name change from "cache_cache" to
"kmem_cache_boot", the crash utility failed to properly downsize
the stored size of the kernel's kmem_cache data structure from the
size indicated by the vmlinux debuginfo data. This in turn could
lead to reading beyond the end of a kmem_cache data structure into
a page of memory that had been excluded from the vmcore. The fix
was also applied to kernels configured with CONFIG_SLUB.
(anderson(a)redhat.com)
- Added a new "--kaslr <offset>" command line option for X86_64
kernels that are configured with CONFIG_RANDOMIZE_BASE. The offset
value must be equal to the difference between the symbol values
compiled into the vmlinux file and their relocated KASLR values.
(ahonig(a)google.com, anderson(a)redhat.com)
- Added a new "--kaslr=auto" command line option for X86_64 kernels
that that are configured with CONFIG_RANDOMIZE_BASE. When set to
"auto", the KASLR relocation value will be determined automatically
by comparing the "_stext" symbol value compiled into the vmlinux file
with the _stext symbol value stored in kdump vmcoreinfo data; on live
systems the comparison will be made with the "_stext" symbol value
that is found in /proc/kallsyms.
(ahonig(a)google.com, anderson(a)redhat.com)
- Enable kernel text line number capability for the "dis -l", "bt -l",
"sys -c", and "sym" commands for kernels that are configured with
CONFIG_RANDOMIZE_BASE.
(anderson(a)redhat.com)
- Fix for the "crash --log vmcore" command to account for the kernel
data structure and VMCOREINFO string name changes from "log" to
"printk_log" in Linux 3.11-rc4 and later kernels. Without the patch,
the command fails with the error message "crash: VMCOREINFO: no log
buffer data".
(anderson(a)redhat.com)
- Adjustment to the internal symbol-handling to prevent the usage of
kernel system call alias/wrapper names, for examples, "SyS_read" and
"compat_SyS_futex" instead of "sys_read" and "compat_sys_futex".
Without the patch, commands such as "dis", "sym <address>", and
"sys -c" display the alias/wrapper name instead of the real system
call name in Linux 3.10 and later kernels.
(anderson(a)redhat.com)
- Increase the internal hash queue head count from 128 to 32768.
The hash queue is used for gathering and verifying lists, and the
original count of 128 may be overwhelmed if a list is extremely
large. For example, on a 256GB system with 192GB of free pages,
the "kmem -f" command takes hours to complete; with this patch,
the time is reduced to a few minutes. In addition, a new command
line option "--hash <count>" has been added to allow a user to
override the default hash queue head count of 32768.
(anderson(a)redhat.com)
- Fix for the "kmem -F" display and the "kmem -f <address>" or
"kmem <address>" options. Without the patch, "kmem -F" does
not display the first page in a list of free page blocks on its own
line, but rather at the end of the previous line that shows the area
number, block size, and free_area struct address that the page is
linked to. Due to this error, both "kmem -f <address>" and
"kmem -f address>" would not find the associated page or page block
if it happened to be the first page or page block in the list.
(anderson(a)redhat.com)
- Created a new feature for the internal do_list() function if it
is necessary to immediately perform a function for each entry in a
list while the list is being traversed. A callback function, and an
option callback data pointer, can be registered in the list_data
structure. The address of each entry in the list along with the
optional callback data pointer will be passed to the callback
function. If desired, the callback function may also dictate that
do_list() should stop the list traversal and return immediately to
its caller.
(anderson(a)redhat.com)
- Made the "kmem -f <address>" and "kmem <address>" options more
efficient by using the new do_list() callback function feature above
as well as restricting the search to only the NUMA node that contains
the address.
(anderson(a)redhat.com)
- If the first assembly language instruction in an X86_64 function is
"nopl 0x0(%rax,%rax,1)" or "data32 data32 data32 xchg %ax,%ax",
which are generated when the ftrace facility is configured, the
X86_64 "dis" command will append "[FTRACE NOP]" to the line.
(anderson(a)redhat.com)
- Correction for the "crash -h" and crash.8 man page documentation of
the "--machdep phys_base=<physical-address>" command line option.
In both places the parameter mistakenly indicated "physbase".
(ptesarik(a)suse.cz)
- If a host build system does not have /usr/bin/wget installed, and
the crash package is built from a directory that was git-cloned
from github.com/crash-utility/crash.git, the error message has
been clarified to indicate "/usr/bin/wget is required to download
gdb-7.6.tar.gz". Without the patch, the message indicates "tar
(child): gdb-7.6.tar.gz: Cannot open: No such file or directory".
(anderson(a)redhat.com)
- Updated the ARM64 implementation to support Linux 3.13 and later
kernels that expand to a 42-bit address space when 64K pages are
configured. This is also the first crash version that has been
tested on a live ARM64 system with 4K pages, where it cleanly
make it to the "crash>" prompt. However, it should be noted that
some commands (most notably "bt") still do not work as of yet.
(anderson(a)redhat.com)
- Document the "--machdep phys_offset=<physical-address>" command
line option for the ARM64 architecture in the crash.8 man page and
the "crash -h" output.
(anderson(a)redhat.com)
- Fix for KVM dumpfiles created with "virsh dump --memory-only" if
an X86_64 kernel was loaded with a non-zero "phys_base". Without
the patch, the crash session fails with the warning message "WARNING:
cannot read linux_banner string" followed by the fatal error message
"crash: vmlinux and <dumpfile name> do not match!".
(anderson(a)redhat.com)
- Initial working implementation of the basic ARM64 "bt" command, with
several command options still under development. In-kernel exception
frames are only dumped if the exception handler function is contained
within the symbol boundaries from "__exception_text_start" to
"__exception_text_end"; when ARM64 kdump is eventually implemented,
further exception-related work will be resumed.
(anderson(a)redhat.com)
- Cleaned up the exception frame displays of 64-bit in-kernel and both
32-bit and 64-bit user-mode exceptions.
(anderson(a)redhat.com)
- Implemented support for the ARM64 "bt -e" option.
(anderson(a)redhat.com)
- Implemented support for the ARM64 "bt -l" option.
(anderson(a)redhat.com)
- Update for the X86_64 "bt -l" option such that it also displays the
available file and line number information for functions indicated as
the "exception RIP" in kernel exception frames. The line number
information will follow the exception frame register dump.
(anderson(a)redhat.com)
- Fix for the ARM64 virtual-to-physical translation of vmemmap page
structure addresses for kernels configured with 4K pages. Without
the patch, any command that required the contents of a page structure
would fail with a readmem error.
(cldu(a)marvell.com, anderson(a)redhat.com)
- Added support for the ARM64 architecture in the extensions/snap.c
extension module. Also fixed the progress percentage display to
correct for systems which have non-zero starting physical addresses.
(anderson(a)redhat.com)
- Implemented support for the ARM64 "bt -f" and "bt -F[F]" options.
(anderson(a)redhat.com)
- Increase the ARM64 PTRS_PER_PGD_L2_64K from 1024 to 9182 to account
for the Linux 3.13 increase of the ARM64 virtual address space size
from 39 to 42 bits when 64K pages are configured. Without the patch,
the warning message "WARNING: cannot access vmalloc'd module memory"
is displayed during session initialization.
(anderson(a)redhat.com)
- Fix for the "vm -p" option on ARM64 so that file-backed pages are
properly translated to the filename and offset. Without the patch,
file-backed pages are erroneously shown as being backed on a swap
device.
(anderson(a)redhat.com)
- Increment maximum ARM64 physical address from 40 to 48 bits to match
upstream kernel commit 87366d8cf7b3f6dc34633938aa8766e5a390ce33.
(anderson(a)redhat.com)
- Fix for a segmentation violation generated by the "crash -g vmlinux"
command on ARM64.
(anderson(a)redhat.com)
- Fix for the ARM64 "vtop <address>" command on kernels configured
with 64K pages if the address argument is located in the kernel
logical memory map region, which uses 512MB hugepage mappings.
Without the patch, the verbose page table walk mistakenly continues
to the PTE level.
(anderson(a)redhat.com)
- Fix for ARM64 /proc/kcore support. Without the patch, the crash
session fails with the warning message "WARNING: cannot read
linux_banner string" followed by the fatal error message "crash:
vmlinux and <dumpfile name> do not match!". At this point in
time, the kernel requires a patch to the ARM64 kern_addr_valid()
function to properly allow memory to be read from the kernel logical
memory map region.
(anderson(a)redhat.com)
10 years, 2 months
Re: [Crash-utility] [PATCH 0/3] add LPAE support for kexec and kernel (Liu Hua)
by Dave Anderson
----- Original Message -----
> The patch series introduce LPAE support for user space
> utility kexec(the last) and ARM linux kernel(the others).
>
> I have tested the patch series in armA15 platform which have
> more than 4G memory.
Hello Liu,
I'm curious how you tested this? The crash utility does not have
any specific support for LPAE on ARM, and a couple years ago I
asked on the crash-utility mailing list whether any of the ARM
developers were working on it. But at that time none of them were
working with LPAE. I see that you are on the crash-utility mailing
list -- are you planning to post follow-up patches to the crash-utility?
Thanks,
Dave
10 years, 3 months
