| crash-5.1.8-3.el5_11.x86_64
[2.3 MiB] |
Changelog
by Dave Anderson (2015-02-17):
- Fix for kernel CVE-2014-9322
Resolves: rhbz#1192396
|
| crash-5.1.8-2.el5_9.x86_64
[2.3 MiB] |
Changelog
by Dave Anderson (2012-12-04):
- Fix to handle xen dom0 dumpfiles created with "makedumpfile -d1" on very
large systems, where the ELF vmcore may be mistakenly determined to be
an old-style netdump vmcore.
Resolves: rhbz#876046
|
| crash-5.1.8-1.el5.x86_64
[2.3 MiB] |
Changelog
by Dave Anderson (2011-10-04):
- Rebase to upstream version 5.1.8.
Resolves: rhbz#715072
- Fix for the x86_64 "bt" command if the shutdown NMI is issued to a
32-bit task that has executed a "sysenter" instruction and the RSP
still contains the zero value loaded from the MSR_IA32_SYSENTER_ESP
register. The backtrace issued a warning message indicating
"WARNING: possibly bogus exception frame", and was unable to make a
transition from the NMI exception stack back to the process stack.
Resolves: rhbz#676408
- Fix for the x86 "bt" command for several backtraces of non-crashing
active tasks that fail with "bt: cannot resolve stack trace" errors
due to the failure to properly transition from the shutdown NMI stack
back to the process stack.
Resolves: rhbz#713050
- Fix to more correctly determine the KVM I/O hole size and location.
The I/O hole size to this point in time is either 1GB or 512MB, but
its setting is hardwired into the Qemu code that was used to create
the dumpfile. The dumpfile is a "savevm" file that is designed to be
used for guest migration, and since inter-version save/load is not
supported, the I/O hole information does not have to be encoded into the
dumpfile. Without the patch, the I/O hole for dumpfiles created by
older Qemu version was not being set to 1GB, so if the KVM guest was
configured with more than 3GB of memory, the crash session would
typically display numerous "read error" messages during session
initialization.
Resolves: rhbz#715070
- Fix for KVM dumpfiles from guests that were provisioned with more
than 3.5GB of RAM. KVM virtual systems contain an I/O hole in the
physical memory region from 0xe0000000 to 0x100000000 (3.5GB to 4GB).
If a guest is provisioned with more than 3.5GB of RAM, then the
memory above 3.5GB is "pushed up" to start at 0x100000000 (4GB).
But the "ram" device headers in the KVM dumpfiles do not reflect
that, and so without the patch, numerous error messages would be
displayed during invocation, and in all probability, the session
would fail.
Resolves: rhbz#716327
|
| crash-4.1.2-8.el5.x86_64
[1.7 MiB] |
Changelog
by Dave Anderson (2010-12-03):
- Fix for potential segmentation violation in glibc malloc/free when
running "kmem -s" on a large, active, live system.
Resolves: rhbz#659593
|
| crash-4.1.2-4.el5_5.1.x86_64
[1.7 MiB] |
Changelog
by Dave Anderson (2010-06-08):
- Fix for backtrace of x86 NMI-interrupted task with a user exception frame
from a syscall exception that had not called the requested system call
function.
Fix for backtrace when a newly-forked x86 task's resumption EIP address
value is set to the "ret_from_fork" entry point by copy_thread().
Resolves: rhbz#601089
- Fix for segmentation violation with the "mach -m" command option on x86
or x86_64 systems whose BIOS-provided e820 map contains EFI-related memory
type value that has not been mapped to an E820 type.
Resolves: rhbz#601082
- Fix for the "kmem -s list" command option to prevent it from attempting
to gather a slab cache name string from the "cache_chain" list_head.
Resolves: rhbz#601084
- Change the ppc64 cpu count displayed by the initial system banner
and by the "sys" and "mach" commands to be the number of cpus online.
Resolves: rhbz#601088
- Fix for backtrace of an x86_64 NMI-interrupted task which had not
swapped its RSP from the user-space stack to the kernel stack.
Resolves: rhbz#601081
|
| crash-4.1.2-4.el5.x86_64
[1.7 MiB] |
Changelog
by Dave Anderson (2010-02-10):
- Fix for very large xendump core files whose ELF sections are located
beyond a file offset of 4GB.
- Resolves: rhbz#561767
|
| crash-4.0-8.9.1.el5.x86_64
[1.7 MiB] |
Changelog
by Dave Anderson (2009-06-11):
- Fix for running "foreach bt" on a live system, where a backtrace that
is attempted on a task that no longer exists may cause a segmentation
violation due to the use of stale/invalid kernel stack pointer.
- Resolves: rhbz#504796
|
| crash-4.0-7.2.3.el5.1.x86_64
[1.7 MiB] |
Changelog
by Dave Anderson (2009-01-13):
Fix for a "bt" command segmentation violation by correctly
handling the transition from the IRQ stack back to the process
stack running when running against a Xen kernel.
- Resolves: rhbz#479810
|
| crash-4.0-7.2.3.x86_64
[1.7 MiB] |
Changelog
by Dave Anderson (2008-09-25):
Fix for the incomplete resolution for the "search -k" option when
run on RHEL5 ia64 CONFIG_SPARSEMEM kernels. The initial fix
addressed the segmentation violation, but on certain physical
memory configurations, it would prematurely bail out when making
the transition from the kernel mapped region to the vmalloc region.
- Resolves: rhbz#458417
|