On Thu, 2005-11-17 at 13:18 -0800, Haren Myneni wrote: > > > crash-utility-bounces@xxxxxxxxxx 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. No. We still we have 2 vtop() functions. One for old kernels (pre-4level changes - which also works on 2.4 kernels). Other for kernels with 4-level pagetables, 64K page support. I guess, make a single vtop() which works on all kernels: 2.4 kernels, 2.6 pre-level4 changes, 4-level pagetables changes, 64k pagesupport etc. But I really don't have bandwidth to understand all the shifts and masks, make changes to incorporate all of differences & back and test every single one of them (I have no interest or time testing 2.4 kernels). > > > > 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? Yes. We can add INDEX macros if you like - but we will end up with 3 different sets of them: 2.4 kernels, 4-level pgtables, 64K pagesize. Thanks, Badari
