[Crash-utility] crash-4.0-2.10 ppc64 4-level pagetable fixes

[Dave Anderson]

Haren Myneni wrote:

>
>
> crash-utility-bounces at redhat.com wrote on 11/08/2005 02:54:33 PM:
>
> > On Tue, 2005-11-08 at 17:32 -0500, Dave Anderson wrote:
> > > Badari Pulavarty wrote:
> > >
> > > > On Tue, 2005-11-08 at 14:42 -0500, Dave Anderson wrote:
> > > > > Badari Pulavarty wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Yep. You are right, those pages are not mapped. Initially
> > > > > > I thought that was the case, but I wasn't really sure if it
> > > > > > can happen with segments from shared libraries. (since
> > > > > > the routine which is telling its not mapped involves
> > > > > > going through my code).
> > > > > >
> > > > > > Anyway, I verified this on x86-64 machine also - I do
> > > > > > get "read" error and those pages are not mapped.
> > > > > >
> > > > > > I guess, my changes are good :)
> > > > > >
> > > > > > Haren, can you review them ?
> > > > > >
> > > > > > Thanks,
> > > > > > Badari
> > > > > >
> > > > >
> > > > > The patch looks just fine to me -- the only minor things to
> > > > > add is a dump of the VM_ORIG/VM_4_LEVEL bits in
> > > > > the ppc64_dump_machdep_table() debug function, and
> > > > > although the "pud_clear_bad" is in all probability quite
> > > > > suitable as a qualifier, it's probably also worth adding
> > > > > an optional "--machdep vm=xxx" command line argument
> > > > > like I put in place for the x86_64 equivalent.  Just to cover
> > > > > our collective arse...
> > > > >
> > > > > Anyway, upon Haren's blessing, it's good to go.
> > > > >
> > > > > Again -- really nice work!
> > > >
> > > > Okay, made recommended changes.
> > > >
> > > > I still need to figure out a decent symbol to identify
> > > > 4-level pagetable layout. I am looking through "nm -Bn".
> > > > I still can't find a decent one. (has to be some symbol
> > > > added for 2.6.14).
> > > >
> > > > Any ideas ?
> > > >
> > >
> > > If you can google out the wholesale patch that introduced the
> > > 4-level pagetable support, you might find something added
> > > or removed?  That's what I did for the x86_64 qualifier.
> > >
> >
> > Okay. I found new structure "pgtable_cache" got added along
> > with 4-level pagetable changes. I am using that symbol now.
> >
> > Thanks,
> > Badari
> >
> Badari, Thanks a lot for helping us on PPC64.
>
> Dave, Is it a problem if we use Linux version to determine 4-level page table changes instead of looking for some
> symbol which might get changed later. We need to make some more changes for 64K page support added in 2.6.14-git11.
>

Maybe -- maybe not...

It's kind of a chicken-and-egg situation, where the first readmem()
needs the virtual address range stuff to be in place, but we need
something out of the kernel data space to determine the virtual
address space range data.  That being said, it looks possible, at
least in the case of ppc64, that perhaps we could get away with
doing a readmem() of a unity-mapped address, since at the
point where the VM-range decision is made, machdep->kvbase
has just been set.  (Follow the readmem() path, and you'll see
what I mean...)  But you'd have to read raw data and muck
your way through it because the embedded gdb hasn't been
invoked yet.  Badari had asked the same thing earlier, about
using the THIS_KERNEL_VERSION macro, but again, the
underlying crash data to satisfy the macro doesn't get initialized
until after gdb is alive.

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20051109/56138950/attachment.htm>