README VERSION : 1.1 README CREATION DATE : 2013-09-30 PATCH-ID : PHNE_43529 PATCH NAME : VRTSllt 5.1.103.000 BASE PACKAGE NAME : VRTSllt BASE PACKAGE VERSION : 5.1.100.000 SUPERSEDED PATCHES : NONE REQUIRED PATCHES : NONE INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : hpux1131 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : PERFORMANCE PATCH CRITICALITY : CRITICAL HAS KERNEL COMPONENT : YES ID : NONE REBOOT REQUIRED : NO REQUIRE APPLICATION DOWNTIME : Yes PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer to Release Notes for install instructions PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer to Release Notes for uninstall instructions SPECIAL INSTRUCTIONS: --------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- PATCH ID:PHNE_43529 3154252 (3106493) If for some reason, kernel components of the Veritas Cluster Server (VCS) software stack are stopped and restarted in quick succession, then during a restart, the cluster communication may fail. 3228018 (2405387) When the Low Latency Transit (LLT) module starts up, the lltconfig(1M) command may fail to detect a duplicate cluster ID, and the Group Membership and Atomic Broadcast (GAB) module preventively panics the cluster. 3228021 (2434732) The Low Latency Transport (LLT): lltconfig reports its own cluster node as part of duplicate cluster. 3228036 (2251045) You may experience excessive CPU usage in the lltd process of the Low Latency Transport (LLT) module. SUMMARY OF KNOWN ISSUES: ----------------------------------------- NONE KNOWN ISSUES : -------------- NONE FIXED INCIDENTS: ---------------- PATCH ID:PHNE_43529 * INCIDENT NO:3154252 TRACKING ID:3106493 SYMPTOM: If for some reason, kernel components of the Veritas Cluster Server (VCS) software stack are stopped and restarted in quick succession, then during a restart, the cluster communication may fail. DESCRIPTION: The above behavior occurs when VCS kernel components stop one by one, and the Low Latency Transport (LLT) module starts closing its communication ports. If some protocol packets are lost during this process, LLT is expected to retransmit the packets, and bring the port-close state to completion. If LLT fails to do so, the port enters an inconsistent state, and any subsequent port-open operation fails. Therefore, when VCS kernel components such as the Group Atomic Membership Broadcast (GAB) module try to restart, cluster communication fails. This is an internal error that may occur in various scenarios. In all such cases, it may not be directly related to any of your actions. RESOLUTION: The LLT code has been modified to ensure that LLT always retransmits protocol packets that are lost in the network. * INCIDENT NO:3228018 TRACKING ID:2405387 SYMPTOM: When the Low Latency Transit (LLT) module starts up, the lltconfig(1M) command may fail to detect a duplicate cluster ID, and the Group Membership and Atomic Broadcast (GAB) module may preventively trigger panic in the cluster. DESCRIPTION: When LLT starts up, it tries to determine whether the cluster ID that the user specified, is already in use by another running cluster. If the lltconfig(1M) command fails to detect the duplicate cluster ID, GAB detects it. To prevent data corruption, GAB preventively triggers panics the cluster. RESOLUTION: The LLT code has been modified to ensure that duplicate cluster IDs are detected. * INCIDENT NO:3228021 TRACKING ID:2434732 SYMPTOM: When the Low Latency Transport (LLT) module starts, the lltconfig(1M) command fails and an error message, such as the following message appears: ----------------- Starting LLT... LLT lltconfig ERROR V-14-2-15245 cluster id 345 is already being used by nid 0 and has the address - 00:03:BA:CB:F6:D2 LLT lltconfig ERROR V-14-2-15664 LLT could not configure any link ---------------- Where the node with nid 0 is part of the same cluster. DESCRIPTION: When a user runs the lltconfig(1M) command in a cluster, the underlying code tries to determine if the cluster ID that the user specified, is already in use by another running cluster. If Low Latency Transit (LLT) module detects the duplicate cluster ID, the command fails, and prevents panic in the future. However, in the present case, the code incorrectly detects a peer node to be part of a duplicate cluster. This is due to the unexpected behavior of certain NIC drivers that add a few extra bytes at the end of every packet. The lltconfig(1M) command fails to resolve these extra bytes, and incorrectly displays the error message. RESOLUTION: The implementation of the lltconfig(1M) command is modified to truncate the extra bytes that are received along with LLT packets. * INCIDENT NO:3228036 TRACKING ID:2251045 SYMPTOM: You may experience excessive CPU usage in the lltd process of the Low Latency Transport (LLT) module. DESCRIPTION: During packet transmission, LLT on a receiving node, receives packets in the interrupt context, and queues them in separate queues for every port. During a heavy packet traffic, more than one thread may attempt to serve a single port. When various threads repeatedly attempt to serve a port, which another thread has already served leads to high CPU consumption. RESOLUTION: The LLT code is modified to prevent LLT from invoking multiple lltd threads for a given port. INCIDENTS FROM OLD PATCHES: --------------------------- NONE