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
