- 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(a)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(a)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(a)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(a)redhat.com) - Added support for vtop translation of 1MB large pages available on new z10 (s390x) systems. (holzheu(a)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(a)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(a)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(a)valinux.co.jp, anderson(a)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(a)valinux.co.jp, anderson(a)redhat.com) Download from: http://people.redhat.com/anderson