crash-utility-bounces@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@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility