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

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.