- Fix for the x86 "bt" command when a newly-forked task's resumption EIP address value is set to the "ret_from_fork" entry point by copy_thread(). Without the patch, the backtrace attempt would display "bt: cannot resolve stack trace", dump the text symbols on the stack, and a possible USER-MODE exception frame. (anderson(a)redhat.com) - Fix for the x86 "bt" command if the kdump-generated NMI interrupts a task running in kernel space at a point in the system_call entry point code prior to the call to a system call function. Without the patch, the backtrace attempt would display "bt: cannot resolve stack trace", dump the text symbols on the kernel stack, and display any "KERNEL-MODE" exception frames followed by a possible "USER-MODE" exception frame. (anderson(a)redhat.com) - Fix for the "bt" command on 2.6.29 and later x86_64 kernels to recognize and display exception frames generated by exceptions that do not result in a stack switch, such as general protection faults. Without the patch, the backtrace would potentially not display the exception frames because the "error_exit" assembly-code label in entry_64.S was replaced by the error_exit() entry point. (anderson(a)redhat.com) - The kernel patch for ppc64 CONFIG_SPARSEMEM_VMEMMAP kernels that stores vmemmap page mapping information so that the crash utility is able to translate vmemmap'd kernel virtual addresses has been updated. The crash utility patch that was (preemptively) applied in 5.0.2 for the initial kernel patch needs this update. (anderson(a)redhat.com) - Fix the error message for the "dev -p" comand when run on 2.6.26 or later kernels, which no longer have the global "pci_devices" list head. The patch changes the message to show "dev: -p option not supported or applicable on this architecture or kernel", instead of the misleading "dev: no PCI devices found on this system" message. (anderson(a)redhat.com) - If a cpu in an s390 or s390x dumpfile is offline, and the "bt" command receives a backtrace request for the "swapper" task on that cpu, the command will display "CPU offline". (holzheu(a)linux.vnet.ibm.com) - Fix for 2.6.34 and later x86_64 kernels which generate per-cpu symbols of type 'd' or type 'D' instead of type 'V'. Without the patch, an x86_64 crash session fails during initialization with the error message "crash: cannot determine idle task addresses from init_tasks[] or runqueues[]", followed by "crash: cannot resolve init_task_union". It is unclear why some kernel builds result in only type 'V' per-cpu symbols, whereas others result in in type 'd' and 'D', so the patch accepts both. (Kashyap.Desai(a)lsi.com) - Fix to prevent a segmentation violation during initialization in the x86_64_get_active_set() function by verifying that the array of current tasks in machdep->machspec->current[] has actually been allocated. Theoretically it should never be NULL, but in the unlikely event that x86_64_per_cpu_init() fails to find the required per-cpu symbols, it will return without allocating the array. (anderson(a)redhat.com) - Fix to support KVM dumpfiles created with "virsh dump" that create "cpu" header sections using a QEMU CPU_SAVE_VERSION version greater than the supported version of 9. Without the patch, the crash session fails during initialization with the error message "crash: qemu-load.c:501: cpu_init_load_64: Assertion `version_id >= 4 && version_id <= 9' failed." The patch now accepts CPU_VERSION_VERSION values up to 12. (anderson(a)redhat.com) - Fix for x86_64 KVM dumpfiles created with "virsh dump" whose kernels have a "_text" virtual address higher than __START_KERNEL_map. Without the patch, the physical base address calculation fails, making the dumpfile unusable. (anderson(a)redhat.com, pbonzini(a)redhat.com) - Implemented a new "map" command that is seen only when running with KVM guest dumpfiles created with "virsh dump". The layout of this dumpfile format does not allow the access of system memory in a "random-access" manner. Therefore, during session initialization, a potentially time-consuming dumpfile scan procedure is required to create a physical-memory-to-file-offset memory map for use during the session. The new "map" command allows the user to either append the memory map to the end of the dumpfile, or to create a discrete memory map file. In either case, the dumpfile scan will not be required during subsequent sessions. The command's help page may be seen by entering "crash -h map". (anderson(a)redhat.com) - Fix for an incorrect calculation of the physical base address of a fully-virtualized x86_64 RHEL6 guest kernel running on a RHEL5 Xen host. Without the patch, the session failed during initialization with the error messages "crash: cannot determine base kernel version" and "crash: vmlinux and vmcore do not match!" (anderson(a)redhat.com) - Fix for the "bt" command on inactive (blocked) tasks on 2.6.33 and later x86_64 kernels, which have the "thread_return" symbol removed from the embedded "switch_to" macro. Without the patch, when run on blocked tasks, the command would fail with the error message "bt: cannot resolve thread_return". (anderson(a)redhat.com) - Fix for the "bt" command on 2.6.33 and later x86 kernels, which moved the "system_call" assembly function to the .kprobes.text section. Without the patch, the command would typically display two invalid stack frames, both indicating they were in "ia32_sysenter_target". (anderson(a)redhat.com) - Fix for a segmentation violation caused by the "extensions/trace.c" extension module, as seen when running the "trace show -c <cpu>" command from that module. (laijs(a)cn.fujitsu.com) - Implemented a "trace dump -t" command for the "extensions/trace.c" extension module. The module already has a "trace show" command to show what events had happened before the system crashed, but it is just 1000 lines of code and it is not as complete as the related "trace-cmd report" command from trace-cmd(1). The new extension module command generates a "trace.dat" file, which in turn can be used by the "trace-cmd report" option of trace-cmd(1). So this patch improves both the crash trace command and the trace-cmd(1) as well, which can now handle ftrace even if the kernel crashed. (laijs(a)cn.fujitsu.com) Download from: http://people.redhat.com/anderson