crash-utility-bounces@redhat.com wrote on 02/23/2006 08:32:35 AM:

> 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"

This one could be possible that, CPU 4 is executing in user space (probably, clear error message should be better here) . Rachita, we should see the similar message even with GDB.

>
> 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
>  
Dave, I will look into this issue. I did not see these issues that Rachita reported during my testing.

Thanks
Haren

>  
> Thanks
> Rachita
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility--
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility