[Crash-utility] Re: Problem with using crash 4.0-2.21 on ppc

[Dave Anderson]

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);

>
>
> and 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 fault
>
> Thoughts?
>

Nope -- certainly not without a backtrace by running crash
under gdb.  I've never seen that behaviour before, and cannot
comment whether it could be associated with the paca issue.

You guys are going to have to tell me what's going on...

Dave


>
> Thanks
> Rachita
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060223/52534610/attachment.htm>