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@xxxxxxxxxx>
> >> > --
> >> >
> >> > 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
