[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | HSZ40 Product Conference |
|
| Moderator: | SSDEVO::EDMONDS |
|
| Created: | Mon Apr 11 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 902 |
| Total number of notes: | 3319 |
810.0. "possible data integrity problem HSOF V3.0/V5.0" by UTOPIE::OETTL (hide bug until worst time) Sat Mar 15 1997 06:56
Since I did not find any information concerning the possible data corruption
problem in HSOF V3.0 /V5.0, I'll post it here.
Reply .1 and .2 contain the fix.
�tzi
----------------------------------------------------------------------------
Author : LINDA WARREN
User type : DBA
Location : USTIMA
Vaxmail address : BSS::LWARREN
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT BLITZ
| | | | | | | |
+---------------------------+
BLITZ TITLE: Possible data integrity problem with HSOF V3.0/5.0
and mirrorsets
PRIORITY LEVEL: 1
DATE: March 3, 1997
TD #: 2250
AUTHOR: Kurt Astor
DTN: 522-2478
EMAIL: SSDEVO::ASTOR
DEPARTMENT: Solutions Engineering Support
=================================================================
PRODUCT NAME(S): HSZ40-BX/CX HSZ50 HSJ50 RA310 RA410 RA450
SWXRC-04/05 HSZ20
Other solutions including these controllers such as
ESA
PRODUCT FAMILY(IES):
Storage __X
Systems/OS ___
Networks ___
PC/Peripherals ___ {includes printers, monitors, etc.}
Software Apps. ___
BLITZ TYPE: {Check all that apply}
Maintenance Tip ___ {Info. will assist servicing the product}
Service Action Requested __X {MCS is requested to perform an activity}
IF SERVICE ACTION IS REQUESTED: (Check all that apply.)
Labor Support Required __X {Requires MCS to provide service labor}
Material Support Required ___ {Requires MCS to provide material}
Estimated time to complete activity (in hours): .1 per controller
Will this require a change in the field's inventory: Yes ___ No __X_
Will an FCO be associated with this advisory? Yes ___ No _X__
DESCRIPTION OF SERVICE ACTIVITY REQUESTED (if applicable):
******IMMEDIATELY****** notify all affected Customers of this issue
and FAX them a copy of the attached Customer letter. Request
immediate implementation of the workarounds recommended under
SOLUTION.
**********************************************************************
SYMPTOM:
Data can be lost from mirror sets and this occurance may be
undetected by the controller or the operating system.
Array controllers running HSOF V3.0/5.0 in configurations
containing mirrorsets are exposed to a potential data integrity
problem. Affected products and solutions are identified in the
"PRODUCT NAMES" section above.
IF ALL THE CONDITIONS LISTED BELOW ARE MET, DATA INTEGRITY IS AT RISK
ON ALL OF THE UNITS CONFIGURED ON THE CONTROLLER:
1) HSOF V3.0 or V5.0 running on the products or solutions listed
in the "PRODUCT NAMES" section above.
2) Drives configured in a controller-based mirrorset or striped
mirrorset (RAID 1 or RAID 0+1)
3) Transfer size larger than the MAXIMUM_CACHED_TRANSFER_SIZE
parameter (default value is 32, resulting in a maximum cached
transfer size of 16KB)
4) Drive error occurs, causing mirrorset repair attempt (instance
codes 023B0064, 023C2264, or 02020064)
SOLUTION:
The following operating systems may use the workaround shown below
to prevent the problem from occurring:
OpenVMS
Windows NT
Sun Solaris
IBM AIX
HP-UX
Novell Netware
DIGITAL recommends that the workaround shown below be applied in
all host environments. With this workaround installed, transfers
less than 512KB are not exposed to the problem.
The workaround consists of setting the
MAXIMUM_CACHED_TRANSFER_SIZE parameter to 1024 for any units
which use mirror sets by using the following steps. Note that
both controllers must be rebooted to implement this change.
1. Unmount any units from the host system that are accessed
through the storage subsystem. Windows NT, Netware, HP-UX and
IBM AIX users should shutdown the operating system using the
normal procedure and when the operating system is halted,
power the system OFF.
If you are using the tip utility on SUN Solaris to make a
serial connection to the subsystem, you do not need to
shutdown the host system.
2. You must make a serial connection to the RAID controller to
access the Command Line Interpreter (CLI). You can make the
serial connection from a maintenance terminal, PC or a tip
connection.
3. Issue the following CLI command:
CLI> SET Dxxx MAXIMUM_CACHED_TRANSFER_SIZE = 1024
4. Ensure that your mirrorsets use read cache by issuing the
following CLI command:
CLI> SHOW Dxxx
Look for READ_CACHE in the display. If read cache is
disabled, enable it by issuing the following CLI command:
CLI> SET Dxxx READ_CACHE
5. Restart both controllers by issuing the following CLI
commands. ote that this step is a required part of the
problem prevention process.
CLI> RESTART OTHER_CONTROLLER
CLI> RESTART THIS_CONTROLLER
6. Remount affected filesystems or devices and restart your
applications as appropriate to your host environment.
NOTE: DIGITAL UNIX:
In addition to the above, DIGITAL UNIX users must do the following:
=====================================================================
PROBLEM:
All versions of Digital UNIX have the ability to permit applications
software to request 16 megabyte raw I/O reads and writes. So
even with the controller's maximum cache transfer size set to 512k bytes
(1024 blocks) an application using raw I/O may set up the right
conditions for the HSOF V3.0/5.0 mirror set problem to occur.
RESOLUTION/WORKAROUND:
Digital's recommended workaround is to tune Digital UNIX so that it
will not perform reads and writes larger than the 512K byte
maximum cache transfer size. Using the following instructions, Digital
UNIX can be tuned so that it will, instead, break up such requests into
multiple 512K byte requests.
This tuning can be performed manually or with the aid of specially
created scripts. To ease the process and reduce the possibility of
human error, Digital recommends using the scripts. A C language program
is also available to verify the results of the tuning.
These two scripts ( v3_512k_max_rec.csh and v4_512k_max_rec.csh ) and
the C language program v3_DumpTable.c can be obtained from Digital's
Customer Support Centers.
I. TO MANUALLY TUNE DIGITAL UNIX VERSIONS PRIOR TO V4.0 FOR A 512K BYTE
MAXIMUM TRANSFER SIZE -
A. Become root.
B. cd /usr/sys/data
C. cp cam_data.c cam_data.c.orig /* save original file */
D. In the file cam_data.c, using a text editor, search for the
HSZ20, HSZ40, and HSZ50 entries.
E. Change the DEC_MAX_REC field in each entry to (1024 * 512) bytes
using a text editor.
1. HSZ20 Example:
******************************* Change From **********************************
/* HSZ20 */
{"DEC HSZ2", 12, DEV_HSZ20, (ALL_DTYPE_DIRECT << DTYPE_SHFT) | SZ_HARD_DISK
| SZ_RAID ,
(struct pt_info *)ccmn_hsx00_sizes, NULL, DEC_MAX_REC, NO_DENS_TAB,
NO_MODE_TAB, (SZ_DYNAMIC_GEOM | SZ_DISPERSE_QUE | SZ_REORDER),
NO_OPT_CMDS, 90, 74, DD_REQSNS_VAL |
DD_INQ_VAL, 36, 160
},
****************************** Change To *************************************
/* HSZ20 */
{"DEC HSZ2", 12, DEV_HSZ20, (ALL_DTYPE_DIRECT << DTYPE_SHFT) | SZ_HARD_DISK
| SZ_RAID ,
(struct pt_info *)ccmn_hsx00_sizes, NULL, (1024 * 512), NO_DENS_TAB,
NO_MODE_TAB, (SZ_DYNAMIC_GEOM | SZ_DISPERSE_QUE | SZ_REORDER),
NO_OPT_CMDS, 90, 74, DD_REQSNS_VAL |
DD_INQ_VAL, 36, 160
},
2. HSZ40 Example:
******************************** Change From *********************************
/* HSZ40 */
{"DEC HSZ4", 12, DEV_HSZ40, (ALL_DTYPE_DIRECT << DTYPE_SHFT) | SZ_HARD_DISK
| SZ_RAID ,
(struct pt_info *)ccmn_hsx01_sizes, NULL, DEC_MAX_REC, NO_DENS_TAB,
NO_MODE_TAB,
(SZ_LONG_STO_RETRY | SZ_DYNAMIC_GEOM | SZ_DISPERSE_QUE | SZ_REORDER),
NO_OPT_CMDS, 90, 74, DD_REQSNS_VAL |
DD_INQ_VAL,
36, 160/* HSZ40 */
****************************** Change To *************************************
{"DEC HSZ4", 12, DEV_HSZ40, (ALL_DTYPE_DIRECT << DTYPE_SHFT) | SZ_HARD_DISK
| SZ_RAID ,
(struct pt_info *)ccmn_hsx01_sizes, NULL, (1024 * 512), NO_DENS_TAB,
NO_MODE_TAB,
(SZ_LONG_STO_RETRY | SZ_DYNAMIC_GEOM | SZ_DISPERSE_QUE | SZ_REORDER),
NO_OPT_CMDS, 90, 74, DD_REQSNS_VAL |
DD_INQ_VAL,
36, 160
},
3. HSZ50 Example:
********************************* Change From *******************************
/* HSZ5x */
{"DEC HSZ5", 12, DEV_HSZ50, (ALL_DTYPE_DIRECT << DTYPE_SHFT) | SZ_HARD_DISK
| SZ_RAID ,
(struct pt_info *)ccmn_hsx01_sizes, NULL, DEC_MAX_REC, NO_DENS_TAB,
NO_MODE_TAB,
(SZ_LONG_STO_RETRY | SZ_DYNAMIC_GEOM | SZ_DISPERSE_QUE | SZ_REORDER),
NO_OPT_CMDS, 90, 74, DD_REQSNS_VAL |
DD_INQ_VAL,
36, 160
},
********************************* Change To **********************************
/* HSZ5x */
{"DEC HSZ5", 12, DEV_HSZ50, (ALL_DTYPE_DIRECT << DTYPE_SHFT) | SZ_HARD_DISK
| SZ_RAID ,
(struct pt_info *)ccmn_hsx01_sizes, NULL,(1024 * 512), NO_DENS_TAB,
NO_MODE_TAB,
(SZ_LONG_STO_RETRY | SZ_DYNAMIC_GEOM | SZ_DISPERSE_QUE | SZ_REORDER),
NO_OPT_CMDS, 90, 74, DD_REQSNS_VAL |
DD_INQ_VAL,
36, 160
},
******************************************************************************
F. Write the file and leave the editor.
G. Rebuild the kernel.
H. Reboot the system with the kernel just created. [NOTE: The
maximum record size change will not become effective until the
system is rebooted.]
II. TO TUNE VIA SCRIPT DIGITAL UNIX VERSIONS PRIOR TO V4.0 FOR A 512K
BYTE MAXIMUM TRANSFER SIZE -
A. Obtain the script v3_512k_max_rec.csh from a Digital Customer
Support Center:
B. Place the script file in directory
/usr/tmp
C. Become root.
D. Execute the script v3_512k_max_rec.csh. It will perform steps
I.B through I.F above.
E. Rebuild the kernel.
G. Reboot the system with the kernel just created. [NOTE: The
maximum record size change will not become effective until
the system is rebooted.]
III. TO VERIFY THE CURRENT VALUE OF THE MAXIMUM TRANSFER SIZE PARAMETER
ON DIGITAL UNIX SYSTEMS PRIOR TO V4.0 -
A. Obtain the file v3_DumpTable.c from a Digital Customer
Support Center.
B. Place the file in directory:
/usr/tmp
C. Compile file DumpTable.c
D. Execute the resulting program. It will print out an internal
Digital UNIX kernel table which will show the value as in
the following "before and after tuning" examples.
Before tuning, the HSZ entries would appear as:
DEC HSZ2 16777216
DEC HSZ4 16777216
DEC HSZ5 16777216
After tuning, they would appear as:
DEC HSZ2 524288
DEC HSZ4 524288
DEC HSZ5 524288
IV. TO MANUALLY TUNE DIGITAL UNIX VERSIONS V4.0 AND LATER FOR a 512K
BYTE MAXIMUM TRANSFER SIZE -
A. Become root.
B. cd /etc
C. cp ddr.dbase ddr.dbase.orig /* save original file */
D. In the file ddr.dbase, using a text editor, search for "HSZx"
Before modification, the entry will look as follows:
SCSIDEVICE
#
# Matches everyone in the HSZx family
#
Type = disk
Name = "DEC" "HSZ"
#
PARAMETERS:
TypeSubClass = hard_disk, raid
BlockSize = 0
BadBlockRecovery = disabled
DynamicGeometry = true
DisperseQueue = true
LongTimeoutRetry = enabled
ReadyTimeSeconds = 90
TagQueueDepth = 74
RequestSenseLength = 160
PwrMgmt_Capable = false
E. Add the MaxTransferSize parameter with a value assigned of
0x80000.
After modification, the entry should look as follows:
SCSIDEVICE
#
# Matches everyone in the HSZx family
#
Type = disk
Name = "DEC" "HSZ"
#
PARAMETERS:
TypeSubClass = hard_disk, raid
BlockSize = 0
BadBlockRecovery = disabled
DynamicGeometry = true
DisperseQueue = true
LongTimeoutRetry = enabled
ReadyTimeSeconds = 90
TagQueueDepth = 74
RequestSenseLength = 160
PwrMgmt_Capable = false
MaxTransferSize = 0x80000
F. Write the file and leave the editor.
G. Rebuild the database using the following command:
ddr_config -c
H. Reboot the system. [NOTE: The maximum record size change will
not become effective until the system is rebooted.]
V. TO TUNE VIA SCRIPT DIGITAL UNIX VERSIONS V4.0 AND LATER FOR A 512K
BYTE MAXIMUM TRANSFER SIZE -
A. Obtain the script v4_512k_max_rec.csh from a Digital Customer
Support Center.
B. Place the file in directory
/usr/tmp
C. Become root.
D. Execute the script v4_512k_max_rec.csh. It will perform steps
IV.B through IV.G above.
E. Reboot the system. [NOTE: The maximum record size change will
not become effective until the system is rebooted.]
VI. TO RETUNE DIGITAL UNIX VERSIONS PRIOR TO V4.0 FOR THE ORIGINAL,
I.E. 16 MEGABYTE, MAXIMUM RAW I/O TRANSFER SIZE -
A. Become root.
B. cd /usr/sys/data
C. cp -p cam_data.c.orig cam_data.c. /* restore original file */
D. Rebuild the kernel.
E. Reboot the system. [NOTE: The maximum record size change will
not become effective until the system is completed.]
VII. TO RETUNE DIGITAL UNIX VERSIONS V4.0 AND LATER FOR THE ORIGINAL,
I.E. 16 MEGABYTE, MAXIMUM RAW I/O TRANSFER SIZE -
A. Become root.
B. cd /etc
C. cp -p ddr.dbase.orig ddr.dbase /* restore original file */
D. Rebuild the database using the following command:
ddr_config -c
E. Reboot the system. [NOTE: The maximum record size change will
not become effective until the system is rebooted.]
VIII. TO VERIFY THE CURRENT VALUE OF THE MAXIMUM TRANSFER SIZE PARAMETER
FOR DIGITAL UNIX VERSIONS V4.0 AND LATER, EXECUTE THE FOLLOWING
COMMAND:
ddr_config -s 0 DEC HSZ
When a 512k maximum transfer size has been specified, there will
be one line, among many, of the output of this command that looks
like:
MaxTransferSize = 0x80000
When a 16 megabyte transfer size has been specified, there will
be one line, among many, of the output of this command that looks
like:
MaxTransferSize = 0x1000000
ADDITIONAL COMMENTS:
There may be a slight performance degradation experienced as a result
of tuning for a 512K byte maximum transfer size.
The above workarounds have no effect on problems that may already have
occurred. They serve only to prevent applications software from creating
the conditions which may lead to the HSOF V3.0/5.0 mirror set problem.
VERIFICATION:
Use the SHOW Dxxx command to verify that the
MAXIMUM_CACHED_TRANSFER_SIZE parameter is set to 1024 and that
READ CACHE is enabled.
ADDITIONAL INFORMATION:
A patch that will correct this problem in HSOF V3.0 and V5.0 for
all host environments has been identified and is currently being
tested. Patch release is expected within two weeks.
All MDDS contract Customers and Customers who have registered their
controllers will receive a letter containing the patch as soon as it
is released.
LARS INFORMATION: (Supplied by MCS)
Attention Service Personnel: Begin the comment field of your LARS
with the word "BLITZ" when you perform an activity associated with a
BLITZ Type "Service Action Requested".
CUSTOMER LETTER:
=============================================================================
_____________
| | | | | | | | TM
|d|i|g|i|t|a|l|
|_|_|_|_|_|_|_|
To: Distribution Date: 3 March 1997
From: Mark Lewis
Dept: Storage PM&D
PH/DTN: 719-548-2857/522-2857
MS: CXO1-2/N24
ENET: [email protected]
Subject: Technical Issue with Mirroring (RAID 1) on HS Controllers
Running HSOF 3.0 and 5.0
In past few days, we discovered a problem with the HS series controllers
running HSOF Software version 3.0 or 5.0. Under certain circumstances, and
when multiple specific conditions occur, it is possible that data integrity
may be compromised. While these conditions are rare, we understand that any
potential problem needs to be immediately addressed. Briefly, the conditions
that must exist are:
o HSZ or HSJ controller running HSOF 3.0/5.0
o Running RAID 1 (mirroring)
o Reading a 'large' file
o A disk media error occurs requiring the regeneration of data
The cause of the problem has been isolated to a software issue within the
controller. The steps that we are taking to resolve this issue are:
o We are recommending an interim change to the controller settings
that will significantly reduce and in many cases eliminate the
potential problem. A technical Blitz is attached that details
this change.
o We have developed a patch for the software that will be released
as soon as thorough testing has been completed. Our plan is to
release this patch in 2 weeks.
o We have placed the affected products on ship-hold until we can
incorporate the software patch in production.
o All of our software currently in development and test has been
reviewed and changed to eliminate this potential issue.
o We are reviewing our test processes to insure that problems
of this kind will be found in Engineering testing.
We regret any inconvenience caused by this problem. It is our top priority to
provide our customers with a quality product and to resolve any issues as
quickly as possible. Our most serious concern is the integrity of data. Please
contact Kurt Astor (noted in Blitz) if you require additional technical
information.
Sincerely,
Mark Lewis
Program Manager, Array Controllers
Attch:
Product Blitz
*** DIGITAL INTERNAL USE ONLY ***
\\ GRP=TIME_DEPENDENT CAT=HARDWARE DB=CSSE_TIME_CRITICAL
\\ TYPE=KNOWN_PROBLEM TYPE=BLITZ STATUS=CURRENT PROD=HSOF-HSD
\\ PROD=HSOF-HSJ PROD=HSOF-HSZ
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 810.1 | Blitz with solution | UTOPIE::OETTL | hide bug until worst time | Sat Mar 15 1997 06:59 | 165 |
| Author : LINDA WARREN
User type : DBA
Location : USTIMA
Vaxmail address : BSS::LWARREN
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT BLITZ
| | | | | | | |
+---------------------------+
BLITZ TITLE: Patch for data integrity problem with HSOF V3.0/5.0
and mirrorsets
PRIORITY LEVEL: 1
DATE: March 13, 1997
TD #: 2254
AUTHOR: Kurt Astor
DTN: 522-2478
EMAIL: SSDEVO::ASTOR
DEPARTMENT: Solutions Engineering Support
=================================================================
PRODUCT NAME(S): HSZ40-BX/CX HSZ50 HSJ50 RA310 RA410 RA450
SWXRC-04/05 HSZ20
Other solutions including these controllers such as
ESA
PRODUCT FAMILY(IES):
Storage __X
Systems/OS ___
Networks ___
PC/Peripherals ___ {includes printers, monitors, etc.}
Software Apps. ___
BLITZ TYPE: {Check all that apply}
Maintenance Tip ___ {Info. will assist servicing the product}
Service Action Requested __X {MCS is requested to perform an activity}
IF SERVICE ACTION IS REQUESTED: (Check all that apply.)
Labor Support Required __X {Requires MCS to provide service labor}
Material Support Required ___ {Requires MCS to provide material}
Estimated time to complete activity (in hours): .1 per controller
Will this require a change in the field's inventory: Yes ___ No __X_
Will an FCO be associated with this advisory? Yes ___ No _X__
DESCRIPTION OF SERVICE ACTIVITY REQUESTED (if applicable):
******IMMEDIATELY****** notify all affected Customers of this issue
and FAX or deliver them a copy of the patch. Request immediate
implementation of the patch.
**********************************************************************
SYMPTOM:
Array controllers running HSOF V3.0/5.0 in configurations
containing mirrorsets are exposed to a potential data integrity
problem. Affected products and solutions are identified in the
"PRODUCT NAMES" section above.
IF ALL THE CONDITIONS LISTED BELOW ARE MET, DATA INTEGRITY IS AT RISK
ON ALL OF THE UNITS CONFIGURED ON THE CONTROLLER:
1) HSOF V3.0 or V5.0 running on the products or solutions listed
in the "PRODUCT NAMES" section above.
2) Drives configured in a controller-based mirrorset or striped
mirrorset (RAID 1 or RAID 0+1)
3) Transfer size larger than the MAXIMUM_CACHED_TRANSFER_SIZE
parameter (default value is 32, resulting in a maximum cached
transfer size of 16KB)
4) Drive error occurs, causing mirrorset repair attempt (instance
codes 023B0064, 023C2264, or 02020064)
SOLUTION:
New product shipping after 3/14/97 includes the patches mentioned below.
The part numbers for the PCMCIA cards on which the latest patches are included
are:
Patched V3.0/5.0 PREVIOUS SALEABLE PREVIOUS
SERVICE PN PART NUMBERS SERVICE PN
Vers Used ON RE-PGMED # Replaces (NEW BUILD #) RE-PGMED #
---- ------- ----------- -------------------- --------------
5.0 HSZ50 BG-R4TS0-0A 5.0-2 BG-QZ0Z0-0A 5.0 NONE
5.0 HSJ50 BG-R4UJ0-0A 5.0-3 BG-QY9M0-0A 5.0 NONE
3.0 HSZ40 BG-R22T0-1A 3.0-3 BG-QHD30-3A 3.0 BG-R22T0-0A 3.0-2
Patches to correct this problem in HSOF V3.0/5.0 have been developed.
Following is the location for these patches based upon the controller
hardware type.
Controller Location
Hardware
Type
HSZ20
HSZ40
RA410
SWXRC-04
RA310 CSC32::ISG$COMMON:[HSZ40.HSZ_PATCHES]
RA450
SWXRC-05
HSZ50 CSC32::ISG$COMMON:[HSZ50.HSZ_PATCHES]
HSJ50 CSC32::ISG$COMMON:[HSJ50.HSJ_PATCHES]
NOTE: Patches to HSOF MUST be installed sequentially, i.e., if you require
Patch 3, Patch 1 and Patch 2 must be installed first.
Engineering highly recommends that ALL affected controllers have this
patch installed.
If the Customer has limited the maximum I/O transfer size based upon
the workaround for this issue published in blitz # TD2250, this
limitation is no longer required.
VERIFICATION:
When the controller is rebooted after the patch is installed, verify
that the revision of the code has been increased by 1.
For instance, on HSOF V3.0Z, prior to installing this patch, the code
should be HSOF V3.0Z-2. After this patch is installed, the code
revision should indicate HSOF V3.0Z-3.
For the other controllers, the upgraded revision should be:
HSOF V5.0Z-2
HSOF V5.0J-3
LARS INFORMATION: (Supplied by MCS)
Attention Service Personnel: Begin the comment field of your LARS
with the word "BLITZ" when you perform an activity associated with a
BLITZ Type "Service Action Requested".
\\ GRP=TIME_DEPENDENT CAT=HARDWARE DB=CSSE_TIME_CRITICAL
\\ TYPE=KNOWN_PROBLEM TYPE=BLITZ STATUS=CURRENT PROD=HSOF-HSD
\\ PROD=HSOF-HSJ PROD=HSOF-HSZ
|
| 810.2 | Patch script for V3.0Z | UTOPIE::OETTL | hide bug until worst time | Sat Mar 15 1997 07:01 | 20 |
| !
!Fix for Mirrorset Repair/Fast Buffer problem
!
run clcp
2
1
y
V30Z
32
0
3
3
20032C44
92A120D8
5F401E00
B2412038
0
3596AE96
3
0
|
| 810.3 | Patch script for V5.0 | UTOPIE::OETTL | hide bug until worst time | Sat Mar 15 1997 07:03 | 20 |
| !
!Fix for Mirrorset Repair/Fast Buffer problem
!
run clcp
2
1
y
V50Z
32
0
2
3
20032C44
92A120D8
5F401E00
B2412038
0
35968F16
3
0
|
| 810.4 | Can the patch be installed live?? | TIMAST::HUGHES | | Fri Mar 28 1997 11:22 | 11 |
| Is there any restrictions on putting this patch on a dual redundant
controller (such as both controllers must be down)???
I have a customer who installed the patch and restarted the 1st
controller just fine. He installed an attempted to restart the 2nd
controller and it hung. After a few minutes, the system panic'd. I
don't have any pertinant details execpt that they were already at patch
level 2.
Thanks
Dave
|
| 810.5 | Not that I know of | SSDEVO::RMCLEAN | | Fri Mar 28 1997 12:52 | 2 |
| I would not expect that to happen but I suppose if the failover didn't
happen correctly then you would get bad results.
|