
PROBLEM: (90026) (PATCH ID: TCR520-015)
********
Enablers for Huron Packaged Database Solution


PROBLEM: (90156) (PATCH ID: TCR520-058)
********
This patch kit includes a VM fix to a problem that can be exhibited by
getting a "panic: RDG unwire".  This RDG change is required to match the
VM change.


PROBLEM: (90646) (PATCH ID: TCR520-087)
********
The symptom of this problem is that Oracle 9i can hang when a cluster member
is taken down.  No specific error messages are generated.


PROBLEM: (90661, 90855, 91187, 91513) (PATCH ID: TCR520-105)
********
PROBLEM:
Executing the /usr/sbin/rdginit program multiple times can lead to the
second and subsequent executions hanging and generate "retrying sobind"
messages on the console.  This patch eliminates the problem and allows
/usr/sbin/rdginit to be executed an unlimited number of times.
PROBLEM:
A Kernel Memory Fault can be hit in the rdg_rm_do_snd routine when using
multiple independent memory channel rails.  This patch fixes the problem.

PROBLEM:
A "Simple Lock Owned" panic can be hit in RDG no matter which interconnect
type it is using, but is mostly seen when using the LAN interconnect.
This panic's stack trace will show rdg_proc_exit calling rdg_unwire_iodesc
calling vm_map_pageable.  This patch fixes the problem.


PROBLEM: (93029) (PATCH ID: TCR520-141)
********
Oracle customers could get an error when the database starts and
initializes the use of RDG.  The symptom of this problem is an ORA-27300
error code and 'skgxpcini' and 'RdgInit' being present in the error text
message.


PROBLEM: (92814) (PATCH ID: TCR520-150)
********
Under saturation conditions, a lock problem can result in user processes
hanging in an uninterruptable state.  The main symptom is that the user
processes will make no progress and will include either RDG_READ_LOCK
or RDG_WRITE_LOCK on the stack.


PROBLEM: (90662) (PATCH ID: TCR520-125)
********
This patch resolves an RDG problem whereby the system can get an
"mcs_unlock: current lock not found" panic if an application calls
RdgShutdown.  Customers running Oracle 9i must install this patch.


PROBLEM: (94759) (PATCH ID: TCR520-205)
********
Stress testing uncovered a problem in one of the RDG
kernel threads (rdg_snd_thread) whereby an instance of
this thread can starve other timeshare threads even if
it attempts to yields the processor on which it is running.
This problem can occur if the cluster member is a
uniprocessor and there is very heavy RDG traffic.  The
manifestation occurring during stress testing was that
networking services ceased operating.  However, any thread
running at a priority worse than BASEPRI_USER - 2 (42)
can be starved.


PROBLEM: (93325, 93329) (PATCH ID: TCR520-160)
********
The symptom of the first fix addressed by this patch is that one or more
user processes will be stuck in the "U" state (as shown by the ps command)
and an analysis of a dump shows that a thread is in the rdg_ctx_rcvq_cleanup
routine.
The symptom of the second fix addressed by this patch is a kernel memory
fault whose stack shows the rdg_rm_do_snd routine calling _OtsMove.


PROBLEM: (93754, 93755) (PATCH ID: TCR520-189)
********
Stress testing generated ICS panics caused by a kernel RDG thread
starving the netisr thread.  This patch fixes the problem by inserting
a preemption point in the code path executed by the RDG context receive
scan thread. (QAR 93754)
The RDG sent/received byte counters do not distinguish between remote
and/or loopback modes and consequently can provide misleading values
for evaluating actual load over an interconnect.  This patch adds
transport-specific sysconfig counters to remove this ambiguity.
(QAR 93755)


PROBLEM: (95501, DSATF0C90) (PATCH ID: TCR520-264)
********
This patch fixes problem seen in the TruCluster RDG component.  The problems
seen were as follows:
A system panic with either "rdg: unwiring" or "vl_unwire: page is not wired"
as the panic string.  The problem was seen primarily on systems that were 
heavily loaded and a timing window was hit that caused rdg to panic because it
was attempting to unwire a page that was already unwired.  Depending on timing,
the panic was also seen within the vm layer, but always the "rdg_unwire_iodesc"
was found on the stack.

A system panic with the string "KMF from _otsmove".  This problem was seen if 
someone incorrectly entered the rdg sysconfig value for "msg_size".  The problem
was seen when someone entered "32786" instead of "32768" as the value.



