Rachita Kothiyal wrote:
On Thu, Feb 23, 2006 at 09:49:37AM -0500, Dave Anderson wrote:
>
> Ok, then I guess I'll take that as a thumbs-up.
>
> Waiting on Rachita's go-ahead...Dave,
After the application of the patch (posted by Haren)
on crash-4.0-2.21, I am now able to open the dump using crash
for analysis.The following may be unrelated to the present discussion, but
it is an observation:When I do 'bt -a' I get the following error on one of the cpus:
PID: 2871 TASK: c000000161d05800 CPU: 4 COMMAND: "klogd"
bt: invalid kernel virtual address: ff807a50 type: "Regs NIP value"
It looks like the ppc64_kdump_stack_frame() function is getting
the
kernel stack pointer value from gpr[1] in the ELF header's pt_regs
storage location, and that stack address (+16) is hosed:
/*
* get SP and IP from the saved ptregs.
*/
static int
ppc64_kdump_stack_frame(struct bt_info *bt_in, ulong *nip, ulong
*ksp)
{
struct ppc64_pt_regs
*pt_regs;
unsigned long unip;
pt_regs = (struct ppc64_pt_regs
*)bt_in->machdep;
if (!pt_regs->gpr[1])
{
/*
* Not collected regs. May be the corresponding CPU not
* responded to an IPI.
*/
fprintf(fp, "%0lx: GPR1 register value (SP) was not saved\n",
bt_in->task);
return FALSE;
}
*ksp = pt_regs->gpr[1];
readmem(*ksp+16, KVADDR,
&unip, sizeof(ulong), "Regs NIP value",
FAULT_ON_ERROR);
Nope -- certainly not without a backtrace by running crashand a segmentation fault when I a do a 'bt' after setting the
context to a particular cpu using 'set -c'.crash> set -c 8
PID: 0
COMMAND: "swapper"
TASK: c0000000e9faf800 (1 of 16) [THREAD_INFO: c000000161fa4000]
CPU: 8
STATE: TASK_RUNNING (ACTIVE)
crash> bt
PID: 0 TASK: c0000000e9faf800 CPU: 8 COMMAND: "swapper"
Segmentation faultThoughts?
You guys are going to have to tell me what's going on...
Dave
Thanks
Rachita--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility