5.0MP1CP1 VRTSvxfen
The latest patch(es) : sfha-rhel4_x86_64-5.0MP4  5.0 MP2a 

 Basic information
Release type: Rolling Patch
Release date: 2008-06-26
OS update support: None
Technote: 305324
Documentation: None
Popularity: 621 viewed    11 downloaded
Download size: 597.4 KB
Checksum: 3868688447

 Applies to one or more of the following products:
Cluster Server 5.0 MP1 On RHEL4 x86-64
Storage Foundation Cluster File System 5.0 MP1 On RHEL4 x86-64
Storage Foundation for DB2 5.0 MP1 On RHEL4 x86-64
Storage Foundation for Oracle 5.0 MP1 On RHEL4 x86-64
Storage Foundation for Oracle RAC 5.0 MP1 On RHEL4 x86-64
Storage Foundation HA 5.0 MP1 On RHEL4 x86-64

 Obsolete patches, incompatibilities, superseded patches, or other requirements:

This patch is obsolete. It is superseded by: Release date
sfha-rhel4_x86_64-5.0MP4 2010-04-11
5.0 MP2a 2007-07-05

 Fixes the following incidents:
1051193, 1057418, 896781

 Patch ID:

Readme file
NAME:                           5.0MP1CP1

DATE:                           2007-August-17

VCS RELEASE:                    5.0MP1

LINUX RELEASE:                  RHEL 4 U4



The following is a brief description of the bugs fixed in this patch.

Incident Number: 1051193
Abstract: vxfen unconfigure uses wrong key to preempt/abort from now faulted paths.
Brief Description:
When the fencing driver is stopped, it attempts to preempt/abort its own keys
registered with the coordinator disks. However, this key may be incorrect.
In some setups, this may lead to preempting other nodes keys leading to
the panic of all nodes in the cluster.
Incident Number: 896781
Abstract:  system panics intermitently after disabling array side switch port
Brief Description:
This bug only manifests if the fencing driver is configured to use DMP paths
 to coordinator disks. Before we do a preempt and abort, we do dummy
IOs to the coordinator disks to ensure that keys are correctly failed over
if the paths have failed over before this event. In this operation, there was
a bug dur to which the driver could sleep in an interrupt. If this happens,
the stack trace is as follows:

Call Trace:
[c00000000ffef680] [c00000000005bd98] .__might_sleep+0xcc/0xec (unreliable)
[c00000000ffef720] [d000000000b7e5ec] .vxfen_add_deblog+0x68/0x130 [vxfen]
[c00000000ffef7b0] [d000000000b95e4c] .vxfen_dummy_bio_write_complete+0x90/0x118
[c00000000ffef860] [c0000000000c7b48] .bio_endio+0xc0/0xe0
[c00000000ffef8f0] [d0000000007281c4] .gendmpiodone+0x1c8/0x228 [vxdmp]
[c00000000ffef9a0] [d000000000728ea4] .dmpiodone+0xec/0x120 [vxdmp]
[c00000000ffefa50] [c0000000000c7b48] .bio_endio+0xc0/0xe0
[c00000000ffefae0] [c0000000001e4638] .__end_that_request_first+0x12c/0x26c
[c00000000ffefba0] [d00000000007a488] .scsi_end_request+0x44/0x130 [scsi_mod]
[c00000000ffefc40] [d00000000007a97c] .scsi_io_completion+0x224/0x44c [scsi_mod]
[c00000000ffefd10] [d00000000003c214] .sd_rw_intr+0x2a8/0x2e0 [sd_mod]
[c00000000ffefdc0] [d000000000074318] .scsi_finish_command+0x10c/0x130 [scsi_mod]
[c00000000ffefe50] [d000000000074190] .scsi_softirq+0x140/0x168 [scsi_mod]
[c00000000ffefef0] [c000000000066084] .__do_softirq+0xa0/0x17c
[c00000000ffeff90] [c000000000018580] .call_do_softirq+0x14/0x24
[c00000000250f9e0] [c0000000000144a8] .do_softirq+0x74/0x9c
[c00000000250fa70] [c000000000013e64] .do_IRQ+0xe8/0x100
[c00000000250faf0] [c00000000000ae34] HardwareInterrupt_entry+0x8/0x54


Incident Number: 1057418
Abstract: more page 83 changes since PillarData Array's serial number
                   is implemented in an offset that is different from HDS and

In 5.0MP1 release, I/O fencing can not retrieve the serial number of luns from an array manufactured by PillarData.

552664454       625700  VRTSvxfen-


The patch needs to be installed after installing
Veritas Cluster Server 5.0MP1.

*** Steps to be run on any system in the cluster:

1. Stop VCS and CVM on all nodes. CVM is usually under VCS control and
   so will automatically come down when VCS is stopped using the following
   command on any node in the cluster:

        "hastop -all"

*** Steps to be run on every system in the cluster:

2. Log on as superuser on the system where the point patch is to be installed.

3. Stop VxFEN module using the following command:

        "/etc/init.d/vxfen stop"

4. Upgrade VRTSvxfen package using the following command:
        "rpm -Uvh VRTSvxfen-"

   Where VRTSvxfen- is the package rpm provided in the point patch

5. Bring up VxFEN by using the following command:

        "/etc/init.d/vxfen start"

6. Bring up VCS on all the nodes


Read and accept Terms of Service