[Crash-utility] [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
Dave Anderson
anderson at redhat.com
Wed Dec 21 16:58:23 UTC 2011
----- Original Message -----
>
>
> ----- Original Message -----
>
> > > This would seem to be a little extreme. If by chance CONFIG_SPARSEMEM
> > > is not configured, or for that matter, in old pre-sparsemem kernels,
> > > "mem_section" doesn't even exist as a symbol. So there should be an
> > > IS_SPARSEMEM() qualifier to prevent the FATAL session-ending
> > > error.
> > >
> > > I'm waiting for an s390x reservation as we speak, and I'll change
> > > (and test) the patch to do something like:
> > >
> > > if (IS_SPARSEMEM() &&
> > > !set_s390x_max_physmem_bits())
> > > error(FATAL, ...
> >
> > Actually that won't suffice, because the POST_GDB init call is done
> > before vm_init(). I'll add a new POST_VM case label to the s390x_init()
> > switch statement, and move the set_s390x_max_physmem_bits() call
> > there.
>
> ... which won't work either, because vm_init() calls sparse_mem_init()
> which needs the MAX_PHYSMEM_BITS to be already set.
>
> I guess we'll have to check for the existence of the mem_section array
> and preemptively/redundantly make the STRUCT_SIZE_INIT() call in your
> function so that we can still do it all POST_GDB.
And complicating matters even further, your patch presumes that the
kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured
with just CONFIG_SPARSEMEM alone? If so, your patch breaks down.
Or is there another way you can determine which MAX_PHYSMEM_BITS value
is in use?
Dave
More information about the Crash-utility
mailing list