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

[Dave Anderson]

- For 2.6.14 and later ia64 kdumps, taken either as a result of the
  INIT switch, or when an MCA exception has occurred, several problems
  needed to be addressed.  First, the "pseudo-task" that handles the
  kdump operation due to an INIT or MCA was not being recognized as
  the "panic" task.  Secondly, the backtraces of the per-cpu INIT
  or MCA handling pseudo-tasks only went back as far as their entry
  onto their own per-cpu stacks, and did not show the backtrace of
  the task that was running on that cpu when the INIT or MCA event
  occurred.  This version recognizes the pseudo-task that handles the
  kdump operation; and for each cpu, the active tasks' backtraces now
  also show a transition back to the task that was running on that cpu
  when the INIT or MCA event occurred.  (j-nomura at ce.jp.nec.com)

- To address the need to display per-cpu variables, the "p"
  command has been modified to recognize "per_cpu__xxx" arguments
  when the kernel is SMP, in order to prevent the attempt to display
  the contents of a variable whose symbol value does not represent
  the actual location of its data.  In that case, the data type of
  the per-cpu variable will be displayed, followed by the addresses
  of each per-cpu instance.  Given that information, a proper command
  can be utilized in order to display the data.  For example, to look
  at the per-cpu buffer_head accounting for cpu 2:

    crash> p per_cpu__bh_accounting
    PER-CPU DATA TYPE:
      struct bh_accounting per_cpu__bh_accounting;
    PER-CPU ADDRESSES:
      [0]: c5405a80
      [1]: c540da80
      [2]: c5415a80
      [3]: c541da80
    crash> bh_accounting c5415a80
    struct bh_accounting {
      nr = 434,
      ratelimit = 2216
    }

  Note that "p" on the first command line above is optional, because
  whenever a data variable is entered alone, crash will recognize it
  as such, and pass it to the "p" command by default.  I had thought
  of putting this functionality into the "struct" command, but many
  of the per-cpu variables are pointers, arrays, etc..  So for the
  non-structure cases, the "rd" command would be more appropriate,
  or alternatively a cobbled-together gdb print command.
  (anderson at redhat.com)

- A consolidated cleanup and minor fixes patch has been applied to
  the experimental x86_64 dwarf CFI unwind facility.
  (rachita at in.ibm.com)

- Also related to the experimental x86_64 dwarf CFI unwind facility,
  fixed a problem where if a "set unwind on" was done, and followed
  by a subsequent "set unwind off", then the "bt" output could either
  cause a segmentation violation, or display backtrace data that was
  different from the original.  (anderson at redhat.com)

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061115/f43c7a55/attachment.htm>