FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 10-29-2010, 07:50 PM
Dave Anderson
 
Default crash version 5.0.9 is available

changelog:

- Make the symbol_search_next() function externally available to
extension modules, as requested for the "pykdump" extension module.
(anderson@redhat.com)

- Fix for the "log" command to recognize that the "log_end" symbol
was changed from an unsigned long to an unsigned int in 2.6.25 and
later kernels.
(anderson@redhat.com)

- Fix to determine the size and location of the x86_64 interrupt stack
on kernels that are not configured CONFIG_SMP. Without the patch,
runtime commands that use the embedded gdb module may fail with the
error message "<segmentation violation in gdb>".
(anderson@redhat.com)

- Suppress the "crash -d1" initialization-time message that indicates
"WARNING: Because this kernel was compiled with gcc version <x.x.x>,
certain commands or command options may fail unless crash is invoked
with the --readnow command line option" to only be displayed with
kernels compiled with gcc versions between 3.4.0 and 4.0.0.
(anderson@redhat.com)

- Fix for the "bt" command on 2.6.33 and later x86_64 kernels, which
contain debuginfo data for "struct user_regs_struct", and where the
the dumpfile is a kdump ELF vmcore. Without the patch, the backtrace
for the panic task uses the registers found in the ELF header's
NT_PRSTATUS note as starting hooks, which causes the backtrace to be
essentially truncated, leaving out the exception frame, the exception
handler's frame, and so on, down to the kdump operation. The patch
will only use the ELF header's registers if better starting hooks
cannot be determined.
(anderson@redhat.com)

- Fix for handling KVM dumpfiles that contain "devices" that are not
explicitly supported. The patch skips over the unsupported/unused
device segment in the dumpfile, and searches for the next "known"
device contained in the supported device table. Without the patch,
the crash session fails during initialization with the error message
"crash: <dumpfile>: initialization failed".
(anderson@redhat.com)

- When handcrafting the backtrace starting point for the "bt" command
by using the -S option, and the starting stack address is not in
the task's process stack or in a legitimate non-process stack
address, such as a hard or soft IRQ stack address, or an x86_64
exception stack address, a message gets displayed that indicates
"non-process stack address for this task". Without the patch, the
backtrace is still attempted, which may result in a segmentation
violation, so this behavior has been changed such that the "bt"
command will fail immediately.
(anderson@redhat.com)

- Modified the help page for the "help" command to also show the
various crash-internal debug options available.
(anderson@redhat.com)

- Fix for the x86_64 "bt" command to more correctly find the starting
backtrace RIP and RSP hooks in KVM dumpfiles. Without the patch,
backtraces that should start in the interrupt or exception stacks
were not being detected correctly.
(anderson@redhat.com)

- Save the per-cpu register contents stored in the "cpu" devices of
x86_64 KVM dumpfiles, and use their contents for x86_64 backtrace RSP
and RIP hooks in the case of KVM "live dumps" where the guest system
was not in a crashed state when the "virsh dump" operation was done
on the KVM host. If an active task was running in user space when
a live dump was taken, that will be indicated by the "bt" output,
along with the user-space register contents. The x86_64 register set
saved for each cpu may be displayed with the "help -[D|n]" command.
(hutao@cn.fujitsu.com, anderson@redhat.com)

- Fix for the cpu count determination in crashed x86 KVM dumpfiles,
where the non-crashing cpus are marked offline in the kernel's
cpu_online_mask by smp_stop_cpu(). Depending upon the cpu number
of the crashing task, the cpu count may be set to a value that is
less than the number of present cpus.
(anderson@redhat.com)

- Fix for a premature failure of the "kmem -i" command with kernels
that are not configured with CONFIG_SWAP.
(per.xx.fransson@stericsson.com)

- Fix for the x86 "bt" command on 2.6.31 and later kernels when the
crash was generated by an "echo c > /proc/sysrq-trigger". Without
the patch, the backtrace does not display the exception frame from
the forced oops. This is not applicable to older kernels where
crash_kexec() is called directly from sysrq_handle_crash(), or if
an actual alt-sysrq-c keystroke sequence is entered.
(anderson@redhat.com)

- Fix for the x86 "bt" command to correctly find the starting backtrace
EIP and ESP hooks for the active tasks in KVM dumpfiles where the
kernel had crashed.
(anderson@redhat.com)

- Fix to utilize the correct "cpu" device format in x86 KVM dumpfiles
Without the patch, the x86 registers were read in a 32-bit format,
which is only true if the host machine was running a 32-bit kernel.
With the patch, the format defaults to the 64-bit format, and is
switched to the 32-bit format if it can be determined that the host
machine was running a 32-bit kernel.
(hutao@cn.fujitsu.com, anderson@redhat.com)

- Save the per-cpu register contents stored in the "cpu" devices of
x86 KVM dumpfiles, and use their contents for x86 backtrace ESP and
EIP hooks in the case of KVM "live dumps", i.e., where the guest
system was not in a crashed state when the "virsh dump" operation
was done on the KVM host. If an active task was running in user
space when a live dump was taken, that will be indicated by the
"bt" output, along with the user-space register contents. The saved
x86 register set for each cpu may also be displayed with the
"help -[D|n]" command.
(hutao@cn.fujitsu.com, anderson@redhat.com)

- Update for the KVM-only "map" command to also store the register sets
read from the the KVM dumpfile's "cpu" devices in addition to the
mapfile data when it is written to an external mapfile, or appended
to the dumpfile, so that subsequent sessions will not require the
initial scan of the KVM dumpfile.
(anderson@redhat.com)

- Fix the KVM-only "map" command to prevent its use when the session
is not being run against a KVM dumpfile, and to reject filename
arguments to the -a option or without the -f option.
(anderson@redhat.com)

Download from: http://people.redhat.com/anderson

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 06:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org