[Crash-utility] Re: Problem with using crash 4.0-2.21 on ppc
Dave Anderson
anderson at redhat.com
Fri Feb 24 14:38:11 UTC 2006
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
More information about the Crash-utility
mailing list