[ANNOUNCE] crash version 6.0.6 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
Changelog:
- Extend the supported cross-architecture build capability so that
it applies to the SIAL extension module. Without the patch,
when building the SIAL module in an environment where the
overlying crash utility was built with "make target=ARM",
"make target=PPC", or "make target=X86", the SIAL extension
module would continue to be built for the host architecture.
(rabin(a)rab.in, anderson(a)redhat.com)
- Fixes for memory leaks and possible segmentation violations
when unloading SIAL extension module scripts.
(rabin(a)rab.in)
- Fix for the new "foreach RU" task state qualifier. Without the
patch, the runnable tasks are not selected.
(anderson(a)redhat.com)
- Fix to disallow multiple task states from being entered using
the "foreach <task-state>" qualifier. Without the patch, if
multiple states were entered, the last one on the command line
would be honored.
(anderson(a)redhat.com)
- Fix for the "extend" command to allow the usage of 32-bit PPC
extension modules. Without the patch, the command fails with the
message: "extend: <object>.so: not an ELF format object file".
(anderson(a)redhat.com)
- If an input line starts with "#" or "//", then the line will be
saved as a comment that is visible when re-cycling through the
command history list.
(olivier.daudel(a)u-paris10.fr, anderson(a)redhat.com)
- Fix for a crash-5.1.9 regression that broke the "bt -g" option.
Without the patch, the option is ignored completely.
(ptesarik(a)suse.cz)
- Fix for s390x virtual-to-physical translation of virtual addresses
that are backed by 1MB pages.
(ptesarik(a)suse.cz)
- The s390x has a dumpfile method that creates "live dumps", where
the kernel continues to run while the dumpfile is being created.
The initial system banner display and the "sys" command will inform
the user that the dumpfile is a "[LIVE DUMP]", and the "bt -a" option
will fail with the message "bt: -a option not supported on a live
system or live dump".
(holzheu(a)linux.vnet.ibm.com)
- Newly-created dumpfiles generated by the "snap.c" extension module
will now be recognized as "live dumps". Accordingly, the initial
system banner display and the "sys" command will inform the user that
the dumpfile is a "[LIVE DUMP]", and the "bt -a" option will fail
with the message "bt: -a option not supported on a live system or
live dump".
(anderson(a)redhat.com)
- If "bt" alone is attempted on an active task in a "live dump", it
will indicate "(active)", i.e., the same as if it were attempted on
a live system.
(holzheu(a)linux.vnet.ibm.com)
- If an extension module does not define the appropriate architecture,
i.e., "-DX86", "-DX86_64", etc., then the inclusion of "defs.h" will
generate a compiler failure indicating "error: 'NR_CPUS' undeclared
here (not in a function)". In that case, the architecture will now
default to that of the host machine.
(anderson(a)redhat.com)
- Prevent a highly-unlikely incorrect calculation of the maximum
cpudata array length of a kmem_cache during initialization of
of CONFIG_SLAB kernels.
(anderson(a)redhat.com)
- Prevent an infinite loop during the initialization of the kmem_cache
subsystem in CONFIG_SLAB kernels if the cache list or the vmcore is
corrupt. If the kmem_cache list links back into itself, messages
showing the first "duplicate" entry in the list and "crash: unable
to initialize kmem slab cache subsystem" will be displayed.
(anderson(a)redhat.com)
- Update to the "mod" command to additionally search for module object
files in the directory containing the kernel namelist (vmlinux) file.
This will allow an alternate module-debuginfo directory tree to be
set up like so:
# cd <directory>
# rpm2cpio kernel-debuginfo-<release>.rpm | cpio -idv
Having done that, and by referencing the vmlinux file in that
directory tree directly or by symbolic link, the "mod" command
will search for module object files starting from the directory
containing the vmlinux file if they are not found in the standard
/lib/modules/<release> directory.
(shane.seymour(a)hp.com, anderson(a)redhat.com)
- Update to the s390x "bt" command if a task was running in userspace.
Without the patch, the back trace display ended at the kernel entry
function frame; with the patch, the user space PSW register is
displayed with a "(user space)" tag, followed by the general purpose
register set.
(holzheu(a)linux.vnet.ibm.com)
- In the unlikely event that the access of ARM or x86_64 kernel unwind
table data fails during crash invocation, print a warning message and
allow the crash session to continue. Without the patch, the crash
session would fail immediately.
(Jan.Karlsson(a)sonymobile.com, anderson(a)redhat.com)
14 years, 1 month
loop in crash
by Karlsson, Jan
Hi Dave,
I have a corrupt vmcore file (for ARM) that makes crash loop forever. The problem is in memory.c, function max_cpudata_limit. The last part of that function:
if (VALID_MEMBER(kmem_list3_shared) && VALID_MEMBER(kmem_cache_s_lists) &&
readmem(kmem_cache_nodelists(cache), KVADDR, &start_address[0],
sizeof(ulong) * vt->kmem_cache_len_nodes, "array nodelist array",
RETURN_ON_ERROR)) {
for (i = 0; i < vt->kmem_cache_len_nodes; i++) {
if (start_address[i] == 0)
continue;
if (readmem(start_address[i] + OFFSET(kmem_list3_shared),
KVADDR, &shared, sizeof(void *),
"kmem_list3 shared", RETURN_ON_ERROR|QUIET)) {
if (!shared)
break;
}
if (readmem(shared + OFFSET(array_cache_limit),
KVADDR, &limit, sizeof(int), "shared array_cache limit",
RETURN_ON_ERROR|QUIET)) {
if (limit > max_limit)
max_limit = limit;
break;
}
}
}
FREEBUF(start_address);
return max_limit;
bail_out:
vt->flags |= KMEM_CACHE_UNAVAIL;
error(INFO, "unable to initialize kmem slab cache subsystem\n\n");
*cpus = 0;
return 0;
The problem is that the readmem statement "if (readmem(start_address[i] + OFFSET(kmem_list3_shared), ....." fails, and then the function max_cpudata_limit is called over and over again. I did a patch adding "else goto bail_out;" if the readmem fails and then crash managed to continue. I do not know if this is really a good idea.
As this seems only to be a problem for corrupt vmcore files I do not know if you want to do anything about it.
Best regards
Jan
Jan Karlsson
Senior Software Engineer
MIB
Sony Mobile Communications
Tel: +46703062174
sonymobile.com<http://sonymobile.com/>
[cid:image001.jpg@01CD22E9.EA9DB1E0]
14 years, 1 month
[PATCH] s390x: Print userspace PSW and registers for active tasks
by Michael Holzheu
Hi Dave,
Currently when we find a userspace pt_regs at the beginning of the stack,
we print nothing. With this patch the userspace PSW and general purpose
registers are printed.
With this change for the user it is clearer now that the task has
been interrupted while running in userspace.
Example: External interrupt while in userspace
Before change:
crash> bt -a
...
#1 [176327e08] arch_send_call_function_ipi_mask at 115d80
#2 [176327e38] do_extint at 10dd82
#3 [176327eb0] ext_skip at 63e344
After change:
crash> bt -a
...
#1 [176327e08] arch_send_call_function_ipi_mask at 115d80
#2 [176327e38] do_extint at 10dd82
#3 [176327eb0] ext_skip at 63e344
PSW: 0705e00180000000 0000000080000a16 (userspace)
GPRS: 0000000000000001 000003ff00647213 000003fffd800000 0000000003710001
0000000080000afc 000003fffff77e58 0000000080000bb0 000003fffff781c0
00000000800007bc 0000000000000000 0000000080000b44 000003fffff77e58
000003fffd7c6000 000003fffd777020 0000000080000b02 000003fffff77e58
Michael
---
s390x.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
--- a/s390x.c
+++ b/s390x.c
@@ -978,12 +978,16 @@ static void print_ptregs(struct bt_info
return;
fprintf(fp, " PSW: %016lx %016lx ", psw_flags, psw_addr);
- sym = closest_symbol(psw_addr);
- offs = psw_addr - closest_symbol_value(psw_addr);
- if (module_symbol(psw_addr, NULL, &lm, NULL, 0))
- fprintf(fp, "(%s+%ld [%s])\n", sym, offs, lm->mod_name);
- else
- fprintf(fp, "(%s+%ld)\n", sym, offs);
+ if (psw_flags & S390X_PSW_MASK_PSTATE) {
+ fprintf(fp, "(user space)\n");
+ } else {
+ sym = closest_symbol(psw_addr);
+ offs = psw_addr - closest_symbol_value(psw_addr);
+ if (module_symbol(psw_addr, NULL, &lm, NULL, 0))
+ fprintf(fp, "(%s+%ld [%s])\n", sym, offs, lm->mod_name);
+ else
+ fprintf(fp, "(%s+%ld)\n", sym, offs);
+ }
addr = sp + MEMBER_OFFSET("pt_regs", "gprs");
for (i = 0; i < 16; i++) {
@@ -1039,8 +1043,10 @@ static unsigned long show_trace(struct b
return sp;
/* Check for user PSW */
reg = readmem_ul(sp + MEMBER_OFFSET("pt_regs", "psw"));
- if (reg & S390X_PSW_MASK_PSTATE)
+ if (reg & S390X_PSW_MASK_PSTATE) {
+ print_ptregs(bt, sp);
return sp;
+ }
/* Get new backchain from r15 */
reg = readmem_ul(sp + MEMBER_OFFSET("pt_regs", "gprs") +
15 * sizeof(long));
14 years, 1 month
After feedback on crash patch
by Seymour, Shane M
Hi,
I'd like to get crash changed to add a new option to the mod command in crash. If you've got a dump server and you've got debuginfo RPMs extracted for pretty much every RHEL/SLES release you can create a symlink in the same directory as the vmcore pointing to the correct namelist, for example:
vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux
I'd like to see the mod command automatically work out where the debug modules will be based upon the result of realpath(3) on the namelist then removing everything after /usr/lib/debug. I know that there's the "--mod directory" option but you've got to remember to run it all the time and if you've extracted the kernel debuginfo crash can easily work out where they are if you use either a full or relative path or symlink to the namelist. I don't know if anyone would prefer to see it implemented in a different way but rather than risk breaking something I didn't understand I added a new -t option instead (-t because it's similar to -S and t is the next available option after the letter s).
I've run it on a few dumps and it seems to be working correctly. All of the code changes are in kernel.c, help.c needed some changes just to add the help text. Any feedback would be appreciated.
Thanks
Shane
14 years, 1 month
[PATCH] add a new command: ipcs
by qiaonuohan
Hello Dave,
I have been working on a new command to provide information of ipc
facilities. Recently, the function displaying shared memory segments has
been implemented.
The output is like below:
crash> ipcs
------ Shared Memory Segments ------
SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES
NATTCH SHM_INODE
ffff8804683b0310 0x00000000 0 7 15 0 600 393216 2
ffff880470512d98
ffff880470987910 0x00000000 32769 6 16 0 600 393216 2
ffff880470512758
ffff880471621190 0x00000000 65538 46 0 0 600 393216 2
ffff880474202d98
ffff8804747f1a50 0x00000000 98307 12 12 0 600 393216 2
ffff880471264758
ffff8804704ad510 0x00000000 131076 96 0 0 600 393216 2
ffff880474094d98
To see more details, please refer to the help information and the patch.
--
--
Regards
Qiao Nuohan
14 years, 1 month
[RFC/PATCH] s390x: Add live dump detection
by Michael Holzheu
Hi Dave,
On s390 we will have a dump method that creates live dumps, similar to
the snap.so crash plugin. Because Linux is not stopped while the dump
is created, the resulting dump is not consistent. Therefore it is
important that the crash tool informs the user about this issue.
The dump tool writes a magic number (ASCII "LIVEDUMP") into the first 8
bytes of the dump memory. With this patch this is checked in POST_INIT
by the s390x backend crash code. If the magic is found, the LIVE_SYSTEM
flag is set. This ensures that commands that do not work with /dev/mem
also will fail with s390x live dumps.
Example:
crash> bt -a
bt: -a option not supported on a live system
In addition to that with this patch crash prints a "[LIVE DUMP]" info
tag for live dump files at startup (similar to [PARTIAL DUMP]):
$ crash livedump vmlinux
KERNEL: /boot/vmlinux
DUMPFILE: dump.s390 [LIVE DUMP]
Michael
---
kernel.c | 8 ++++++--
s390x.c | 12 ++++++++++++
2 files changed, 18 insertions(+), 2 deletions(-)
--- a/kernel.c
+++ b/kernel.c
@@ -975,7 +975,9 @@ non_matching_kernel(void)
else
fprintf(fp, " DUMPFILE: ");
if (ACTIVE()) {
- if (REMOTE_ACTIVE())
+ if (pc->dumpfile)
+ fprintf(fp, "%s [LIVE DUMP]\n", pc->dumpfile);
+ else if (REMOTE_ACTIVE())
fprintf(fp, "%s@%s (remote live system)\n",
pc->server_memsrc, pc->server);
else
@@ -4080,7 +4082,9 @@ display_sys_stats(void)
else
fprintf(fp, " DUMPFILE: ");
if (ACTIVE()) {
- if (REMOTE_ACTIVE())
+ if (pc->dumpfile)
+ fprintf(fp, "%s [LIVE DUMP]\n", pc->dumpfile);
+ else if (REMOTE_ACTIVE())
fprintf(fp, "%s@%s (remote live system)\n",
pc->server_memsrc, pc->server);
else
--- a/s390x.c
+++ b/s390x.c
@@ -328,6 +328,17 @@ static void s390x_process_elf_notes(void
}
}
+static void s390x_check_live(void)
+{
+ unsigned long long live_magic;
+
+ readmem(0, KVADDR, &live_magic, sizeof(live_magic),
"live_magic",
+ RETURN_ON_ERROR | QUIET);
+
+ if (live_magic == 0x4c49564544554d50ULL)
+ pc->flags |= LIVE_SYSTEM;
+}
+
/*
* Do all necessary machine-specific setup here. This is called
several
* times during initialization.
@@ -402,6 +413,7 @@ s390x_init(int when)
break;
case POST_INIT:
+ s390x_check_live();
break;
}
}
14 years, 1 month
[PATCH 0/5] let make flexible for multiple host
by Toshikazu Nakayama
Hi Dave,
This patch set will make configure or build flexible for host environment,
in particular dealing with cross compiler.
Please consider about this proposal.
patch#1:
By declaring tables about target and host relationships,
cleanup corresponding code and the new build combination will be
adapted briefly.
Remaining patches:
Try to relieve cross compiler burden by using explicit host_cross option.
I'm using cross compiler environ host=x86 for target=ppc,
and might attempt target=<another arch> in the near future.
I stocked private patches to accomplish cross compiling
but I'd like to discard them permanently with your agreement.
Thanks,
Toshi
Toshikazu Nakayama (5):
configure: retake the way of host compiler detection
Makefile: wrap cc, gcc and ar with common make valiables
make: add host_cross option
build_data: handle CC valiable
configure: handle cross compile with target=ppc host_cross=x86
Makefile | 144 +++++++++--------
configure.c | 441 ++++++++++++++++++++++-----------------------------
extensions/Makefile | 10 +-
extensions/sial.mk | 6 +-
extensions/snap.mk | 6 +-
5 files changed, 289 insertions(+), 318 deletions(-)
14 years, 1 month
[PATCH] Extend the SIAL built-in functions to include memset function.
by Aravinda Prasad
The memset function will be used to specify the virtual address
and the length of the data to be scrubbed in the dump file when
the SIAL macro is used with the makedumpfile command. The
makedumpfile command is currently being enhanced to accept SIAL
macros to scrub data in the dump file.
When used with crash, SIAL macro using memset function will
have no effect (as intended as dump file should not be modified).
This is because the API_PUTMEM call back function implemented
in crash extension layer is a no-op.
Signed-off-by: Aravinda Prasad <aravinda(a)linux.vnet.ibm.com>
---
extensions/libsial/sial_builtin.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/extensions/libsial/sial_builtin.c b/extensions/libsial/sial_builtin.c
index e189f5e..05228a4 100644
--- a/extensions/libsial/sial_builtin.c
+++ b/extensions/libsial/sial_builtin.c
@@ -192,6 +192,18 @@ char p[1024];
return sial_setstrval(sial_newval(), p);
}
+value_t *
+sial_memset(value_t* vaddr, value_t* vch, value_t* vlen)
+{
+ull addr=sial_getval(vaddr);
+int len=sial_getval(vlen);
+ull ch=sial_getval(vch);
+
+ API_PUTMEM(addr, (void *)ch, len);
+ return sial_makebtype(1);
+}
+
+
static builtin *bfuncs=0;
/*
@@ -334,6 +346,7 @@ static btspec_t sialbfuncs[] = {
{ "void prarr(string name, int i)", bcast(sial_prarr)},
{ "int member(void*, string name)", bcast(sial_ismember)},
{ "string findsym(string)", bcast(sial_findsym)},
+ { "int memset(char*, int, int)", bcast(sial_memset)},
};
14 years, 1 month
What should "list -h" be doing?
by Petr Tesarik
Hi,
I think the behaviour of the (undocumented) "list -h" command is hardly
useful. I believe the intention was to cover cases like struct anon_vma, which
is linked through a list_head (not at the beginning of the structure) and does
not have an external struct list_head. However, it doesn't work for that case:
crash> struct -o anon_vma
struct anon_vma {
[0x0] struct anon_vma *root;
[0x4] spinlock_t lock;
[0x8] atomic_t external_refcount;
[0xc] struct list_head head;
}
Now, let's have an anon_vma at 0xf0749d38
crash> anon_vma 0xf0749d38
struct anon_vma {
root = 0xf0749d38,
/* left out for brevity */
head = {
next = 0xf6c34708,
prev = 0xf6c34d80
}
}
I would assume that I can walk all linked anon_vma's with
list -o anon_vma.head -h 0xf0749d38
But that still expects a pointer to struct list_head. I would have to do
list -o anon_vma.head -h 0xf0749d38+0xc
That's awkward. But maybe it's how it should work, because it's not clear what
the "-h" should be doing.
Anyway, I think the "list" command could help with walking the anon_vma list.
I can surely add another option letter for that purpose, but before doing
that, I'd like to ask if this is merely missing documentation and a bug in the
implemenatation of the existing "-h" option.
Thanks for your patience,
Petr Tesarik
14 years, 1 month
Subject: [PATCH] s390x: fix vtop for 1M pages
by Petr Tesarik
Hi Michael,
I'm not a z/Series guru, but it seems to me that the address should not be
returned directly, but rather assigned to the phys_addr output parameter.
Petr Tesarik
SUSE Linux
14 years, 1 month
