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

[Haren Myneni]

crash-utility-bounces at redhat.com wrote on 11/09/2005 11:16:30 AM:

> Badari Pulavarty wrote:
> 
> > >
> > > 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.
> >
> > Okay. It looks like we can delay deciding 4-level pagetable layout
> > till POST_GDB stage. Since THIS_KERNEL_VERSION is set by then, I was
> > able to use that instead :)
> 
> Ok -- sorry, I'm so far behind in my mail, I answered your last query 
before
> I got to this one.  So doing it this late should be OK -- as long as
> there never
> becomes a requirement to access a vmalloc address data prior to that 
point.
> 
> One question -- if the 64k page support is put in place for 2.6.14, are 
you
> going to run into the same kind of "qualification" issue?

Based on my investigation so far that, mostly INDEX values got changed. We 
could do like this:

Define shift variables pgd_shift, pmd_shift and etc, and assign them 
during POST_GDB stage. Depends on the kernel version and page_size, these 
shift values can be assigned. We need to look some more. 

Thanks
Haren 

> 
> Dave
> 
> 
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20051109/901ca2a6/attachment.htm>