* * * 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 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