-
Wed Dec 05 2012 Dave Anderson <anderson@redhat.com> - 5.1.8-2.el5
- 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
-
Wed Oct 05 2011 Dave Anderson <anderson@redhat.com> - 5.1.8-1.el5
- 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
-
Sat Dec 04 2010 Dave Anderson <anderson@redhat.com> - 4.1.2-8.el5
- Fix for potential segmentation violation in glibc malloc/free when
running "kmem -s" on a large, active, live system.
Resolves: rhbz#659593
-
Wed Nov 24 2010 Dave Anderson <anderson@redhat.com> - 4.1.2-7.el5
- Fix for the x86 "bt" command for potential backtrace error of a
NMI-interrupted idle task.
Resolves: rhbz#653288
- Fix for the x86 "bt" command to fix Xen hypervisor backtrace errors
generated when a NMI-interrupted VCPU is running within the hypercall
entry point, and when a NMI-interrupted VCPU is running within an
interrupt handler entry point.
Resolves: rhbz#653823
-
Wed Jul 07 2010 Dave Anderson <anderson@redhat.com> - 4.1.2-6.el5
- Support for "__rhel5" marker device in KVM dumpfile header.
Resolves: rhbz#603027
- Fix for the x86 "bt" command to generically recognize the end of trace
condition for user-space tasks without having to hardwire any more
kernel entry point function names.
Resolves: rhbz#608714
- Fix for the x86_64 "bt" command if the kdump-generated NMI interrupts
a multi-threaded task that has just entered kernel space but has not
changed the RSP stack pointer register from its user-space per-thread
stack location to the kernel stack.
Resolves: rhbz#608171
-
Sat Jun 05 2010 Dave Anderson <anderson@redhat.com> - 4.1.2-5.el5
- 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#572605
- 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#569164
- 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#580589
- 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#580599
- 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#593066
-
Thu Feb 11 2010 Dave Anderson <anderson@redhat.com> - 4.1.2-4.el5
- Fix for very large xendump core files whose ELF sections are located
beyond a file offset of 4GB.
- Resolves: rhbz#561767
-
Thu Jan 21 2010 Dave Anderson <anderson@redhat.com> - 4.1.2-3.el5
- Fix for the "bt" command on an ia64 "INIT" process that interrupted
a task that was running in user space, but was unable to modify the
original (interrupted) task's stack. Without the patch, the "INIT"
task's backtrace would not display the task that was interrupted,
and would display the error message "bt: unwind: failed to locate
return link (ip=<user-virtual-address>)!". With the patch, the
interrupted task information is displayed in the same manner as if
the original stack had been modified.
- Resolves: rhbz#553353
-
Thu Jan 07 2010 Dave Anderson <anderson@redhat.com> - 4.1.2-2.el5
- Fix for a 4.0-8.11 regression that introduced a bug in determining
the number of cpus in ppc64 kernels when the cpu_possible_[map/mask]
has more cpus than the cpu_online_[map/mask]. In that case, the
kernel contains per-cpu runqueue data and "swapper" tasks for the
extra cpus. Without the patch, on systems with a possible cpu count
that is larger than its online cpu count:
(1) the "sys" command will reflect the possible cpu count.
(2) the "ps" command will show the existent-but-unused "swapper"
tasks as active on the extra cpus.
(3) the "set" command will allow the current context to be set to
any of the existent-but-unused "swapper" tasks.
(4) the "runq" command will display existent-but-unused runqueue
data for the extra cpus.
(5) the "bt" command on the existent-but-unused "swapper" tasks will
indicate: "bt: cannot determine NT_PRSTATUS ELF note for active
task: <task>" on dumpfiles, and "(active)" on live systems
- Resolves: rhbz#550419
-
Fri Dec 11 2009 Dave Anderson <anderson@redhat.com> - 4.1.2-1.el5
- Re-based package to upstream version 4.1.2.
- Resolves: rhbz#528184
- If a kdump NMI issued to a non-crashing x86_64 cpu was received while
running in schedule(), after having set the next task as "current" in
the cpu's runqueue, but prior to changing the kernel stack to that of
the next task, then a backtrace would fail to make the transition
from the NMI exception stack back to the process stack, with the
error message "bt: cannot transition from exception stack to current
process stack". This patch will report inconsistencies found between
a task marked as the current task in a cpu's runqueue, and the task
found in the per-cpu x8664_pda "pcurrent" field. If it can be safely
determined that the runqueue setting (used by default) is premature,
then the crash utility's internal per-cpu active task will be changed
to be the task indicated by the appropriate architecture specific value.
Also, a new "set -a <task>" option has been added to manually set a task
to be the "active" task on its cpu.
- Resolves: rhbz#504952
- Fix for a potential segmentation violation during invocation if a
vmcore file, a System.map file, and a non-matching vmlinux file are
used as command line arguments. The problem is that whenever a
System.map file is used, it is presumed that the user knows what he
is doing, and that the vmlinux file is not the same as the kernel
that generated the vmcore; therefore the vmlinux/vmcore matching and
verification routines are not performed. However, if the kernel data
structures in the non-matching vmlinux vary widely enough from the
kernel that generated the vmcore, all manners of bogus data may be
read and consumed. The reported segmentation violation occurred when
using a vmcore created from a "stock" Red Hat kernel with a vmlinux
file from a Red Hat "debug" kernel, where the kernel data structures
are significantly different. The patch adds a several new defensive
mechanisms, and displays additional warning messages, when invalid or
questionable data is read, and as a result the crash session will fail
in a more reasonable manner.
- Resolves: rhbz#508156
- Fix for "bt" command when run against a Xen hypervisor, which showed
a "cannot resolve stack trace" warning message if the cpu received its
shutdown NMI while running in an interrupt handler.
- Resolves: rhbz#510505
- Support for dumpfile format of "virsh dump" of KVM kernels.
- Resolves: rhbz#510519
- Fix for initialization-time failure when running against ppc64 vmcores
if the dump was collected when there were one or more cpus offline in
the system at the time of the crash.
- Resolves: rhbz#520506
- Fix for the x86_64 "bt" command that may possibly start the backtrace
of an active non-crashing task on its per-cpu IRQ stack instead of
starting from the NMI exception stack, causing a faulty transition
back to the process stack, the dumping of a bogus exception fame and
the message "bt: WARNING: possibly bogus exception frame".
- Resolves: rhbz#523512
-
Fri Jun 12 2009 Dave Anderson <anderson@redhat.com> - 4.0-8.9.1.el5
- 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
-
Sat Apr 18 2009 Dave Anderson <anderson@redhat.com> - 4.0-8.9.el5
- Re-based package to upstream version 4.0-8.9.
- Resolves: rhbz#494028
- Fix for nonsensical usage of the "set" command when running
against the xen hypervisor binary. If entered alone on the
command line, the command would cause a segmentation violation,
because there is no concept of a "context" in the xen hypervisor.
In addition, more reasonable error messages are displayed if
"set", "set -c <cpu>", "set -p", or "set <address>" are
attempted when running against a xen hypervisor.
- Resolves: rhbz#462819
- Fix for "irq -d" option when run on x86_64 xen kernels. Without the
patch it would indicate: "irq: invalid structure size: gate_struct"
and dump a stack trace leading to x86_64_display_idt_table(). Now it
will indicate that the -d option is not applicable.
- Resolves: rhbz#464116
- Fixes for the "bt" command when running against the xen hypervisor
binary. The "bt -o" option, and setting it to run by default with
"bt -O", would fail with the vmlinux-specific error message "bt:
invalid structure size: desc_struct" with a stack trace leading
to read_idt_table(); with the patch it will display the generic
error message "bt: -o option not supported or applicable on this
architecture or kernel". The "bt -e" or "bt -E" will also display
the same error message, as opposed to the command usage message.
Lastly, the "bt -R" option would cause a segmentation violation;
it has been fixed to work as it was designed.
- Resolves: rhbz#464288
- Fix for the "bt" command when run on a xen hypervisor in which the
backtrace leads to either "process_softirqs" or "page_fault".
Without the patch, the backtrace indicates: "bt: cannot resolve stack
trace", and then the recovery code terminates the command with the
nonsensical error message: "bt: invalid structure size: task_struct".
- Resolves: rhbz#466724
- Fix for "bt -a" command when running against the xen hypervisor where
the number of physical cpus outnumber the MAX_VIRT_CPUS value for the
processor type. Without the patch on such a system, "bt -a" would
fail after displaying backtraces for the first 32 (MAX_VIRT_CPUS)
pcpus with the the error message: "bt: invalid vcpu". The patch also
corrects the "vcpus" command output to show the vcpus associated with
pcpus 32 through 63, and the "doms" command output to show the second
idle domain associated with pcpus 32 through 63.
- Resolves: rhbz#471790
- Fix for the "bt" command when run on a xen hypervisor in which the
backtrace leads to either "process_softirqs" or "page_fault".
Without the patch, the backtrace indicates: "bt: cannot resolve stack
trace", and then the recovery code terminates the command with the
nonsensical error message: "bt: invalid structure size: task_struct".
- Resolves: rhbz#474712
- Fix for "mod -[sS]" command if the target module object filename
contains both underscore and dash characters. Without the patch
the module load would fail with the error message: "mod: cannot
find or load object file for <name> module". Examples are
the "aes_x86_64" module from the "aes-x86_64.ko" object file, and
the "dm_region_hash" module from the "dm-region_hash.ko" object file.
- Resolves: rhbz#480136
- Changed the manner in which the "bt" command determines which PID 0
swapper task was interrupted by an ia64 INIT or MCA exception.
There is an existing ia64 INIT/MCA handler bug which incorrectly
writes the pseudo task's command name in its comm[] name string
such that the cpu number may not be part of the string. If that
happens without this patch, the "bt" command fails to make the link
back to the interrupted task, and displays the error message:
"bt: unwind: failed to locate return link (ip=0x0)!"
- Resolves: rhbz#487429
- 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.
- 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).
- Resolves: rhbz#495586
-
Fri Jan 09 2009 Dave Anderson <anderson@redhat.com> - 4.0-7.2.4
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#478904
-
Fri Sep 26 2008 Dave Anderson <anderson@redhat.com> - 4.0-7.2.3
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
-
Wed Sep 24 2008 Dave Anderson <anderson@redhat.com> - 4.0-7.2.2
Fix for x86 "bt" command to correctly handle the transition from
the hard IRQ stack back to the process stack and then display
the interrupt exception frame.
- Resolves: rhbz#462624
-
Tue Sep 16 2008 Dave Anderson <anderson@redhat.com> - 4.0-7.2.1
- Fix to prevent a potential divide-by-zero SIGFPE exception when
using a vmlinux that does not match the vmcore being analyzed.
This is a bad, but acceptable, practice, although when done, it
usually requires adding a System.map file to the command line
so that the correct symbol values are used; that was not done
in this case.
- Resolves: rhbz#457371
- Fix for the crash utility's "search -u" option, which searches
the current context's user virtual address space for a given value.
It would cause a SIGSEGV when run on a xen-syms hypervisor binary,
and gives a somewhat misleading error message when run on vmlinux
binary on a kernel thread. Both of these usages are nonsensical
because the xen-syms hypervisor and vmlinux kernel threads do not
have user address space regions. Fix for the "search -k" option,
which searches the kernel virtual address space for a given value.
When run on a xen-syms hypervisor binary, it would display a
nonsensical vmlinux-based error message. That option should not
be used with the xen-syms hypervisor, which requires that a starting
virtual address be supplied. The fix now displays error messages
that are applicable to the incorrect command usage.
- Resolves: rhbz#457373
Fix for the "search -k" option when run on RHEL5 ia64 CONFIG_SPARSEMEM
kernels. It would cause a segmentation violation, because it would
start the search at the base of the ia64 processor's identity-mapped
region, which is not necessarily backed by physical memory, and result
in a SIGSEGV. The fix sets the start of the ia64 kernel virtual address
space search to the appropriate virtual address.
- Resolves: rhbz#458417
Enhancement for invoking crash with an input-file of crash commands
using the -i command-line option, as in "crash -i <input-file> ...",
and doing so from inside a script file instead of the command line.
It would indicates "crash: /dev/tty: No such device or address", run
the commands in the input-file, but then would hang. The fix terminates
the crash session after all of the commands in the input-file have
completed.
- Resolves: rhbz#458422
-
Sat Apr 26 2008 Dave Anderson <anderson@redhat.com> - 4.0-5.0.3
- Fixes for xen 5.2 hypervisor support.
- Resolves: rhbz#442438
-
Fri Jan 18 2008 Dave Anderson <anderson@redhat.com> - 4.0-5.0.2
- Fix for initialization-time segmentation violation when analyzing
a vmcore in which the kernel has over-run its kernel stack,
corrupting the process thread_info structure, which is used by
the crash utility for determining the process cpu.
- Resolves: rbhz#405101
-
Fri Jan 18 2008 Dave Anderson <anderson@redhat.com> - 4.0-5.0.1
- Fix for initialization-time failure when analyzing a vmcore of
an i386-HVM guest that was taken when running on an x86_64 host
- Resolves: rbhz#288691
- Fix for initialization-time segmentation violation when analyzing
a vmcore in which the kernel has over-run its kernel stack,
corrupting the process thread_info structure, which is used by
the crash utility for determining the process cpu.
- Resolves: rbhz#405101
- Fix for "mod" command when analyzing ppc64 kernels with 64K pages.
- Resolves: rbhz#414881
-
Tue Aug 28 2007 Dave Anderson <anderson@redhat.com> - 4.0-4.6.1
- Fix for "bt" command segmentation violation when run against
an x86 xen-syms hypervisor.
- Resolves: rhbz#252198
-
Sat Jun 23 2007 Dave Anderson <anderson@redhat.com> - 4.0-4.3.1
- Fix for "dev -p" command for ppc64 machines with virtual devices
and for kernels that don't have the "pci_device" symbol.
- Resolves: rhbz#220929
- Fix for "crash: cannot resolve "init_task_union" errors due to
to "__per_cpu_start" and "__per_cpu_end" symbols changing from
type 'A' to type 'D'.
- Resolves: rhbz#221901
- Fix for segmentation fault when attempting to read a xen core dump
from a 6 GB guest.
- Resolves: rhbz#224535
- Fix for crash session initialization failure indicating "crash:
cannot read/find cr3 page" in xendumps where the cr3 register
value in the dumpfile header is overloaded to be able to use
page directory pages that are greater than 4GB.
- Resolves: rhbz#223454
- Support for determining the physical base address in FV relocatable
x86_64 xendump dumpfiles run as xen guests.
- Resolves: rhbz#233151
Create a new crash-devel package for extension modules, which installs
defs.h in /usr/include/crash.
- Resolves: rhbz#241045
Reasonable backtraces for x86_64.
- Resolves: rhbz#221355
-
Sat Dec 02 2006 Dave Anderson <anderson@redhat.com> - 4.0-3.14
- Fix for s390x live system analysis to recognize debuginfo vmlinux
file that contains an ASCII char adjacent to the Linux version
string.
- Resolves: rhbz#216973
-
Tue Nov 21 2006 Dave Anderson <anderson@redhat.com> - 4.0-3.12
- Fix for ia64 kdump vmcore backtraces when crash was generated
via INIT switch or due to an MCA exception.
- Resolves: rhbz#216037
-
Thu Nov 09 2006 Dave Anderson <anderson@redhat.com> - 4.0-3.11
- Revisited fix for BZ #213929; when crash is run in a small
terminal window, gdb does line-wrapping that breaks the fix
for x86_64 backtraces.
-
Sat Nov 04 2006 Dave Anderson <anderson@redhat.com> - 4.0-3.10
- Updated crash.patch to match upstream version 4.0-3.9, bumped
by 1 to differentiate from RHEL4-5 errata version.
- Fixes for x86_64 "bt" command for tasks that have transitioned
to the IRQ stack from the process stack via hardware interrupt
or call_softirq entry point, and to the NMI stack from the
process stack.
- Resolves: rhbz#213929
-
Sat Oct 14 2006 Dave Anderson <anderson@redhat.com> - 4.0-3.7
- Updated crash.patch to match upstream version 4.0-3.7.
- Resolves: rhbz#207296 rhbz#210471
-
Thu Sep 14 2006 Dave Anderson <anderson@redhat.com> - 4.0-3.3
- Updated crash.patch to match upstream version 4.0-3.3.
- Support for x86_64 relocatable kernels. BZ #204557
-
Tue Aug 08 2006 Dave Anderson <anderson@redhat.com> - 4.0-3.1
- Updated crash.patch to match upstream version 4.0-3.1.
- Added kdump reference to description.
- Added s390 and s390x to ExclusiveArch list. BZ #199125
- Removed LKCD v1 pt_regs references for s390/s390x build.
- Removed LKCD v2_v3 pt_regs references for for s390/s390x build.
-
Sat Jul 15 2006 Jesse Keating <jkeating@redhat.com> - 4.0-3
- rebuild
-
Tue May 16 2006 Dave Anderson <anderson@redhat.com> - 4.0-2.26.4
- Updated crash.patch such that <asm/page.h> is not #include'd
by s390_dump.c; IBM did not make the file s390[s] only; BZ #192719
-
Tue May 16 2006 Dave Anderson <anderson@redhat.com> - 4.0-2.26.3
- Updated crash.patch such that <asm/page.h> is not #include'd
by vas_crash.h; only ia64 build complained; BZ #191719
-
Tue May 16 2006 Dave Anderson <anderson@redhat.com> - 4.0-2.26.2
- Updated crash.patch such that <asm/segment.h> is not #include'd
by lkcd_x86_trace.c; also for BZ #191719
-
Tue May 16 2006 Dave Anderson <anderson@redhat.com> - 4.0-2.26.1
- Updated crash.patch to bring it up to 4.0-2.26, which should
address BZ #191719 - "crash fails to build in mock"
-
Wed Feb 08 2006 Jesse Keating <jkeating@redhat.com> - 4.0-2.18.1
- rebuilt for new gcc4.1 snapshot and glibc changes
-
Thu Jan 05 2006 Dave Anderson <anderson@redhat.com> 4.0-2.18
- Updated source package to crash-4.0.tar.gz, and crash.patch
to bring it up to 4.0-2.18.
-
Sat Dec 10 2005 Jesse Keating <jkeating@redhat.com>
- rebuilt
-
Fri Mar 04 2005 Dave Anderson <anderson@redhat.com> 3.10-13
- Compiler error- and warning-related fixes for gcc 4 build.
- Update to enhance x86 and x86_64 gdb disassembly output so as to
symbolically display call targets from kernel module text without
requiring module debuginfo data.
- Fix hole where an ia64 vmcore could be mistakenly accepted as a
usable dumpfile on an x86_64 machine, leading eventually to a
non-related error message.
-
Thu Mar 03 2005 Dave Anderson <anderson@redhat.com> 3.10-12
- rebuild (gcc 4)
-
Fri Feb 11 2005 Dave Anderson <anderson@redhat.com> 3.10-9
- Updated source package to crash-3.10.tar.gz, containing
IBM's final ppc64 processor support for RHEL4
- Fixes potential "bt -a" hang on dumpfile where netdump IPI interrupted
an x86 process while executing the instructions just after it had entered
the kernel for a syscall, but before calling the handler. BZ #139437
- Update to handle backtraces in dumpfiles generated on IA64 with the
INIT switch (functionality intro'd in RHEL3-U5 kernel). BZ #139429
- Fix for handling ia64 and x86_64 machines booted with maxcpus=1 on
an SMP kernel. BZ #139435
- Update to handle backtraces in dumpfiles generated on x86_64 from the
NMI exception stack (functionality intro'd in RHEL3-U5 kernel).
- "kmem -[sS]" beefed up to more accurately verify slab cache chains
and report errors found.
- Fix for ia64 INIT switch-generated backtrace handling when
init_handler_platform() is inlined into ia64_init_handler();
properly handles both RHEL3 and RHEL4 kernel patches.
BZ #138350
- Update to enhance ia64 gdb disassembly output so as to
symbolically display call targets from kernel module
text without requiring module debuginfo data.
-
Thu Jul 15 2004 Dave Anderson <anderson@redhat.com> 3.8-5
- bump release for fc3
-
Wed Jul 14 2004 Dave Anderson <anderson@redhat.com> 3.8-4
- Fix for gcc 3.4.x/gdb issue where vmlinux was mistakenly presumed non-debug
-
Sat Jun 26 2004 Dave Anderson <anderson@redhat.com> 3.8-3
- remove (harmless) error message during ia64 diskdump invocation when
an SMP system gets booted with maxcpus=1
- several 2.6 kernel specific updates
-
Fri Jun 18 2004 Dave Anderson <anderson@redhat.com> 3.8-2
- updated source package to crash-3.8.tar.gz
- diskdump support
- x86_64 processor support
-
Tue Sep 23 2003 Dave Anderson <anderson@redhat.com> 3.7-5
- make bt recovery code start fix-up only upon reaching first faulting frame
-
Sat Sep 20 2003 Dave Anderson <anderson@redhat.com> 3.7-4
- fix "bt -e" and bt recovery code to recognize new __KERNEL_CS and DS
-
Thu Sep 11 2003 Dave Anderson <anderson@redhat.com> 3.7-3
- patch to recognize per-cpu GDT changes that redefine __KERNEL_CS and DS
-
Thu Sep 11 2003 Dave Anderson <anderson@redhat.com> 3.7-2
- patches for netdump active_set determination and slab info gathering
-
Thu Aug 21 2003 Dave Anderson <anderson@redhat.com> 3.7-1
- updated source package to crash-3.7.tar.gz
-
Thu Jul 24 2003 Dave Anderson <anderson@redhat.com> 3.6-1
- removed Packager, Distribution, and Vendor tags
- updated source package to crash-3.6.tar.gz
-
Sat Jul 19 2003 Jay Fenlason <fenlason@redhat.com> 3.5-2
- remove ppc from arch list, since it doesn't work with ppc64 kernels
- remove alpha from the arch list since we don't build it any more
-
Sat Jul 19 2003 Matt Wilson <msw@redhat.com> 3.5-1
- use %defattr(-,root,root)
-
Wed Jul 16 2003 Jay Fenlason <fenlason@redhat.com>
- Updated spec file as first step in turning this into a real RPM for taroon.
- Wrote man page.