* * * READ ME * * *
 * * * Veritas Group Membership and Atomic Broadcast 5.1 SP1 RP2 * * *
                         * * * P-patch 1 * * *
                         Patch Date: 2017-10-17


This document provides the following information:

   * PATCH NAME
   * OPERATING SYSTEMS SUPPORTED BY THE PATCH
   * PACKAGES AFFECTED BY THE PATCH
   * BASE PRODUCT VERSIONS FOR THE PATCH
   * SUMMARY OF INCIDENTS FIXED BY THE PATCH
   * DETAILS OF INCIDENTS FIXED BY THE PATCH
   * INSTALLATION PRE-REQUISITES
   * INSTALLING THE PATCH
   * REMOVING THE PATCH


PATCH NAME
----------
Veritas Group Membership and Atomic Broadcast 5.1 SP1 RP2 P-patch 1


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
HP-UX 11i v3 (11.31)


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSgab


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Veritas Cluster Server 5.1 SP1
   * Veritas Storage Foundation Cluster File System 5.1 SP1
   * Veritas Storage Foundation for Oracle RAC 5.1 SP1
   * Veritas Storage Foundation HA 5.1 SP1


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: PHNE_44626
* 3832381 (3767366) The VxFS read-ahead feature may not work if the read request is greater than 
the read-ahead request.
Patch ID: PHNE_43152
* 2292291 (2292294) pfiles, lsof, procfiles, or truss commands hang in the gablogd daemon.
* 2858122 (2831283) System got panic on GAB with below: panic string: BAD TRAP: type=31 rp=2a10d4cf530 addr=28 mmu_fsr=0 occurred in module "gab" due to a NULL pointer dereference


DETAILS OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
This patch fixes the following incidents:

Patch ID: PHNE_44626

* 3832381 (Tracking ID: 3767366)

SYMPTOM:
Using the sendfile(2) function to transfer a big file takes long as compared 
with the same transfer via the send(2) function. The sequential file access via 
the sendfile(2) function generates a lot of synchronous I/Os suggesting that 
VxFS read-ahead is not fully utilized.

DESCRIPTION:
When the page size is greater than 4 KB, VOP_GETPAGE may return more data than 
requested which breaks the read-ahead detection.

RESOLUTION:
The code is modified to update the read-ahead parameters considering the 
possibility that more data can be returned via VOP_GETPAGE, so as to continue 
doing the read-ahead for the sequential read.

Patch ID: PHNE_43152

* 2292291 (Tracking ID: 2292294)

SYMPTOM:
When you run tracing commands like pfiles, lsof, procfiles, or truss on the 
gablogd daemon, the command hangs.

DESCRIPTION:
When you run tracing commands like pfiles, lsof, procfiles, or truss on the 
gablogd daemon, a signal is issued to gablogd. This signal is blocked because it 
has called gab ioctl and is waiting for events with the cv_wait() call, which 
is not interruptible. As a result, the tracing command hangs.

RESOLUTION:
When gablogd calls gab ioctl, within ioctl, gab calls interruptible wait 
cv_wait_sig() for mutex conditional variable in ioctl. This call does not block 
signals on the process which calls gab ioctl.

* 2858122 (Tracking ID: 2831283)

SYMPTOM:
Unconfiguring GAB immediately after a network failure may cause the
system to panic. On a system with Solaris operating system you may see the
following error message: "BAD TRAP: type=31 rp=2a10d4cf530 addr=28mmu_fsr=0
occurred in module "gab" due to a NULL pointer dereference". On other operating
systems, you can find "NULL pointer dereference" as part of the error message.

DESCRIPTION:
In the event of a network issue in a cluster, GAB needs to close
all of its ports that are accessible to user-space and kernel-space clients. The
order in which the ports close is not defined. This undefined order means that
there is no check to ensure that the last port to be closed is the GAB's
internal port. 

So, there is a possibility that the GAB's internal port may close first. And the
last port to be closed is another port that may be left open for a transient
period.  During this period, if you try to unconfigure GAB, the unconfigure
program assumes that GAB's internal port is open instead of the other port and
LLT is shut down.  The other port remains open. Later, whenever GAB tries to
access LLT interfaces on behalf of the port that is open the system panics.

RESOLUTION:
Symantec has added an additional check in the unconfigure program to
verify that last port to be closed is the GAB's internal port. If the last port
is any other port, the program returns an error.



INSTALLING THE PATCH
--------------------
Perform the following steps on all the nodes of the cluster:

1) Bring down the VCS stack with the help of corresponding init scripts of the various modules.

2) Unconfigure GAB and LLT modules with:
   # gabconfig -U
   # lltconfig -Uo

3) Unload GAB and LLT modules with:
   # kcmodule gab=unused
   # kcmodule llt=unused

4) Apply the patch with:
   # swinstall -x autoreboot=true -s <patch_directory>    PHNE_44626

5) Start the LLT and GAB modules with the help of init scripts:
   # /sbin/init.d/llt start
   # /sbin/init.d/gab start

6) Start rest of the VCS stack with the help of corresponding init scripts.


REMOVING THE PATCH
------------------
Perform the following steps on all the nodes of the cluster:

1) Bring down the VCS stack with the help of corresponding init scripts of the various modules.

2) Unconfigure GAB and LLT modules with:
   # gabconfig -U
   # lltconfig -Uo

3) Unload GAB and LLT modules with:
   # kcmodule gab=unused
   # kcmodule llt=unused

4) Remove the patch with:
   # swremove -x autoreboot=true PHNE_44626

5) Start the LLT and GAB modules with the help of init scripts:
   # /sbin/init.d/llt start
   # /sbin/init.d/gab start

6) Start rest of the VCS stack with the help of corresponding init scripts.


SPECIAL INSTRUCTIONS
--------------------
NONE


OTHERS
------
NONE