Hi Dave & Haren, Here are the changes I made to "crash" to function with PPC64 64k pagesize. Instead of adding whole set of indexs, shifts, masks, macros and new vtop() routines - I generalized 4-level pagetable support and set & compute indexes, shift and masks correctly for 4K and 64K. Tested with 4K pagesize and 64K pagesize kernels on PPC64. Please review.

crash-utility-bounces(a)redhat.com wrote on 11/17/2005 12:56:01 PM: > Badari Pulavarty wrote: > > > Hi Dave & Haren, > > > > Here are the changes I made to "crash" to function with PPC64 > > 64k pagesize. Instead of adding whole set of indexs, shifts, > > masks, macros and new vtop() routines - I generalized 4-level > > pagetable support and set & compute indexes, shift and masks > > correctly for 4K and 64K. > > > > Tested with 4K pagesize and 64K pagesize kernels on PPC64. > > Please review. > > The proof is in the pudding, so I trust that it all works and is > backwards-compatible -- but to cover my own ass, I need you > to positively confirm that it still works on RHEL3 and RHEL4 kernels. Let me run crash tool on RHEL4 vmcore (I believe, I saved vmlinux and vmcore created on RHEL4 kernel). Yes, it should support backward compatible since we did not change the previous code patch even though we should be having one vtop with the new approach. But, we will check on previous vmcore or on live RHEL4 kernel.

> > One minor thing I can suggest, but I'll leave it up to you > whether you want to add it. On all of the other architectures, > their xxx_dump_machdep_table() functions will display the > contents of the generic machdep_table structure followed > by the contents of their attached machine_specific structure. > The ppc64_dump_machdep_table() function just has the > machspec pointer. When everything "just works", it's usually > never needed, but I've found it invaluable when debugging new > machine-specific stuff that comes along. > Yes, we will make changes. > But it's your call... so when you and Haren are happy, just let > me know. Badari, Thanks a lot for doing this. This approach is useful to support easily even for future changes. One minor comment, instead of hardcoding in ppc64.c source file for 'm->l1_index_size = 9', can we define INDEX macros in the header file and use them here. For example, PTE_INDEX_SIZE_L4. I am thinking we can map/understand easily to see what is l1 or l2. What do you think?

> But it's your call... so when you and Haren are happy, just let > me know. Badari, Thanks a lot for doing this. This approach is useful to support easily even for future changes. One minor comment, instead of hardcoding in ppc64.c source file for 'm->l1_index_size = 9', can we define INDEX macros in the header file and use them here. For example, PTE_INDEX_SIZE_L4. I am thinking we can map/understand easily to see what is l1 or l2. What do you think?

Badari Pulavarty wrote: > On Thu, 2005-11-17 at 13:18 -0800, Haren Myneni wrote: > > > > But it's your call... so when you and Haren are happy, just let > > > me know. > > > > Badari, Thanks a lot for doing this. This approach is useful to > > support easily even for future changes. One minor comment, instead

> > hardcoding in ppc64.c source file for 'm->l1_index_size = 9', can we > > define INDEX macros in the header file and use them here. For > > example, PTE_INDEX_SIZE_L4. I am thinking we can map/understand

> > to see what is l1 or l2. What do you think? > > Okay, here is the latest to include what Dave and Haren want. > > Please review. This looks good to me. AFAICT, there should be no impact at all on RHEL3 or RHEL4 kernels since there's no way they could run without VM_ORIG set. If Haren could just give it his final blessing, I'll check it in.

Thanks, Dave -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility