Re: [Crash-utility] Re: PATCH] support vmcores with 64k page sizeon 4kpage size kernels

Haren Myneni wrote: > Dave Anderson wrote: > > >> Dave Anderson wrote: >> >> >>> "Sachin P. Sant" wrote: >>> >>> >>>> Hi Dave >>>> Recently there were changes made to kexec tools to support 64K page >>>> >>> size. >>> >>>> With those changes vmcore file obtained from a kernel which >>>> >>> supports 64K >>> >>>> page size cannot be analyzed using crash on a machine running with >>>> >>> kernel >>> >>>> supporting 4K page size. >>>> >>>> The following changes in crash tool resolves the problem. >>>> Look if the symbol __hash_page_64k exists. This symbol is defined only >>>> for kernels with 64K PAGE SIZE support. If yes then the dump was taken >>>> with a kernel supporting 64k page size. So use the vmcore page >>>> >>> size[64K] >>> >>>> instead of getpagesize(). >>>> >>>> Thanks >>>> -Sachin >>>> >>>> >>>> >>> ------------------------------------------------------------------------------------------------------------------------ >>> >>> >>>> * Recently there were changes made to kexec tools to support 64K >>>> >>> page size. >>> >>>> With those changes vmcore file obtained from a kernel which >>>> >>> supports 64K >>> >>>> page size cannot be analyzed using crash on a machine running >>>> >>> with kernel >>> >>>> supporting 4K page size. >>>> The following change were made in crash tool to solve the problem. >>>> Look if the symbol __hash_page_64k exists. If yes then the dump >>>> >>> was taken >>> >>>> with a kernel supporting 64k page size. So change the page size >>>> >>> accordingly. >>> >>>> Signed-Off-By: Sachin Sant <sachinp(a)in.ibm.com&gt; >>>> -- >>>> >>>> diff -Naurp crash-4.0/defs.h crash-4.0-new/defs.h >>>> --- crash-4.0/defs.h 2006-09-14 21:41:50.000000000 -0400 >>>> +++ crash-4.0-new/defs.h 2006-09-14 21:48:37.000000000 -0400 >>>> @@ -2297,6 +2297,7 @@ struct efi_memory_desc_t { >>>> #define _64BIT_ >>>> #define MACHINE_TYPE "PPC64" >>>> >>>> +#define PPC64_64K_PAGE_SIZE 65536 >>>> #define PAGEBASE(X) (((ulong)(X)) & (ulong)machdep->pagemask) >>>> >>>> #define PTOV(X) ((unsigned long)(X)+(machdep->kvbase)) >>>> diff -Naurp crash-4.0/ppc64.c crash-4.0-new/ppc64.c >>>> --- crash-4.0/ppc64.c 2006-09-14 21:41:50.000000000 -0400 >>>> +++ crash-4.0-new/ppc64.c 2006-09-14 21:50:26.000000000 -0400 >>>> @@ -67,19 +67,6 @@ ppc64_init(int when) >>>> machdep->verify_symbol = ppc64_verify_symbol; >>>> if (pc->flags & KERNEL_DEBUG_QUERY) >>>> return; >>>> - machdep->pagesize = memory_page_size(); >>>> - machdep->pageshift = ffs(machdep->pagesize) - 1; >>>> - machdep->pageoffset = machdep->pagesize - 1; >>>> - machdep->pagemask = ~((ulonglong)machdep->pageoffset); >>>> - machdep->stacksize = 4 * machdep->pagesize; >>>> - if ((machdep->pgd = (char *)malloc(PAGESIZE())) == >>>> >>> NULL) >>> >>>> - error(FATAL, "cannot malloc pgd space."); >>>> - if ((machdep->pmd = (char *)malloc(PAGESIZE())) == >>>> >>> NULL) >>> >>>> - error(FATAL, "cannot malloc pmd space."); >>>> - if ((machdep->ptbl = (char *)malloc(PAGESIZE())) == >>>> >>> NULL) >>> >>>> - error(FATAL, "cannot malloc ptbl space."); >>>> - if ((machdep->machspec->level4 = (char >>>> >>> *)malloc(PAGESIZE())) == NULL) >>> >>>> - error(FATAL, "cannot malloc level4 space."); >>>> machdep->last_pgd_read = 0; >>>> machdep->last_pmd_read = 0; >>>> machdep->last_ptbl_read = 0; >>>> @@ -93,6 +80,40 @@ ppc64_init(int when) >>>> break; >>>> >>>> case PRE_GDB: >>>> + /* >>>> + * Recently there were changes made to kexec tools >>>> + * to support 64K page size. With those changes >>>> + * vmcore file obtained from a kernel which supports >>>> + * 64K page size cannot be analyzed using crash on a >>>> + * machine running with kernel supporting 4K page size >>>> + * >>>> + * The following modifications are required in crash >>>> + * tool to be in sync with kexec tools. >>>> + * >>>> + * Look if the following symbol exists. If yes then >>>> + * the dump was taken with a kernel supporting 64k >>>> + * page size. So change the page size accordingly. >>>> + * >>>> + * Also moved the following code block from >>>> + * PRE_SYMTAB case here. >>>> + */ >>>> + if (symbol_exists("__hash_page_64K")) >>>> + machdep->pagesize = PPC64_64K_PAGE_SIZE; >>>> + else >>>> + machdep->pagesize = memory_page_size(); >>>> + machdep->pageshift = ffs(machdep->pagesize) - 1; >>>> + machdep->pageoffset = machdep->pagesize - 1; >>>> + machdep->pagemask = ~((ulonglong)machdep->pageoffset); >>>> + machdep->stacksize = 4 * machdep->pagesize; >>>> + if ((machdep->pgd = (char *)malloc(PAGESIZE())) == >>>> >>> NULL) >>> >>>> + error(FATAL, "cannot malloc pgd space."); >>>> + if ((machdep->pmd = (char *)malloc(PAGESIZE())) == >>>> >>> NULL) >>> >>>> + error(FATAL, "cannot malloc pmd space."); >>>> + if ((machdep->ptbl = (char *)malloc(PAGESIZE())) == >>>> >>> NULL) >>> >>>> + error(FATAL, "cannot malloc ptbl space."); >>>> + if ((machdep->machspec->level4 = (char >>>> >>> *)malloc(PAGESIZE())) == NULL) >>> >>>> + error(FATAL, "cannot malloc level4 space."); >>>> + >>>> machdep->kvbase = symbol_value("_stext"); >>>> machdep->identity_map_base = machdep->kvbase; >>>> machdep->is_kvaddr = generic_is_kvaddr; >>>> >>> The patch looks safe enough. >>> >>> A couple things I just noticed though... >>> >>> Is it true that the process stack size will be 256K? And the >>> ppc64 hardware interrupt stack would be 512K? Based upon >>> the machdep->pagesize value, these inititializations get done >>> later: >>> >>> machdep->stacksize = 4 * machdep->pagesize; >>> >>> machdep->machspec->hwstacksize = 8 * machdep->pagesize; >>> >>> If they have not increased, won't the backtrace code get confused? >>> >>> Thanks, >>> Dave >>> >>> >> The kernel's asm-powerpc/thread_info.h file doesn't >> show any change in stack size, which I didn't expect >> it would anyway: >> >> #ifdef __KERNEL__ >> >> /* We have 8k stacks on ppc32 and 16k on ppc64 */ >> >> #ifdef CONFIG_PPC64 >> #define THREAD_SHIFT 14 >> #else >> #define THREAD_SHIFT 13 >> #endif >> >> #define THREAD_SIZE (1 << THREAD_SHIFT) >> >> and the hardware interrupt stack seems to only be in >> the paca_struct in 2.4 kernels. >> >> I think we can safely hardwire those two values anyway, >> right? >> >> > Sachin, Yes, we should be hardcoding the stack size value (16K). It does > not matter for hardware intr stack which is used only for 2.4 kernel and > supports only 4K page. Uses soft IRQ and hard IRQ stacks in 2.6 kernel > for interrupt context and their sizes are the same as THREAD_SIZE. > > This patch should also support backward compatibility since the symbol > __hash_page_64K does not exist and thus the page size is always 4K. > > Thanks, Haren. Sachin is probably blissfully asleep and not aware of this discussion, so I will go ahead and modify his patch to: (1) hardwire the process stack size, and (2) as you state, it doesn't really make a difference for the 2.4 kernel since it won't ever see the larger pagesize.

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