The latest patch(es) : vm-hpux1131-5.1SP1RP3P10
|
---|
Release type: | P-patch |
Release date: | 2012-06-15 |
OS update support: | None |
Technote: | None |
Documentation: | None |
Popularity: | 1151 viewed downloaded |
Download size: | 341.81 MB |
Checksum: | 645386998 |
Dynamic Multi-Pathing 5.1SP1 On HP-UX 11i v3 (11.31)
Storage Foundation 5.1SP1 On HP-UX 11i v3 (11.31) Storage Foundation Cluster File System 5.1SP1 On HP-UX 11i v3 (11.31) Storage Foundation for Oracle RAC 5.1SP1 On HP-UX 11i v3 (11.31) Storage Foundation HA 5.1SP1 On HP-UX 11i v3 (11.31) |
|
2440015, 2477272, 2493635, 2497637, 2497796, 2507120, 2507124, 2508294, 2508418, 2511928, 2515137, 2517819, 2525333, 2528144, 2531983, 2531987, 2531993, 2552402, 2553391, 2568208, 2574840, 2583307, 2603605, 2676703
|
PHCO_42807
PHKL_42808 |
* * * READ ME * * * * * * Veritas Volume Manager 5.1 SP1 RP1 * * * * * * P-patch 1 * * * Patch Date: 2012-06-15 This document provides the following information: * PATCH NAME * PACKAGES AFFECTED BY THE PATCH * BASE PRODUCT VERSIONS FOR THE PATCH * OPERATING SYSTEMS SUPPORTED BY THE PATCH * INCIDENTS FIXED BY THE PATCH * INSTALLATION PRE-REQUISITES * INSTALLING THE PATCH * REMOVING THE PATCH PATCH NAME ---------- Veritas Volume Manager 5.1 SP1 RP1 P-patch 1 PACKAGES AFFECTED BY THE PATCH ------------------------------ VRTSvxvm VRTSvxvm BASE PRODUCT VERSIONS FOR THE PATCH ----------------------------------- * Veritas Storage Foundation for Oracle RAC 5.1 SP1 * Veritas Storage Foundation Cluster File System 5.1 SP1 * Veritas Storage Foundation 5.1 SP1 * Veritas Storage Foundation High Availability 5.1 SP1 * Veritas Dynamic Multi-Pathing 5.1 SP1 OPERATING SYSTEMS SUPPORTED BY THE PATCH ---------------------------------------- HP-UX 11i v3 (11.31) INCIDENTS FIXED BY THE PATCH ---------------------------- This patch fixes the following Symantec incidents: Patch ID: PHCO_42807 * 2440015 (Tracking ID: 2428170) SYMPTOM: I/O hangs when reading or writing to a volume after a total storage failure in CVM environments with Active-Passive arrays. DESCRIPTION: In the event of a storage failure, in active-passive environments, the CVM-DMP fail over protocol is initiated. This protocol is responsible for coordinating the fail-over of primary paths to secondary paths on all nodes in the cluster. In the event of a total storage failure, where both the primary paths and secondary paths fail, in some situations the protocol fails to cleanup some internal structures, leaving the devices quiesced. RESOLUTION: After a total storage failure all devices should be un-quiesced, allowing the I/Os to fail. The CVM-DMP protocol has been changed to cleanup devices, even if all paths to a device have been removed. * 2477272 (Tracking ID: 2169726) SYMPTOM: After import operation, the imported diskgroup contains combination of cloned and original disks. For example, after importing the diskgroup which has four disks, two of the disks from imported diskgroup are cloned disks and the other two are original disks. DESCRIPTION: For a particular diskgroup, if some of the original disks are not available at the time of diskgroup import operation and the corresponding cloned disks are present, then the diskgroup imported through vxdg import operation contains combination of cloned and original disks. Example - Diskgroup named dg1 with the disks disk1 and disk2 exists on some machine. Clones of disks named disk1_clone disk2_clone are also available. If disk2 goes offline and the import for dg1 is performed, then the resulting diskgroup will contain disks disk1 and disk2_clone. RESOLUTION: The diskgroup import operation will consider cloned disks only if no original disk is available. If any of the original disks exists at the time of import operation, then the import operation will be attempted using original disks only. * 2493635 (Tracking ID: 2419803) SYMPTOM: Secondary Site panics in VVR (Veritas Volume Replicator). Stack trace might look like: kmsg_sys_snd+0xa8() nmcom_send_tcp+0x800() nmcom_do_send+0x290() nmcom_throttle_send+0x178() nmcom_sender+0x350() thread_start+4() DESCRIPTION: While Secondary site is communicating with Primary site, if it encounters "EAGAIN" (try again) error, then it tries to send data on next connection. If all the session connections are not established by this time, it leads to panic as the connection is not initialized. RESOLUTION: Code changes have been made to check for a valid connection before sending data. * 2497637 (Tracking ID: 2489350) SYMPTOM: In a Storage Foundation environment running Symantec Oracle Disk Manager (ODM), Veritas File System (VxFS), Cluster volume Manager (CVM) and Veritas Volume Replicator (VVR), kernel memory is leaked under certain conditions. DESCRIPTION: In CVR (CVM + VVR), under certain conditions (for example when I/O throttling gets enabled or kernel messaging subsystem is overloaded), the I/O resources allocated before are freed and the I/Os are being restarted afresh. While freeing the I/O resources, VVR primary node doesn't free the kernel memory allocated for FS-VM private information data structure and causing the kernel memory leak of 32 bytes for each restarted I/O. RESOLUTION: Code changes are made in VVR to free the kernel memory allocated for FS-VM private information data structure before the I/O is restarted afresh. * 2497796 (Tracking ID: 2235382) SYMPTOM: IOs can hang in DMP driver when IOs are in progress while carrying out path failover. DESCRIPTION: While restoring any failed path to a non-A/A LUN, DMP driver is checking that whether any pending IOs are there on the same dmpnode. If any are present then DMP is marking the corresponding LUN with special flag so that path failover/failback can be triggered by the pending IOs. There is a window here and by chance if all the pending IOs return before marking the dmpnode, then any future IOs on the dmpnode get stuck in wait queues. RESOLUTION: Make sure that whenever the LUN is having pending IOs then only to set the flag on it so that failover can be triggered by pending IOs. * 2507120 (Tracking ID: 2438426) SYMPTOM: The following messages are displayed after vxconfigd is started. pp_claim_device: Could not get device number for /dev/rdsk/emcpower0 pp_claim_device: Could not get device number for /dev/rdsk/emcpower1 DESCRIPTION: Device Discovery Layer(DDL) has incorrectly marked a path under dmp device with EFI flag even though there is no corresponding Extensible Firmware Interface (EFI) device in /dev/[r]dsk/. As a result, Array Support Library (ASL) issues a stat command on non-existent EFI device and displays the above messages. RESOLUTION: Avoided marking EFI flag on Dynamic MultiPathing (DMP) paths which correspond to non-efi devices. * 2507124 (Tracking ID: 2484334) SYMPTOM: The system panic occurs with the following stack while collecting the DMP stats. dmp_stats_is_matching_group() dmp_group_stats() dmp_get_stats() gendmpioctl() dmpioctl() DESCRIPTION: Whenever new devices are added to the system, the stats table is adjusted to accomodate the new devices in the DMP. There exists a race between the stats collection thread and the thread which adjusts the stats table to accomodate the new devices. The race can result the stats collection thread to access the memory beyond the known size of the table causing the system panic. RESOLUTION: The stats collection code in the DMP is rectified to restrict the access to the known size of the stats table. * 2508294 (Tracking ID: 2419486) SYMPTOM: Data corruption is observed with single path when naming scheme is changed from enclodure based (EBN) to OS Native (OSN). DESCRIPTION: The Data corruption can occur in the following configuration, when the naming scheme is changed while applications are on-line. 1. The DMP device is configured with single path or the devices are controlled by Third party Multipathing Driver (Ex: MPXIO, MPIO etc.,) 2. The DMP device naming scheme is EBN (enclosure based naming) and persistence=yes 3. The naming scheme is changed to OSN using the following command # vxddladm set namingscheme=osn There is possibility of change in name of the VxVM device (DA record) while the naming scheme is changing. As a result of this the device attribute list is updated with new DMP device names. Due to a bug in the code which updates the attribute list, the VxVM device records are mapped to wrong DMP devices. Example: Following are the device names with EBN naming scheme. MAS-usp0_0 auto:cdsdisk hitachi_usp0_0 prod_SC32 online MAS-usp0_1 auto:cdsdisk hitachi_usp0_4 prod_SC32 online MAS-usp0_2 auto:cdsdisk hitachi_usp0_5 prod_SC32 online MAS-usp0_3 auto:cdsdisk hitachi_usp0_6 prod_SC32 online MAS-usp0_4 auto:cdsdisk hitachi_usp0_7 prod_SC32 online MAS-usp0_5 auto:none - - online invalid MAS-usp0_6 auto:cdsdisk hitachi_usp0_1 prod_SC32 online MAS-usp0_7 auto:cdsdisk hitachi_usp0_2 prod_SC32 online MAS-usp0_8 auto:cdsdisk hitachi_usp0_3 prod_SC32 online MAS-usp0_9 auto:none - - online invalid disk_0 auto:cdsdisk - - online disk_1 auto:none - - online invalid bash-3.00# vxddladm set namingscheme=osn The follwoing is after executing the above command. The MAS-usp0_9 is changed as MAS-usp0_6 and the following devices are changed accordingly. bash-3.00# vxdisk list DEVICE TYPE DISK GROUP STATUS MAS-usp0_0 auto:cdsdisk hitachi_usp0_0 prod_SC32 online MAS-usp0_1 auto:cdsdisk hitachi_usp0_4 prod_SC32 online MAS-usp0_2 auto:cdsdisk hitachi_usp0_5 prod_SC32 online MAS-usp0_3 auto:cdsdisk hitachi_usp0_6 prod_SC32 online MAS-usp0_4 auto:cdsdisk hitachi_usp0_7 prod_SC32 online MAS-usp0_5 auto:none - - online invalid MAS-usp0_6 auto:none - - online invalid MAS-usp0_7 auto:cdsdisk hitachi_usp0_1 prod_SC32 online MAS-usp0_8 auto:cdsdisk hitachi_usp0_2 prod_SC32 online MAS-usp0_9 auto:cdsdisk hitachi_usp0_3 prod_SC32 online c4t20000014C3D27C09d0s2 auto:none - - online invalid c4t20000014C3D26475d0s2 auto:cdsdisk - - online RESOLUTION: Code changes are made to update device attribute list correctly even if name of the VxVM device is changed while the naming scheme is changing. * 2508418 (Tracking ID: 2390431) SYMPTOM: In a Disaster Recovery environment, when DCM (Data Change Map) is active and during SRL(Storage Replicator Log)/DCM flush, the system panics due to missing parent on one of the DCM in an RVG (Replicated Volume Group). DESCRIPTION: The DCM flush happens during every log update and its frequency depends on the IO load. If the I/O load is high, the DCM flush happens very often and if there are more volumes in the RVG, the frequency is very high. Every DCM flush triggers the DCM flush on all the volumes in the RVG. If there are 50 volumes, in an RVG, then each DCM flush creates 50 children and is controlled by one parent SIO. Once all the 50 children are done, then the parent SIO releases itself for the next flush. Once the DCM flush of each child completes, it detaches itself from the parent by setting the parent field to NULL. It so happens that, if the 49th child is done and before it is detaching it from the parent, the 50th child completes and releases the parent_SIO for the next DCM flush. Before the 49th child detaches, the new DCM flush is started on the same 50th child. After the next flush is started, the 49th child of the previous flush detaches itself from the parent and since it is a static SIO, it indirectly resets the new flush parent field. Also, the lock is not obtained before modifing the sio state field in a few scenarios. RESOLUTION: Before reducing the children count, detach the parent first. This will make sure the new flush will not race with the previous flush. Protect the field with the required lock in all the scenarios. * 2511928 (Tracking ID: 2420386) SYMPTOM: Corrupted data is seen near the end of a sub-disk, on thin-reclaimable disks with either CDS EFI or sliced disk formats. DESCRIPTION: In environments with thin-reclaim disks running with either CDS-EFI disks or sliced disks, misaligned reclaims can be initiated. In some situations, when reclaiming a sub-disk, the reclaim does not take into account the correct public region start offset, which in rare instances can potentially result in reclaiming data before the sub-disk which is being reclaimed. RESOLUTION: The public offset is taken into account when initiating all reclaim operations. * 2515137 (Tracking ID: 2513101) SYMPTOM: When VxVM is upgraded from 4.1MP4RP2 to 5.1SP1RP1, the data on CDS disk gets corrupted. DESCRIPTION: When CDS disks are initialized with VxVM version 4.1MP4RP2, the no of cylinders are calculated based on the disk raw geometry. If the calculated no. of cylinders exceed Solaris VTOC limit (65535), because of unsigned integer overflow, truncated value of no of cylinders gets written in CDS label. After the VxVM is upgraded to 5.1SP1RP1, CDS label gets wrongly written in the public region leading to the data corruption. RESOLUTION: The code changes are made to suitably adjust the no. of tracks & heads so that the calculated no. of cylinders be within Solaris VTOC limit. * 2517819 (Tracking ID: 2530279) SYMPTOM: vxesd consumes 100% CPU, and hang is in following stack: vold_open () es_update_ddlconfig () do_get_ddl_config () start_ipc () main () DESCRIPTION: Due to inappropriate handling of thread control, race condition occurs inside the ESD code path. This race condition leads 100% CPU cycles and reaches to hang state. RESOLUTION: Done the proper way of handling to control thread to avoid the race condition in the code path. * 2525333 (Tracking ID: 2148851) SYMPTOM: "vxdisk resize" operation fails on a disk with VxVM cdsdisk/simple/sliced layout on Solaris/Linux platform with the following message: VxVM vxdisk ERROR V-5-1-8643 Device emc_clariion0_30: resize failed: New geometry makes partition unaligned DESCRIPTION: The new cylinder size selected during "vxdisk resize" operation is unaligned with the partitions that existed prior to the "vxdisk resize" operation. RESOLUTION: The algorithm to select the new geometry has been redesigned such that the new cylinder size is always aligned with the existing as well as new partitions. * 2528144 (Tracking ID: 2528133) SYMPTOM: vxprint -l command gives following error (along with the output), when multiple DGs have same DM_NAME VxVM vxdisk ERROR V-5-1-0 disk100 - Record in multiple disk groups DESCRIPTION: vxprint -l, internally takes one record(in this case DM_NAME) at a time and searches that record in all the DGs. If it finds the record in more than one DG, it marks the flag to DGL_MORE. This DGL_MORE flag checking was causing the error in case of vxprint -l. RESOLUTION: Since, it is a valid operation to create multiple DGs with same DM_NAME. The error checking is not required at all. The code change removes the flag checking logic from the function. * 2531983 (Tracking ID: 2483053) SYMPTOM: VVR Primary system consumes very high kernel heap memory and appear to be hung. DESCRIPTION: There is a race between REGION LOCK deletion thread which runs as part of SLAVE leave reconfiguration and the thread which process the DATA_DONE message coming from log client to logowner. Because of this race, the flags which stores the status information about the I/Os was not correctly updated. This used to cause a lot of SIOs being stuck in a queue consuming a large kernel heap. RESOLUTION: The code changes are made to take the proper locks while updating the SIOs' fields. * 2531987 (Tracking ID: 2510523) SYMPTOM: In CVM-VVR configuration, I/Os on "master" and "slave" nodes hang when "master" role is switched to the other node using "vxclustadm setmaster" command. DESCRIPTION: Under heavy I/O load, the I/Os are sometimes throttled in VVR, if number of outstanding I/Os on SRL reaches a certain limit (2048 I/Os). When "master" role is switched to the other node by using "vxclustadm setmaster" command, the throttled I/Os on original master are never restarted. This causes the I/O hang. RESOLUTION: Code changes are made in VVR to make sure the throttled I/Os are restarted before "master" switching is started. * 2531993 (Tracking ID: 2524936) SYMPTOM: Disk group is disabled after rescanning disks with "vxdctl enable" command. The error messages given below are seen in vxconfigd debug log output: <timestamp> VxVM vxconfigd ERROR V-5-1-12223 Error in claiming /dev/<disk>: The process file table is full. <timestamp> VxVM vxconfigd ERROR V-5-1-12223 Error in claiming /dev/<disk>: The process file table is full. ... <timestamp> VxVM vxconfigd ERROR V-5-1-12223 Error in claiming /dev/<disk>: The process file table is full. DESCRIPTION: When attachment of shared memory segment to the process address space fails, proper error handling of such case was missing in vxconfigd code, hence resulting in error in claiming disks and offlining configuration copies which in-turn results in disabling of disk group. RESOLUTION: Code changes are made to handle the failure case while creating shared memory segment. * 2552402 (Tracking ID: 2432006) SYMPTOM: System intermittently hangs during boot if disk is encapsulated. When this problem occurs, OS boot process stops after outputing this: "VxVM sysboot INFO V-5-2-3409 starting in boot mode..." DESCRIPTION: The boot process hung due to a dead lock between two threads, one VxVM transaction thread and another thread attempting a read on root volume issued by dhcpagent. Read I/O is deferred till transaction is finished but read count incremented earlier is not properly adjusted. RESOLUTION: Proper care is taken to decrement pending read count if read I/O is deferred. * 2553391 (Tracking ID: 2536667) SYMPTOM: In a CVM (Clustered Volume Manager) environment, the slave node panics with the following stack: e_block_thread() pse_block_thread() pse_sleep_thread() volsiowait() voldio() vol_voldio_read() volconfig_ioctl() volsioctl_real() volsioctl() vols_ioctl() rdevioctl() spec_ioctl() vnop_ioctl() vno_ioctl() DESCRIPTION: Panic happened due to accessing a stale DG pointer as DG got deleted before the I/O returned. It may happen on cluster configuration where commands generating private region i/os and "vxdg deport/delete" commands are executing simultaneously on two nodes of the cluster. RESOLUTION: Code changes are made to drain private region I/Os before deleting the DG. * 2568208 (Tracking ID: 2431448) SYMPTOM: Panic in vol_rv_add_wrswaitq() while processing duplicate message. Stack trace of panic vxio:vol_rv_add_wrswaitq vxio:vol_rv_msg_metadata_req vxio:vol_get_timespec_latest vxio:vol_mv_kmsg_request vxio:vol_kmsg_obj_request vxio:kmsg_gab_poll vxio:vol_kmsg_request_receive vxio:kmsg_gab_poll vxio:vol_kmsg_receiver DESCRIPTION: On receiving message from slave node, VVR looks for duplicate message before adding to per node queue. In case of duplicate message, VVR tries to copy some data structure from old message, if processing of old message is complete then we might end up accessing freed pointer which will cause panic. RESOLUTION: For duplicate message, copy from old message is not required since we discard duplicate message. Removing code of copying data structure resolved this panic. * 2574840 (Tracking ID: 2344186) SYMPTOM: In a master-slave configuration with FMR3/DCO volumes, reboot of a cluster node fails to join back the cluster again with following error messages in the console [..] Jul XX 18:44:09 vienna vxvm:vxconfigd: [ID 702911 daemon.error] V-5-1-11092 cleanup_client: (Volume recovery in progress) 230 Jul XX 18:44:09 vienna vxvm:vxconfigd: [ID 702911 daemon.error] V-5-1-11467 kernel_fail_join() : Reconfiguration interrupted: Reason is retry to add a node failed (13, 0) [..] DESCRIPTION: VxVM volumes with FMR3/DCO have inbuilt DRL mechanism to track the disk block of in-flight IOs in order to recover the data much quicker in case of a node crash. Thus, a joining node awaits the variable, responsible for recovery, to get unset to join the cluster. However, due to a bug in FMR3/DCO code, this variable was set forever, thus leading to node join failure. RESOLUTION: Modified the FMR3/DCO code to appropriately set and unset this recovery variable. * 2583307 (Tracking ID: 2185069) SYMPTOM: In a CVR setup, while the application I/Os are going on all nodes of the primary site, bringing down a slave node results in a panic on the master node and the following stack trace is displayed: volsiodone vol_subdisksio_done volkcontext_process voldiskiodone voldiskiodone_intr voldmp_iodone bio_endio gendmpiodone dmpiodone bio_endio req_bio_endio blk_update_request blk_update_bidi_request blk_end_bidi_request blk_end_request scsi_io_completion scsi_finish_command scsi_softirq_done blk_done_softirq __do_softirq call_softirq do_softirq irq_exit smp_call_function_single_interrupt call_function_single_interrupt DESCRIPTION: An internal data structure access is not serialized properly, resulting in corruption of that data structure. This triggers the panic. RESOLUTION: The code is modified to properly serialize access to the internal data structure so that its contents are not corrupted under any conditions. * 2603605 (Tracking ID: 2419948) SYMPTOM: Race between the SRL flush due to SRL overflow and the kernel logging code, leads to a panic. DESCRIPTION: Rlink is disconencted, the RLINK state is moved to HALT. Primary RVG SRL is overflowed since there is no replication and which initiated DCM logging. This change the STATE of rlink to DCM. (since rlink is already disconencted, this will keep the finale state as HALT. During the SRL overflow, if the rlink connection resoted, then it has many state changes before completing the connection. If the SRL overflow and klogging code, finishes inbetween the above state transistion, and if it not finding it in VOLRP_PHASE_HALT, then the system is initiating the panic. RESOLUTION: Consider the above state change as valid, and make sure the SRL overflow code dont always expect the HALT state. Take action for the other state or wait for the full state transistion to complete for the rlink connection. * 2676703 (Tracking ID: 2553729) SYMPTOM: The following is observed during 'Upgrade' of VxVM (Veritas Volume Manager): i) 'clone_disk' flag is seen on non-clone disks in STATUS field when 'vxdisk -e list' is executed after uprade to 5.1SP1 from lower versions of VxVM. Eg: DEVICE TYPE DISK GROUP STATUS emc0_0054 auto:cdsdisk emc0_0054 50MP3dg online clone_disk emc0_0055 auto:cdsdisk emc0_0055 50MP3dg online clone_disk ii) Disk groups (dg) whose versions are less than 140 do not get imported after upgrade to VxVM versions 5.0MP3RP5HF1 or 5.1SP1RP2. Eg: # vxdg -C import <dgname> VxVM vxdg ERROR V-5-1-10978 Disk group <dgname>: import failed: Disk group version doesn't support feature; see the vxdg upgrade command DESCRIPTION: While uprading VxVM i) After upgrade to 5.1SP1 or higher versions: If a dg which is created on lower versions is deported and imported back on 5.1SP1 after the upgrade, then "clone_disk" flags gets set on non-cloned disks because of the design change in UDID (unique disk identifier) of the disks. ii) After upgrade to 5.0MP3RP5HF1 or 5.1SP1RP2: Import of dg with versions less than 140 fails. RESOLUTION: Code changes are made to ensure that: i) clone_disk flag does not get set for non-clone disks after the upgrade. ii) Disk groups with versions less than 140 get imported after the upgrade. INSTALLING THE PATCH -------------------- $ swinstall -x autoreboot=true <patch id> Please do swverify after installing the patches in order to make sure that the patches are installed correctly using: $ swverify <patch id> REMOVING THE PATCH ------------------ To remove the patch, enter the following command: # swremove -x autoreboot=true <patch id> SPECIAL INSTRUCTIONS -------------------- NONE OTHERS ------ NONE |
Why Register?
Get notifications about ASLs/APMs, HCLs, patches, and high availability agents
As a registered user, you can create notifications to receive updates about NetBackup Future Platform and Feature Plans, NetBackup hot fixes/EEBs in released versions, Array Support Libraries (ASLs)/Array Policy Modules (APMs), hardware compatibility lists (HCLs), patches and high availability agents. In addition, you can create system-specific notifications customized to your environment.
Compare configurations
The Compare Configurations feature lets you compare different system scans by the data collector. When you sign in, you can choose a target system, compare reports run at different times, and easily see how the system's configuration has changed.
Save configurations
After logging in, you can retrieve past reports, share reports with colleagues, review notifications you received, and retain custom settings. Anonymous users cannot access these features.
Bulk uploader
As a registered user,you can upload multiple reports, using the Bulk Uploader.