Document fins/I0860-1
FIN #: I0860-1
SYNOPSIS: RAID Manager 6.22.1 with A1000/A3x00/A3500FC arrays needs a new patch
revision for Solaris 9
DATE: Nov/04/02
KEYWORDS: RAID Manager 6.22.1 with A1000/A3x00/A3500FC arrays needs a new patch
revision for Solaris 9
---------------------------------------------------------------------
- Sun Proprietary/Confidential: Internal Use Only -
---------------------------------------------------------------------
FIELD INFORMATION NOTICE
(For Authorized Distribution by SunService)
SYNOPSIS: RAID Manager 6.22.1 with A1000/A3x00/A3500FC arrays needs
a new patch revision for Solaris 9.
SunAlert: No
TOP FIN/FCO REPORT: Yes
PRODUCT_REFERENCE: Raid Manager 6 with Solaris 9
PRODUCT CATEGORY: Storage / SW Admin
PRODUCTS AFFECTED:
Systems Affected:
-----------------
Mkt_ID Platform Model Description Serial Number
------ -------- ----- ----------- -------------
- ANYSYS - System Platform Independent -
X-Options Affected:
-------------------
Mkt_ID Platform Model Description Serial Number
------ -------- ----- ----------- -------------
- A1000 - A1000 Storage Array -
- A3000 - A3000 Storage Array -
- A3500 - A3500 Storage Array -
- A3500FC - A3500FC Storage Array -
PART NUMBERS AFFECTED:
Part Number Description Model
----------- ----------- -----
798-0522-01 RAID Manager 6.1.1 -
798-0522-02 RAID Manager6.1.1 Update 1 -
798-0522-03 RAID Manager6.1.1 Update 2 -
704-6708-10 CD, SUN STOREDGE RAID Manager6.22 -
704-7937-05 CD, SUN STOREDGE RAID Manager6.22.1 -
REFERENCES:
BugId: 4479887 - RDAC open log messages when RDBMS (Oracle, Sybase)
accesses raw lun partitions.
4630273 - installing rm6 on s9 leads to a long pause at system
boot.
PatchId: 
112126: RAID Manager 6.22.1: generic RM6.22.1 Solaris 8 patch.
Manual: 805-7758-12: Sun StorEdge RAID Manager 6.22.1 Release Notes.
URL: http://www.sun.com/storage/disk-drives/raid.html
ESC: 539493 - bug 4238051 /sd.conf entries cause excessive boot times
w/A3500 and EMC
PROBLEM DESCRIPTION:
Versions of patch 112126 for RAID Manager 6.22.1 (RM 6) before -05
failed to install on Solaris 9 systems. If the patch is not installed,
all RM 6.22.1 fixes are lost including access to database data may be
impaired as described in bug 4479887.
This issue applies to any system type and any A1000/A3x00/A3500FC array
with RM 6.22.1 running on Solaris 9. It also applies to any system
with an earlier version of RM 6, such as 6.22 or 6.1.1 Update 2, which
is upgraded to RM 6.22.1. It also applies to customers who are running
RM 6.22.1 and who are upgrading to Solaris 9 from an earlier version.
The following command displays the version of RM installed, in this case
6.22.1:
# pkginfo -l SUNWosar
VERSION: 06.22,REV=01.54
Attempts to install the RM 6 patch, 112126, on Solaris 9 produce
the following error and the 'patchadd' utility terminates.
# patchadd 112126
Checking installed patches...
Executing prepatch script...
This patch only applies to rm6 running on Solaris 8.... exiting
The prepatch script exited with return code 1.
Patchadd is terminating.
#
The root cause for this issue is that Patch 112126 or earlier does
not allow installation on Solaris 9 due to a check for the Solaris
version in the patch pre-install script. This script is executed
during the patchadd process. This issue is fixed in the version of the
RM 6.22.1 patch, 112126.
IMPLEMENTATION:
---
| | MANDATORY (Fully Proactive)
---
---
| X | CONTROLLED PROACTIVE (per Sun Geo Plan)
---
---
| | REACTIVE (As Required)
---
CORRECTIVE ACTION:
The following recommendation is provided as a guideline for authorized
Enterprise Services Field Representatives who may encounter the above
mentioned problem.
Use patch 112126 or later on Solaris 9 systems. If 112126 was
already installed on the Solaris 9 system which was previously upgraded
from Solaris 8, then there is no need to install 112126 which has
exactly the same content, ie only the pre-installation check for
Solaris versions was changed.
NOTE: When using Solaris 9 with RM 6.22x, host boot time will experience a
slow down. The slowdown can be explained as follow: On Solaris 9,
probing all the device nodes put under rdnexus by RM6 is slowed by a
kernel change, which is in power management code, as described in bug
4630273. This new code spends about 1 second to scan every third
rdriver instance in the Solaris device tree. The duration of the
slowdown can be understood in some simple math:
X = total number of rdnexus entry in /kernel/drv/rdnexus.conf
example of rdnexus entry:
name="rdnexus" parent="pseudo" instance=0;
V = total number of rdriver generic module entry in
/kernel/drv/rdriver.conf.
example of rdriver generic module entry:
name="rdriver" parent="rdnexus" target=4 lun=0;
N = the total number of rdriver instances in the Solaris device tree
T = the slowdown duration in seconds
N = X*V
T = N/3
The V value can increase by running the add16lun.sh, add32lun.sh
scripts, changing sd.conf, running genscsiconf(1m), changing the target
id on the Rdac controller, and attaching other types of arrays. The
rdriver generic module entries are always in a symmetric format, ie
each target will have the same number of luns, so one can figure out
the V value by multiply LUNs supported by number of devices listed in
rdriver.conf. In the case of 8 lun supported in A1000, X=64 and if
default target id on A1000 and rmparams are used, V=8*3 for target
0,4,5 listed in rdriver.conf. T=64*8*3/3=512 seconds.
However, one could reduce the slowdown in boot time, especially on
Solaris 9 systems, by removing rdnexus entries in
/kernel/drv/rdnexus.conf. The total number of rdnexus entries that can
be removed depends on individual systems but general guide lines are as
follows:
. Use 'ls /devices/pseudo | grep rdnexus' to check the number of
rdnexus nodes used.
. Leave enough entries for future expansion. Each rdnexus node
represents a HBA port connected to a Rdac controller. In general,
16 rdnexus entries in /kernel/drv/rdnexus.conf is sufficient for
systens with 4 arrays or less.
. Remove the rdnexus entries by starting from highest instance number
. Some of the test results show good improvement in boot time.
system configuration:
A1000 with 32 lun support, V=96
Solaris 8 with 64 rdnexus entry boot time = 3 minutes
Solaris 9 with 64 rdnexus entry boot time = 39 minutes
Solaris 9 with 16 rdnexus entry boot time = 13 minutes
COMMENTS:
None.
============================================================================
Implementation Footnote:
i) In case of MANDATORY FINs, Enterprise Services will attempt to
contact all affected customers to recommend implementation of
the FIN.
ii) For CONTROLLED PROACTIVE FINs, Enterprise Services mission critical
support teams will recommend implementation of the FIN (to their
respective accounts), at the convenience of the customer.
iii) For REACTIVE FINs, Enterprise Services will implement the FIN as the
need arises.
----------------------------------------------------------------------------
All released FINs and FCOs can be accessed using your favorite network
browser as follows:
SunWeb Access:
--------------
* Access the top level URL of http://sdpsweb.ebay/FIN_FCO/
* From there, select the appropriate link to query or browse the FIN and
FCO Homepage collections.
SunSolve Online Access:
-----------------------
* Access the SunSolve Online URL at http://sunsolve.Corp/
* From there, select the appropriate link to browse the FIN or FCO index.
Internet Access:
----------------
* Access the top level URL of https://infoserver.Sun.COM
--------------------------------------------------------------------------
General:
--------
* Send questions or comments to finfco-manager@sdpsweb.EBay
--------------------------------------------------------------------------
Copyright (c) 1997-2003 Sun Microsystems, Inc.