<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Oracle VM Bug Fix Advisory OVMBA-2010-0010<br>
<br>
The following updated rpms for Oracle VM 2.2 have been uploaded to the
Unbreakable Linux Network:<br>
<br>
i386:<br>
crash-4.1.2-4.0.2.el5.i386.rpm<br>
<br>
x86_64:<br>
<br>
<br>
SRPMS:<br>
<a class="moz-txt-link-freetext"
href="http://oss.oracle.com/oraclevm/server/2.2/SRPMS-updates/crash-4.1.2-4.0.2.el5.src.rpm">http://oss.oracle.com/oraclevm/server/2.2/SRPMS-updates/crash-4.1.2-4.0.2.el5.src.rpm</a><br>
<br>
<br>
Description of changes:<br>
<br>
[4.1.2-4.0.2.el5]<br>
- Fix for xen vmcore's > 4GB (Tina Yang) [orabug 9770239]<br>
<br>
[4.1.2-4.0.1.el5]<br>
- Updated the description in specfile to be product neutral<br>
- Added crash-oracle.patch<br>
<br>
[4.1.2-4.el5]<br>
- Fix for very large xendump core files whose ELF sections are located<br>
beyond a file offset of 4GB.<br>
- Resolves: rhbz#561767<br>
<br>
[4.1.2-3.el5]<br>
- Fix for the "bt" command on an ia64 "INIT" process that interrupted<br>
a task that was running in user space, but was unable to modify the<br>
original (interrupted) task's stack. Without the patch, the "INIT"<br>
task's backtrace would not display the task that was interrupted,<br>
and would display the error message "bt: unwind: failed to locate<br>
return link (ip=<user-virtual-address>)!". With the patch, the<br>
interrupted task information is displayed in the same manner as if<br>
the original stack had been modified.<br>
- Resolves: rhbz#553353<br>
<br>
[4.1.2-2.el5]<br>
- Fix for a 4.0-8.11 regression that introduced a bug in determining<br>
the number of cpus in ppc64 kernels when the cpu_possible_[map/mask]<br>
has more cpus than the cpu_online_[map/mask]. In that case, the<br>
kernel contains per-cpu runqueue data and "swapper" tasks for the<br>
extra cpus. Without the patch, on systems with a possible cpu count<br>
that is larger than its online cpu count:<br>
(1) the "sys" command will reflect the possible cpu count.<br>
(2) the "ps" command will show the existent-but-unused "swapper"<br>
tasks as active on the extra cpus.<br>
(3) the "set" command will allow the current context to be set to<br>
any of the existent-but-unused "swapper" tasks.<br>
(4) the "runq" command will display existent-but-unused runqueue<br>
data for the extra cpus.<br>
(5) the "bt" command on the existent-but-unused "swapper" tasks will<br>
indicate: "bt: cannot determine NT_PRSTATUS ELF note for active<br>
task: <task>" on dumpfiles, and "(active)" on live systems<br>
- Resolves: rhbz#550419<br>
<br>
[4.1.2-1.el5]<br>
- Re-based package to upstream version 4.1.2.<br>
- Resolves: rhbz#528184<br>
- If a kdump NMI issued to a non-crashing x86_64 cpu was received while<br>
running in schedule(), after having set the next task as "current" in<br>
the cpu's runqueue, but prior to changing the kernel stack to that of<br>
the next task, then a backtrace would fail to make the transition<br>
from the NMI exception stack back to the process stack, with the<br>
error message "bt: cannot transition from exception stack to current<br>
process stack". This patch will report inconsistencies found between<br>
a task marked as the current task in a cpu's runqueue, and the task<br>
found in the per-cpu x8664_pda "pcurrent" field. If it can be safely<br>
determined that the runqueue setting (used by default) is premature,<br>
then the crash utility's internal per-cpu active task will be changed<br>
to be the task indicated by the appropriate architecture specific
value.<br>
Also, a new "set -a <task>" option has been added to manually
set a task<br>
to be the "active" task on its cpu.<br>
- Resolves: rhbz#504952<br>
- Fix for a potential segmentation violation during invocation if a<br>
vmcore file, a System.map file, and a non-matching vmlinux file are<br>
used as command line arguments. The problem is that whenever a<br>
System.map file is used, it is presumed that the user knows what he<br>
is doing, and that the vmlinux file is not the same as the kernel<br>
that generated the vmcore; therefore the vmlinux/vmcore matching and<br>
verification routines are not performed. However, if the kernel data<br>
structures in the non-matching vmlinux vary widely enough from the<br>
kernel that generated the vmcore, all manners of bogus data may be<br>
read and consumed. The reported segmentation violation occurred when<br>
using a vmcore created from a "stock" Red Hat kernel with a vmlinux<br>
file from a Red Hat "debug" kernel, where the kernel data structures<br>
are significantly different. The patch adds a several new defensive<br>
mechanisms, and displays additional warning messages, when invalid or<br>
questionable data is read, and as a result the crash session will fail<br>
in a more reasonable manner.<br>
- Resolves: rhbz#508156<br>
- Fix for "bt" command when run against a Xen hypervisor, which showed<br>
a "cannot resolve stack trace" warning message if the cpu received its<br>
shutdown NMI while running in an interrupt handler.<br>
- Resolves: rhbz#510505<br>
- Support for dumpfile format of "virsh dump" of KVM kernels.<br>
- Resolves: rhbz#510519<br>
- Fix for initialization-time failure when running against ppc64 vmcores<br>
if the dump was collected when there were one or more cpus offline in<br>
the system at the time of the crash.<br>
- Resolves: rhbz#520506<br>
- Fix for the x86_64 "bt" command that may possibly start the backtrace<br>
of an active non-crashing task on its per-cpu IRQ stack instead of<br>
starting from the NMI exception stack, causing a faulty transition <br>
back to the process stack, the dumping of a bogus exception fame and<br>
the message "bt: WARNING: possibly bogus exception frame".<br>
- Resolves: rhbz#523512<br>
<br>
[4.0-8.9.1.el5]<br>
- Fix for running "foreach bt" on a live system, where a backtrace that<br>
is attempted on a task that no longer exists may cause a segmentation<br>
violation due to the use of stale/invalid kernel stack pointer.<br>
- Resolves: rhbz#504796<br>
<br>
[4.0-8.9.el5]<br>
- Re-based package to upstream version 4.0-8.9.<br>
- Resolves: rhbz#494028<br>
- Fix for nonsensical usage of the "set" command when running<br>
against the xen hypervisor binary. If entered alone on the<br>
command line, the command would cause a segmentation violation,<br>
because there is no concept of a "context" in the xen hypervisor.<br>
In addition, more reasonable error messages are displayed if<br>
"set", "set -c <cpu>", "set -p", or "set <address>" are<br>
attempted when running against a xen hypervisor.<br>
- Resolves: rhbz#462819<br>
- Fix for "irq -d" option when run on x86_64 xen kernels. Without the<br>
patch it would indicate: "irq: invalid structure size: gate_struct"<br>
and dump a stack trace leading to x86_64_display_idt_table(). Now it<br>
will indicate that the -d option is not applicable.<br>
- Resolves: rhbz#464116<br>
- Fixes for the "bt" command when running against the xen hypervisor<br>
binary. The "bt -o" option, and setting it to run by default with<br>
"bt -O", would fail with the vmlinux-specific error message "bt:<br>
invalid structure size: desc_struct" with a stack trace leading<br>
to read_idt_table(); with the patch it will display the generic<br>
error message "bt: -o option not supported or applicable on this<br>
architecture or kernel". The "bt -e" or "bt -E" will also display<br>
the same error message, as opposed to the command usage message.<br>
Lastly, the "bt -R" option would cause a segmentation violation;<br>
it has been fixed to work as it was designed.<br>
- Resolves: rhbz#464288<br>
- Fix for the "bt" command when run on a xen hypervisor in which the<br>
backtrace leads to either "process_softirqs" or "page_fault".<br>
Without the patch, the backtrace indicates: "bt: cannot resolve stack<br>
trace", and then the recovery code terminates the command with the<br>
nonsensical error message: "bt: invalid structure size: task_struct".<br>
- Resolves: rhbz#466724<br>
- Fix for "bt -a" command when running against the xen hypervisor where<br>
the number of physical cpus outnumber the MAX_VIRT_CPUS value for the<br>
processor type. Without the patch on such a system, "bt -a" would<br>
fail after displaying backtraces for the first 32 (MAX_VIRT_CPUS)<br>
pcpus with the the error message: "bt: invalid vcpu". The patch also<br>
corrects the "vcpus" command output to show the vcpus associated with<br>
pcpus 32 through 63, and the "doms" command output to show the second<br>
idle domain associated with pcpus 32 through 63.<br>
- Resolves: rhbz#471790<br>
- Fix for the "bt" command when run on a xen hypervisor in which the<br>
backtrace leads to either "process_softirqs" or "page_fault".<br>
Without the patch, the backtrace indicates: "bt: cannot resolve stack<br>
trace", and then the recovery code terminates the command with the<br>
nonsensical error message: "bt: invalid structure size: task_struct".<br>
- Resolves: rhbz#474712<br>
- Fix for "mod -[sS]" command if the target module object filename<br>
contains both underscore and dash characters. Without the patch<br>
the module load would fail with the error message: "mod: cannot<br>
[module". Examples are]<br>
the "aes_x86_64" module from the "aes-x86_64.ko" object file, and<br>
the "dm_region_hash" module from the "dm-region_hash.ko" object file.<br>
- Resolves: rhbz#480136<br>
- Changed the manner in which the "bt" command determines which PID 0<br>
swapper task was interrupted by an ia64 INIT or MCA exception.<br>
There is an existing ia64 INIT/MCA handler bug which incorrectly<br>
writes the pseudo task's command name in its comm[] name string<br>
such that the cpu number may not be part of the string. If that<br>
happens without this patch, the "bt" command fails to make the link<br>
back to the interrupted task, and displays the error message:<br>
"bt: unwind: failed to locate return link (ip=0x0)!"<br>
- Resolves: rhbz#487429<br>
- The starting backtrace location of active, non-crashing, xen dom0<br>
tasks are not available in kdump dumpfiles, nor is there anything<br>
that can be searched for in their respective stacks. Therefore, for<br>
those those tasks, the "bt" command will indicate: "bt: starting<br>
backtrace locations of the active (non-crashing) xen tasks cannot be<br>
determined: try -t or -T options". Without the patch, the backtrace<br>
would either be empty, or it would show an invalid backtrace starting<br>
at the last location where schedule() had been called. <br>
- Fix for potentially empty "bt -t" output, and for "bt -T" potentially<br>
dumping the text return addresses in the hard or soft IRQ stacks<br>
instead of the process stack. This could occur if the targeted task<br>
was the last task that used the hard or soft IRQ stack (x86 only).<br>
- Resolves: rhbz#495586<br>
<br>
[4.0-7.2.4]<br>
Fix for a "bt" command segmentation violation by correctly <br>
handling the transition from the IRQ stack back to the process <br>
stack running when running against a Xen kernel.<br>
- Resolves: rhbz#478904<br>
</tt><br>
<div class="moz-signature"><!-- This signature was generated by the MyDesktop Oracle Business Signature utility version 3.5.7 -->
</div>
</body>
</html>