kernel change post v3.3
by Gerard Snitselaar
The xtime struct has been moved inside the timekeeper struct in kernel/time/timekeeping.c.
12 years, 8 months
Re: [Crash-utility] Kernel Crash Analysis on Android
by Shankar, AmarX
Hi Daisuke,
Thanks for info.
Regards,
Amar
From: "Shankar, AmarX" <amarx.shankar(a)intel.com>
Subject: Re: [Crash-utility] Kernel Crash Analysis on Android
Date: Thu, 22 Mar 2012 04:02:23 +0000
> 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
>
Follow this link. There are a variety of resources about kexec-tools.
http://horms.net/projects/kexec/
Thanks.
HATAYAMA, Daisuke
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
From: Shankar, AmarX
Sent: Thursday, March 22, 2012 9:32 AM
To: 'crash-utility(a)redhat.com'
Subject: RE: Kernel Crash Analysis on Android
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
12 years, 8 months
Kernel Crash Analysis on Android
by Shankar, AmarX
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
12 years, 8 months
[PATCH 0/5] [ppc32] Support E500 processor for FSL BOOKE
by Toshikazu Nakayama
This patch add support fleescale ppce500mc in E500 processor chipset.
And make platform specific code shape-up so that new support can get easy.
Todo:
vtop for kernel vaddr in ppce500mc can not work out yet.
crash> vtop c0000000
VIRTUAL PHYSICAL
c0000000 0
PAGE DIRECTORY: c08d1000
PGD: c08d2800 => 0 # Not mapped from PGD.
- linux/arch/powerpc/mm/fsl_booke_mmu.c
I think if kernel use TLBCAM's fixed map, page table setting are not required?
I'll make up fsl-booke specific physaddr search method later.
Thanks,
Toshi
Toshikazu Nakayama (5):
ppc32: handle PTE size by using gdb datatype request
ppc32: shrink machine_specific
ppc32: handle greater PTE_RPN_SHIFT than PAGE_SHIFT
ppc32: add E500 processor probe function
ppc32: cleanup page table code
defs.h | 59 ++++++++++++++++++++++----------
ppc.c | 118 +++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 109 insertions(+), 68 deletions(-)
12 years, 8 months
"gdb" by itself ought to put crash into a "gdb" mode
by Bruce Korb
Hi,
I might actually write the patch for this one. Piping back to crash,
as useful as it would be,
requires too much context shuffling. Here, all that'd be necessary is
a "we are in pass
through to gdb" mode meaning that the "gdb " prefix to gdb commands
would not be necessary.
Just monitor the input for a "crash" line and flip the bit. It's a
nuisance to have to remember
that prefix when typing a long series of gdb commands that mostly work
as crash commands.
Possible? Thanks ! Regards, Bruce
12 years, 8 months
[PATCH] fix command vm/files -d/mount on new kernel
by qiaonuohan
Hello Dave,
New kernel has moved some elements of struct vfsmount to a new struct
mount. So crash will not act normally on new kernel. The patch is used
to fix the problem.
Please check.
--
--
Regards
Qiao Nuohan
--------------------------------------------------
Qiao Nuohan
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu Road, Nanjing, Nanjing, 210012, China
TEL: +86+25-86630566-8526 FUJITSU
INTERNAL: 7998-8526 FAX: +86+25-83317685
EMail: qiaonuohan(a)cn.fujitsu.com
--------------------------------------------------
This communication is for use by the intended
recipient(s) only and may contain information that
is privileged, confidential and exempt from
disclosure under applicable law. If you are not an
intended recipient of this communication, you are
hereby notified that any dissemination,
distribution or copying hereof is strictly
prohibited. If you have received this communication
in error, please notify me by reply e-mail,
permanently delete this communication from your
system, and destroy any hard copies you may have
printed
12 years, 8 months
[PATCH] add -s option to vm to display one vma at a time
by qiaonuohan
Hello Dave,
When I am using "vm -p" command, I feel it is chaotic when too much data
is printed. I think it is clear to display one vma each time.
In the patch, I compare all vmas with the argument of -s option. If an
equal vma is found, it will be printed like below.
crash> vm -ps ffff88028ff7d3a0
VMA START END FLAGS FILE
ffff88028ff7d3a0 7fff29b71000 7fff29b87000 100173
VIRTUAL PHYSICAL
7fff29b71000 (not mapped)
7fff29b72000 (not mapped)
7fff29b73000 (not mapped)
7fff29b74000 (not mapped)
7fff29b75000 (not mapped)
7fff29b76000 (not mapped)
7fff29b77000 27faad000
7fff29b78000 2807aa000
7fff29b79000 280781000
7fff29b7a000 280787000
7fff29b7b000 280776000
7fff29b7c000 280786000
7fff29b7d000 27f2df000
7fff29b7e000 27f2e0000
7fff29b7f000 27f2e1000
7fff29b80000 27f2d7000
7fff29b81000 28b1ac000
7fff29b82000 28ecc1000
7fff29b83000 28c5c2000
7fff29b84000 28aaf4000
7fff29b85000 28aaf9000
7fff29b86000 289566000
crash>
--
--
Regards
Qiao Nuohan
12 years, 8 months
ANNOUNCE: PyKdump-0.6.4 prebuilt binaries for X86/X86_64 available
by Alex Sidorenko
Hello,
even though PyKdump extension is widely used both in HP and other companies, I
have not uploaded any binaries to SF since 2008. This is mainly due to the
lack of time - my colleagues in HP use binaries built by me on our internal
hosts and other companies are either building from sources or ask me to
provide binaries by email. As a result, the old binaries from SF do not work
properly on recent kernels. Wiki documentation describing how to build from
sources was not very good either (now Bruce Korb has kindly agreed to help
with documentation).
You can download the prebuilt binaries from
http://sourceforge.net/projects/pykdump/
These binaries have been built on RHEL4. As the only dependency is GLIBC,
this means that they can be used on any distribution with GLIBC not older
than that on RHEL4, in particular RHEL5, RHEL6, SLES10, SLES11 are fine.
Usually extensions built against a specific crash version do not need
to be rebuilt for other crash versions, as long as it is the same major
version. But extensions built against crash-6.X will not work with
crash-5.X and vice versa.
For convenience, the archive contains both extensions (built with
Python-2.7.2 and crash-6.0.3), and crash executables themselves,
both 32-bit and 64-bit versions:
usr/local/bin/crash32
usr/local/bin/crash64
usr/local/lib/mpykdump32.so
usr/local/lib/mpykdump64.so
The provided utilities work with any kernel starting from 2.4.21 and up to
3.0.0.
Loading the extension registers 'epython', 'crashinfo', 'xportshow' and
'taskinfo' commands.
'epython' can be used to run your own scripts, other commands are general-
purpose and have many options.
I hope to significantly improve the documentation and building process in the
nearest future.
Regards,
Alex
--
------------------------------------------------------------------
Alexandre Sidorenko email: asid(a)hp.com
WTEC Linux Hewlett-Packard (Canada)
------------------------------------------------------------------
12 years, 8 months
[PATCH] ARM: fix vtop -C for kernel addresses
by Rabin Vincent
On ARM, [vtop -C task] doesn't work correctly for kernel addresses: it
always uses swapper_pg_dir when it should be using the task's mm->pgd.
The patch below fixes this, and also makes ARM handle kernel threads
like the other arches.
Rabin
diff --git a/arm.c b/arm.c
index 4be224e..cac9a9a 100644
--- a/arm.c
+++ b/arm.c
@@ -1020,22 +1020,37 @@ static int
arm_uvtop(struct task_context *tc, ulong uvaddr, physaddr_t *paddr, int verbose)
{
ulong *pgd;
- ulong mm;
if (!tc)
error(FATAL, "current context invalid\n");
*paddr = 0;
- if (IS_KVADDR(uvaddr))
- return arm_kvtop(tc, uvaddr, paddr, verbose);
+ if (is_kernel_thread(tc->task) && IS_KVADDR(uvaddr)) {
+ ulong active_mm;
- mm = task_mm(tc->task, TRUE);
- if (mm)
- pgd = ULONG_PTR(tt->mm_struct + OFFSET(mm_struct_pgd));
- else
- readmem(tc->mm_struct + OFFSET(mm_struct_pgd), KVADDR, &pgd,
- sizeof(long), "mm_struct pgd", FAULT_ON_ERROR);
+ readmem(tc->task + OFFSET(task_struct_active_mm),
+ KVADDR, &active_mm, sizeof(void *),
+ "task active_mm contents", FAULT_ON_ERROR);
+
+ if (!active_mm)
+ error(FATAL,
+ "no active_mm for this kernel thread\n");
+
+ readmem(active_mm + OFFSET(mm_struct_pgd),
+ KVADDR, &pgd, sizeof(long),
+ "mm_struct pgd", FAULT_ON_ERROR);
+ } else {
+ ulong mm;
+
+ mm = task_mm(tc->task, TRUE);
+ if (mm)
+ pgd = ULONG_PTR(tt->mm_struct + OFFSET(mm_struct_pgd));
+ else
+ readmem(tc->mm_struct + OFFSET(mm_struct_pgd),
+ KVADDR, &pgd, sizeof(long), "mm_struct pgd",
+ FAULT_ON_ERROR);
+ }
return arm_vtop(uvaddr, pgd, paddr, verbose);
}
12 years, 8 months
[PATCH] foreach filter on state
by Rabin Vincent
The patch below adds support to filter foreach on task states. I've
found [foreach state=D bt] and [foreach state=R bt] useful; the former
allows to emulate the show-blocked-tasks Magic SysRq.
Rabin
diff --git a/defs.h b/defs.h
index 2e7f6bd..dc12844 100755
--- a/defs.h
+++ b/defs.h
@@ -974,6 +974,7 @@ extern struct machdep_table *machdep;
#define FOREACH_F_FLAG (0x400000)
#define FOREACH_x_FLAG (0x800000)
#define FOREACH_d_FLAG (0x1000000)
+#define FOREACH_STATE (0x2000000)
struct foreach_data {
ulong flags;
@@ -982,6 +983,7 @@ struct foreach_data {
char *comm_array[MAX_FOREACH_COMMS];
ulong pid_array[MAX_FOREACH_PIDS];
ulong arg_array[MAX_FOREACH_ARGS];
+ ulong state;
char *reference;
int keys;
int pids;
diff --git a/help.c b/help.c
index adaaea7..dedf479 100755
--- a/help.c
+++ b/help.c
@@ -736,7 +736,9 @@ char *help_foreach[] = {
" precede the name string with a \"\\\".",
" user perform the command(s) on all user (non-kernel) threads.",
" kernel perform the command(s) on all kernel threads.",
-" active perform the command(s) on the active thread on each CPU.\n",
+" active perform the command(s) on the active thread on each CPU.",
+" state=? perform the command(s) on all tasks in the specified state.",
+" (? is one of R, S, D, T, Z, X, W)\n",
" If none of the task-identifying arguments above are entered, the command",
" will be performed on all tasks.\n",
" command select one or more of the following commands to be run on the tasks",
@@ -793,6 +795,9 @@ char *help_foreach[] = {
" Display the open files for all tasks:\n",
" %s> foreach files",
" ...\n",
+" Display the stack traces for all blocked (TASK_UNINTERRUPTIBLE) tasks:\n",
+" %s> foreach state=D bt",
+" ...\n",
NULL
};
diff --git a/task.c b/task.c
index 433a043..de033c3 100755
--- a/task.c
+++ b/task.c
@@ -5061,6 +5061,35 @@ cmd_foreach(void)
continue;
}
+ if (STRNEQ(args[optind], "state=")) {
+ const char *p = args[optind] + strlen("state=");
+ ulong state = 0;
+
+ if (STREQ(p, "R"))
+ state = _RUNNING_;
+ else if (STREQ(p, "S"))
+ state = _INTERRUPTIBLE_;
+ else if (STREQ(p, "D"))
+ state = _UNINTERRUPTIBLE_;
+ else if (STREQ(p, "T"))
+ state = _STOPPED_;
+ else if (STREQ(p, "Z"))
+ state = _ZOMBIE_;
+ else if (STREQ(p, "X"))
+ state = _DEAD_;
+ else if (STREQ(p, "W"))
+ state = _SWAPPING_;
+ else if (*p)
+ error(FATAL, "invalid state: %s\n", p);
+ else
+ error(FATAL, "no state specified\n");
+
+ fd->flags |= FOREACH_STATE;
+ fd->state = state;
+ optind++;
+ continue;
+ }
+
/*
* Select only user threads.
*/
@@ -5322,6 +5351,9 @@ foreach(struct foreach_data *fd)
if ((fd->flags & FOREACH_KERNEL) && !is_kernel_thread(tc->task))
continue;
+ if ((fd->flags & FOREACH_STATE) && task_state(tc->task) != fd->state)
+ continue;
+
if (specified) {
for (j = 0; j < fd->tasks; j++)
if (fd->task_array[j] == tc->task)
--
1.7.9.1
12 years, 8 months
