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

[Dave Anderson]

- Support for Fedora FC9 kernels containing the linux-2.6.utrace.patch,
   which removes the task_struct.parent member.  Without the patch, the
   crash session fails during initialization with the error message:
   "crash: invalid structure member offset: task_struct_parent".
   (anderson at redhat.com)

- Available in Fedora Rawhide devel branch:
     build devel:crash-4.0-6.3
     http://koji.fedoraproject.org/koji/buildinfo?buildID=47600

- Further scalability improvements to the "search -k" mechanisms.
   (anderson at redhat.com)

- Changed ppc64 manner of determining the number of cpus to first check
   the cpu_present_map, and only if that doesn't exist, continue to use
   the cpu_online_map.  Without the patch, depending upon which cpus
   were offline, crash sessions could fail during initialization with
   the error message: "crash: cannot determine idle task addresses from
   init_tasks[] or runqueues[]".  (anderson at redhat.com)

- Fix/workaround for the ppc64 "bt" command on panic/active tasks when
   run against dumpfiles whose kernel had crashed with one or more
   cpus offline.  Without the patch, the "bt" command could cause a
   segmentation violation, or fail because the starting stack location
   and instruction pointer were invalid.  With the patch, an error
   message will be displayed, indicating that the NT_PRSTATUS note for
   that task could not be determined.  (anderson at redhat.com)

- Added support for vtop translation of 1MB large pages available on
   new z10 (s390x) systems. (holzheu at linux.vnet.ibm.com)

- Prevent misleading init-time warning message for s390/s390x when
   verifying the vmlinux file with respect to the host machine type.
   Without the patch, this message would appear when running on s390
   or s390x machines: "WARNING: machine type mismatch: crash utility:
   S390X /usr/lib/debug/lib/modules/2.6.18-86.el5/vmlinux: (unknown)"
   (holzheu at linux.vnet.ibm.com)

- Minor documentation fix to crash.8 man page, moving the "wr" command
   from being munged into the "whatis" description into its own list
   entry.  (yamato at redhat.com)

- Support for running against an x86 xen-syms hypervisor binary based
   upon xen 3.1.2 or later.  Without the patch, the session would fail
   to recognize that it was PAE, and "bt" commands on the non-active
   task would fail with the error messages "bt: cannot resolve stack
   trace" and "bt: invalid structure size: task_struct".
   (oda at valinux.co.jp, anderson at redhat.com)

- Support for running against an x86_64 xen-syms hypervisor binary
   based upon xen 3.1.2 or later.  Without the patch, the session would
   fail during initialization with the error message: "crash: cannot
   resolve idle_pg_table_4".  In addition, the x86_64 xen-syms
   hypervisor is now relocatable, but the kdump vmcore does not
   (currently) export the base physical address of the relocated
   hypervisor text and static data.  Without that knowledge, the crash
   utility cannot make virtual to physical address translations, and
   therefore cannot navigate through the vmcore.  To address that
   shortcoming, a patch is required for either the xen hypervisor code
   or the kexec-tools package to export the value of the hypervisor's
   "xen_phys_start" symbol to the vmcore.  Until such time, however, a
   workaround has been put in place to pass the value with a new command
   line option that is invoked like so:

     # crash --xen_phys_start <address> xen-syms vmcore

   The value of the xen_phys_start <address> argument can be
   determined in two ways, either from /proc/iomem on the live
   system running the dom0 kernel that generated the kdump, or by
   running crash on the target vmcore using the dom0 vmlinux file.
   For example, on this system, the <address> argument would be
   3ee00000:

     # cat /proc/iomem | grep Hypervisor
       3ee00000-3fdfffff : Hypervisor code and data
     #

   Alternatively, the vmcore file in this example indicates that the
   <address> argument would be 0x3f000000:

     # crash vmlinux vmcore
     ...
     crash> px xen_hypervisor_res
     xen_hypervisor_res = $3 = {
       start = 0x3f000000,
       end = 0x3fffffff,
       name = 0xffffffff8049ab72 "Hypervisor code and data",
       flags = 0x80000200,
       parent = 0xffff880000001180,
       sibling = 0x0,
       child = 0xffff8800000000a8
     }

   If the --xen_phys_start command line option is not used, the session
   will fail during initialization.  However there will be a warning
   message preceding the failure indicating: "WARNING: This hypervisor
   is relocatable; if initialization fails below, try using the
   --xen_phys_start <address> command line option".  Eventually the
   value of the hypervisor's "xen_phys_start" will be passed in the
   vmcore header, obviating the need for this workaround.
   (oda at valinux.co.jp, anderson at redhat.com)

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