From: McCracken, Denise (Denise.McCracken@misyshealthcare.com)
Date: Mon Jun 21 2004 - 19:46:49 EDT
Thanks to Derek Haining for the answer to the problem, depressing as
it may be:
I am familiar with this problem. I suggest that you do the following:
>From V5.1A issue the command:
scu show edt
Examine the output from the "Vendor ID" field. If this contains garbage
characters, then you have a major problem.
You are aware, I presume, of the fact that Tru64 V5.x has the new device
names in use. (/dev/disk/dsk<n>a) Part of this change included the
persistent hardware database. The idea was to allow you to connect a
physical disk to any location yet still be able to reference the data
by the same device name. Anyway this is accomplished using the World-
Wide ID associated with the disk. Since the HSx controllers don't
export physical disks, a WWID is constructed using some of the data
you should see from the "scu show edt" command. A very important piece
is the Vendor ID field.
Note that these controllers work just fine in a v4.0x environment. Under
v5.x, however, the corrupted Vendor ID field causes the devices to be
unrecognizable.
The corruption occurs when you copy a configuration from one HSZ to another
when running HSOF V37Z (for an HSZ40, V57Z for an HSZ50, and V77Z for an
HSZ70).
A patch was released (and a Blitz message about the problem) by Compaq a
couple of years ago, but perhaps customers did not see the blitz. The
blitz message essentially said that if your controllers get into this
state that are NOT REPAIRABLE. Essentially they become boat anchors.
We went through 4 HSZ40s not realizing that when we were copying the
configuration from the "old" controller to the "new" one that we were
destroying the new controller.
The fix is to write down your configuration, replace all damaged controllers
with new ones, apply AT LEAST PATCH 1 for the Vx7Z firmware, and
re-configure
your HSZ controllers.
I am told that the "dangerous" command might be used to fix the controllers,
but I have not obtained any documentation to show how such might be done.
-----Original Message-----
We have run into a problem with compatibility between HSZ40
controllers and 5.1a. If we run the commands:
# scu
# sbtl <port> <target> <lun>
# show inquiry
and we see "Vendor Identification: DEC" in the output, the
controller works with 5.1a. Most controllers have this string empty or
corrupted and will not work. Only one of the raidsets will be recognized.
Does anyone know of a patch that can fix this problem, or any other
way to identify the controllers that will work? From hszterm, serial
numbers or firmware revisions, we can't tell the difference, so our hardware
vendors don't know what to bring us.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:50:01 EDT