crash-utility-bounces(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility