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

[Haren Myneni]

crash-utility-bounces at 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 at redhat.com 
> https://www.redhat.com/mailman/listinfo/crash-utility--
> 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/ec5058f9/attachment.htm>