[Crash-utility] crash version 4.0-4.5 is available

[Dave Anderson]

  - Addresses FC7/upstream x86 kernels that have been configured such
    that the vmlinux symbol values do not match their relocated values
    when loaded.  If CONFIG_PHYSICAL_START contains an value that is
    greater then CONFIG_PHYSICAL_ALIGN, then this mismatch occurs.
    Since the crash utility and its embedded gdb have always expected
    that the compiled-in kernel symbol addresses are "real", the virtual
    to physical translation fails, leading to an initialization-time
    failure with the message: "crash: vmlinux and /dev/crash do not
    match!" (/dev/mem or the dumpfile name may replace /dev/crash).
    To deal with this issue, there are several alternatives:

     1) Configure the kernel with CONFIG_PHYSICAL_START less than
        or equal to CONFIG_PHYSICAL_ALIGN.  Having done that, there
        is no problem; the resultant vmlinux file will be loaded at
        the address for which it was compiled, which has always
        been the case.
     2) Since /proc/kallsyms uses the same format as a System.map file,
        and since it reflects the relocated symbol addresses, it
        can be placed on the crash command line as if it were
        a System.map file.  (Note that the System.map file created
        by these relocated kernels contains the same "wrong" symbol
        values as the vmlinux file from which it was created.)
     3) On a live system that has /proc/kallsyms (i.e., the kernel was
        configured with CONFIG_KALLSYMS), this version of the crash
        utility will replace/patch the vmlinux symbol values with those
        seen in /proc/kallsyms.  The relocation value will be displayed
        as a WARNING message during initialization.
     4) On a dumpfile, the relocation will not be performed automatically
        as on a live system.  It will require the addition of the
        /proc/kallsyms on the command line, or if run on a different
        host, a copy of the crashed system's /proc/kallsyms may be
        used.
     5) Alternatively on a dumpfile, a new command line option has been
        created to specify the relocation amount.  For example, if a
        kernel was configured with a CONFIG_PHYSICAL_START value of 16MB
        and a CONFIG_PHYSICAL_ALIGN of 4MB, that results in a relocation
        of 12MB.  To specify that, enter "crash --reloc=12m ..." on the
        command line.  (Recall that if crash is run on the live system,
        a WARNING message will specify the relocation amount.)

    Using /proc/kallsyms or a --reloc=[size] as a command line argument
    is similar to using a System.map file, in that it results in the loss
    of the use of line number debug data.  (anderson at redhat.com)

  - Fix for x86 2.6.22 kernel initialization-time failure indicating:
    "crash: invalid size request: 0  type: __per_cpu_offset"
    (oomichi at mxs.nes.nec.co.jp)

  - Fix to recognize the 2.6.22 kernel's replacement of kmalloc slab
    subsystem from the "./mm/slab.c" file to CONFIG_SLUB-configured
    kernels that use the infrastructure in "./mm/slub.c".  Without this
    fix, crash sessions would fail during initialization with the message
    "crash: invalid structure member offset: kmem_cache_s_c_num".
    (anderson at redhat.com)

  - Cliff Wickman sent an additional patch for the LKCD kerntypes
    support he introduced in version 4.0-4.4, which addresses this
    message that is seen during initialization on 2.6.22 kernels:
    "WARNING: cannot determine pgdat list for this kernel/architecture".
    (cpw at sgi.com)

  - NOTE: The CONFIG_SLUB change in the 2.6.22 kernel will require a
    significant update in the crash utility in order for "kmem -[sS]"
    options to work again.

  - NOTE: 2.6.22 kernels have replaced the O(1) scheduler with the
    new CFS scheduler.  As a result, the "runq" command fails, which
    will require a crash utility update to recognize and display the
    contents of each cpu's run queue.


Download from: http://people.redhat.com/anderson