README VERSION : 1.1 README CREATION DATE : 2012-09-25 PATCH-ID : 5.1.133.000 PATCH NAME : VRTSodm 5.1SP1RP3 BASE PACKAGE NAME : VRTSodm BASE PACKAGE VERSION : 5.1.000.000 SUPERSEDED PATCHES : 5.1.132.000 REQUIRED PATCHES : 5.1.000.000 INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : rhel5_x86_64,rhel6_x86_64,sles10_x86_64,sles11_x86_64 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : OTHER PATCH CRITICALITY : CRITICAL HAS KERNEL COMPONENT : YES ID : NONE REBOOT REQUIRED : YES PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer to Release Notes for install instructions PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer to Release Notes for uninstall instructions SPECIAL INSTALL INSTRUCTIONS: ----------------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- 2900971 (2900969) Kernel panics while running ODMQA tests. SUMMARY OF KNOWN ISSUES: ----------------------------------------- KNOWN ISSUES : -------------- FIXED INCIDENTS: ---------------- PATCH ID:5.1.133.000 * INCIDENT NO:2900971 TRACKING ID:2900969 SYMPTOM: Unable to access odm symbols, resulting into kernel panic, assert 'f:vx_dio_physio:2b,1.1' on CFS and LM respectively. DESCRIPTION: For inter module communication, communication is done via 'proc' interface by creating character special file 'vxodm' inside the '/proc/vximc'. But, in RHEL6.3, the default mount option is "nodev". So, we cannot open the '/proc/vximc/vxodm', which gives 'permission denied' error and causes difficulty in accessing odm symbols. If we make '/proc/vximc/vxodm' a regular file, then, we don't get this issue. RESOLUTION: Changed the type of '/proc/vximc/vxodm' file to regular file. PATCH ID:5.1.132.000 * INCIDENT NO:2125704 TRACKING ID:2125679 SYMPTOM:When "service -status-all" or "service vxvm-recover status" are executed, the duplicate instance of the Veritas Volume Manager(VxVM) daemons (vxattachd, vxcached, vxrelocd, vxvvrsecdgd and vxconfigbackupd) are invoked. DESCRIPTION: The startup scripts of VxVM for Linux are not Linux Standard Base (LSB) compliant. Hence, the execution of the following command results in starting up new instance. # vxvm-recover status RESOLUTION:The VxVM startup scripts are modified to be LSB compliant. * INCIDENT NO:2136161 TRACKING ID:2119531 SYMPTOM:DMP unable to discover all the NPIV(N-Port ID Virtualization) Fibre Channel SCSI controllers whereas OS did discover them. AIX- DESCRIPTION: In NPIV environment, the storage to the Virtual IO client is allocated directly through Virtual Fibre Channel Client adapters that are created in VIO client partition. The FC adapters that are present in a given machine have a location attribute associated with them which gives the actual physical location of the adapter. With NPIV, the location code depends directly on the adapter ID that was provided while creating the VFC client adapters. DMP uses this location attribute as the hardware pathname of the adapter keeping in mind that it will not change after reconfigs. DMP kernel uses this attribute as the controller-id and discovery is based on this. So the uniqueness is lost in the NPIV configuration where the privilege is given to the user in assigning adapter ID's. AIX- RESOLUTION:As this symptom is seen only in virtualization environment and with NPIV, the Device Discovery Layer during discovery will check whether the FC adapters are NPIV adapters and suffix it with the '_#' where # comes from fscsi#, thereby preserving the uniqueness. This fix will function irrespective of whether the location code is same or different. There was double free issue that was causing volume configuration daemon to dump core. This was also taken care. * INCIDENT NO:2138405 TRACKING ID:2052203 SYMPTOM:Immediately after vxconfigd is restarted on master, following error is seen "Slave not communicating" when commands (that result in transactions) are executed on master node. DESCRIPTION: All slaves need to re-establish connection with master vxconfigd after it is restarted. Before this, if any command is executed we get the above error. RESOLUTION:The fix is to retry the command (as this error is a retry error) with some delay. During this time slaves are expected to re-establish the connection with master vxconfigd. INCIDENTS FROM OLD PATCHES: --------------------------- NONE