[Oraclevm-errata] OVMBA-2010-0010 Oracle VM 2.2 crash bug fix update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Thu Jul 1 12:49:22 PDT 2010
Oracle VM Bug Fix Advisory OVMBA-2010-0010
The following updated rpms for Oracle VM 2.2 have been uploaded to the
Unbreakable Linux Network:
i386:
crash-4.1.2-4.0.2.el5.i386.rpm
x86_64:
SRPMS:
http://oss.oracle.com/oraclevm/server/2.2/SRPMS-updates/crash-4.1.2-4.0.2.el5.src.rpm
Description of changes:
[4.1.2-4.0.2.el5]
- Fix for xen vmcore's > 4GB (Tina Yang) [orabug 9770239]
[4.1.2-4.0.1.el5]
- Updated the description in specfile to be product neutral
- Added crash-oracle.patch
[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
[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
[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
[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
[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
[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
[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
[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/oraclevm-errata/attachments/20100701/563f714c/attachment.html
More information about the Oraclevm-errata
mailing list