[Crash-utility] [ANNOUNCE] crash version 5.1.0 is available

[Dave Anderson]

 Changelog:

 - Fix for the x86 "bt" command for the active, non-crashing, tasks
   in 2.6.31 and later KVM dumpfile kernels that are not configured
   with CONFIG_4KSTACKS.  Without the patch, the exception frame
   generated by the reboot_interrupt() entry point is not displayed,
   and if the task was running in user space, the command would 
   generate a "bt: cannot resolve stack trace" error message.
   (anderson at redhat.com)

 - Ksplice Inc. proposed a patch which added the module name to x86 and 
   x86_64 "bt" frame displays so that it would be readily evident that 
   a kernel function had been replaced by a ksplice module function.  
   Given that the functionality is useful for the frame display of any 
   kernel module function, it has been extended to be used in the "bt" 
   output of the other architectures, as well as in the output of the 
   "bt -[tT]" options.
   (nelhage at ksplice.com, anderson at redhat.com)

 - Enhance the "sym" command to display the containing module name
   name in brackets (if applicable) when entering a virtual address, 
   symbol name, or symbol query argument.
   (anderson at redhat.com)

 - Implemented support for the recognition and display of module per-cpu  
   symbols after they have been loaded by the "mod -[sS]" command.  
   Without the patch, any per-cpu symbols declared by a module were not 
   recognized or displayed at all.  With the patch, they are displayed
   in the module's symbol list, and as is the case with base kernel 
   per-cpu symbols, they can be the target of the "p" command in order 
   to show their type and per-cpu virtual addresses.
   (nakayama.ts at ncos.nec.co.jp, anderson at redhat.com)

 - Fix for the x86 "bt" command to properly handle a NMI-interrupted
   idle task running in cpu_idle().  Without the patch, the backtrace 
   indicated "bt: cannot resolve stack trace" even though it had resolved 
   the trace correctly.
   (anderson at redhat.com)

 - Implemented support for s390x compressed kdump dumpfiles created
   by the makedumpfile facility.
   (mahesh at linux.vnet.ibm.com)

 - Fix for the "bt" command on x86 Xen hypervisor dumpfiles where a vcpu
   received a shutdown NMI while running in the event_check_interrupt() 
   interrupt handler.  Without the patch, the backtrace would indicate 
   "bt: cannot resolve stack trace", and dump the text symbols on the 
   stack.  The patch recognizes all hypervisor entry points at the
   top of the vcpu stack.
   (anderson at redhat.com)

 - Fix for the "bt" command on x86 Xen hypervisor dumpfiles where a vcpu
   received a shutdown NMI while running in the hypercall entry point,
   but its return address on the stack gets perceived as an assembly 
   label symbol within the hypercall code.  Without the patch, the 
   backtrace would indicate "bt: cannot resolve stack trace", and dump
   the text symbols on the stack.  The patch replaces the assembly
   label symbol name with "hypercall".
   (anderson at redhat.com)

 - Fix for the "help -n" output for s390x ELF vmcore dumpfiles to
   recognize the EM_S390 e_machine value, the NT_FPREGSET n_type,
   and the new NT_S390_TIMER, NT_S390_TODCMP, NT_S390_TODPREG, 
   NT_S390_CTRS and NT_S390_PREFIX n_types.  Without the patch
   the e_machine field showed "(unsupported)", and the n_types 
   showed "(?)".
   (anderson at redhat.com)

 - Fix for the "help -n" output for s390x ELF vmcore dumpfiles to
   properly dump the contents of the descriptor data of each Elf64_Nhdr 
   note.  Without the patch, the pointer to the descriptor data was 
   incorrectly calculated and the resultant data output was "shifted".
   (anderson at redhat.com)

 - Fix for the "help -n" output for diskdump and compressed kdump
   files to show the file name as stored in the per-file diskdump_data
   structure.  Without the patch, only "split" dumpfiles displayed their
   individual dumpfile names, whereas single dumpfiles showed "(null)".
   (anderson at redhat.com)

 - Resurrection of the "irq -b" command option for 2.6 kernels.
   (anderson at redhat.com)

 - Fix for the displaying of data generated from shell-escaped commands
   when the data contains a "%" character followed by a conversion 
   character.  Without the patch, a segmentation violation may occur 
   when the a conversion gets attempted by fprintf().
   (anderson at redhat.com)

 - Reworked the do_radix_tree() utility function to work without 
   depending upon a hardwired copy of the kernel's radix_tree_node
   structure, and changed the RADIX_TREE_MAP_SHIFT, RADIX_TREE_MAP_SIZE
   and RADIX_TREE_MAP_MASK #define's into dynamically calculated values.
   (anderson at redhat.com)

 - Call FREEBUF() on a GETBUF()-generated buffer in the do_radix_tree() 
   utility function.
   (wang.chao at cn.fujitsu.com)

 - Store the .debug_frame section offset and size from the vmlinux file,
   and use its data as an alternative to the .eh_frame section data in 
   the x86_64 unwind code.
   (wang.chao at cn.fujitsu.com)

 - Fix for the "irq" command when run on 2.6.29 kernels, which declared
   the irq_desc_ptrs as a static array indexed by NR_IRQS.  Without the
   patch, the command would show nonsensical IRQ data or fail with the 
   error message "irq: invalid kernel virtual address: <address>  type:
   hw_interrupt_type typename".
   (anderson at redhat.com)

 - Fix for the "irq" command to run with 2.6.34 or later kernels that
   replaced the array of irq_desc structures or irq_desc pointers with 
   a radix tree.  Without the patch, the command would fail with the
   error message "irq: x86_64_dump_irq: irq_desc[] does not exist?".
   (anderson at redhat.com)

 - As of 2.6.37, the output of the "irq" command will change from the
   current manner of displaying a few cherry-picked structure members 
   that are of questionable usefulness and a nightmare to maintain.  The
   new scheme displays the address of the irq_desc/irq_data structure, 
   and a list of one or more associated irqaction structures and their 
   name string.  With that information, it is simple matter to ascertain
   any other desired data concerning the IRQ.
   (anderson at redhat.com)
   
  Download from: http://people.redhat.com/anderson