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

[Dave Anderson]

 - Tentatively scheduled as the baseline version for the RHEL5.4 crash
   utility errata release.
 
 - Implemented a new "bt -g" option, which will display the backtraces
   of all threads in the targeted task's thread group.  The thread 
   group leader's backtrace will be displayed first, regardless of 
   which task was the target of the "bt" command.
   (anderson at redhat.com)
 
 - Implement support for the kdump "split-dumpfile" format, which can 
   split /proc/vmcore into multiple dumpfiles as specified by the 
   "makedumpfile --split" command option.  It simply requires that all
   of the split dumpfile names be entered on the crash command line.
   (tindoh at redhat.com)
 
 - Fix for "kmem -i", "kmem -n" and "kmem -p" on x86_64 CONFIG_SPARSEMEM 
   and CONFIG_SPARSEMEM_EXTREME kernels that have MAX_PHYSMEM_BITS 
   increased from 40 to 44.  Without the patch, erroneous page-related 
   data could be displayed depending upon the amount of physical memory 
   contained by the target system.  
   (anderson at redhat.com)
 
 - For the architectures that support it, the "--machdep option=value"
   command line option has been modified to allow more than one machine-
   dependent argument.  (anderson at redhat.com)
 
 - The starting backtrace location of active, non-crashing, xen dom0 
   tasks are not available in kdump dumpfiles, nor is there anything 
   that can be searched for in their respective stacks.  Therefore, for
   those those tasks, the "bt" command will indicate: "bt: starting 
   backtrace locations of the active (non-crashing) xen tasks cannot be
   determined: try -t or -T options".  Without the patch, the backtrace
   would either be empty, or it would show an invalid backtrace starting
   at the last location where schedule() had been called. 
   (anderson at redhat.com)
 
 - Fix for potentially empty "bt -t" output, and for "bt -T" potentially
   dumping the text return addresses in the hard or soft IRQ stacks 
   instead of the process stack.  This could occur if the targeted task
   was the last task that used the hard or soft IRQ stack (x86 only).
   (anderson at redhat.com)
 
 Download from: http://people.redhat.com/anderson