Re: [Crash-utility] Re: Problem with using crash 4.0-2.21 on ppc
Haren Myneni wrote:
> Is ff807a50 typically a legitimate user-space stack address
> in ppc64 user VM? You could probably run the address
> through IN_TASK_VMA(), and if it is a valid user-space
> stack address, just indicate that the process was running
> in user-space.
ff807a50 is in user space. Yes, the kernel address on PPC64 starts at
c000000000000000. Not only we should print an message says that "running
is user space", but also to display traces for other active traces. It
is a bug too. I will send the fix ASAP.
Good point -- just returning after the user-space message gets printed
will prevent the premature stoppage of the whole command.
Sure, if you have some other fixes or on other archs. Otherwise, can we
wait for early next week. I am wondering what is causing for Rachita's
issue. Is it related to the same paca.dataoffset patch? just want to
make sure.
That's fine -- I'll just wait until next week.
BTW, I ran the crash tool on RHEL4 vmcore (not the recent RHEL4 update
version) to see whether I am breaking backward compatibility. Small fix.
I somehow overlooked. Sorry. Probably, that might be the reason I saved
one RHEL4 vmcore and the corresponding vmlinux.debug.
----------------------------------------------------------------------------------------------------------------------
--- crash-4.0-2.21/ppc64.c.orig 2006-02-23 15:55:03.000000000 -0800
+++ crash-4.0-2.21/ppc64.c 2006-02-23 16:36:53.000000000 -0800
@@ -1538,7 +1538,7 @@ ppc64_get_dumpfile_stack_frame(struct bt
/*
* For the kdump vmcore, Use SP and IP values that are saved in ptregs.
*/
- if (pc->flags && KDUMP)
+ if (pc->flags & KDUMP)
return ppc64_kdump_stack_frame(bt_in, nip, ksp);
bt = &bt_local;
Good catch -- I've got this one.
Thanks,
Dave