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

On Wed, 2005-11-09 at 08:45 -0500, Dave Anderson wrote: > Haren Myneni wrote: > > > > > > crash-utility-bounces(a)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. Yes. You are right. I verified that THIS_KERNEL_VERSION is not set at PRE_GDB time. What I am not sure is, how late we can push finding out if we have 4-level pagetables are not and still make crash function.