Re: [Crash-utility] crash-4.0-2.10 ppc64 4-level pagetable fixes
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?
Dave