fiber channel locking up

[Rick Garland]

Hi all:

Got some HPUX 10.20 and 11.00 systems on K series, L series, and N series.

We have recently installed a SAN and right now it is dedicated to the backups.

We have fiber running to 16 port Brocades and then to SureStore E SCSI bridges FC 4/2 then to DLT 8000 devices. Seems that after some period of time, I am not able to access the DLT devices unless I reboot the SCSI bridges.

I am using the uma command to move tapes around. Place a tape in a drive and then I would like to move it back to a slot. On a client system I issue the mt -t /dev/rmt/*m offl command and the response I get is the device is busy. When I reboot the SCSI bridges, it works fine.

Is there a patch or some configuration I am missing to prevent this? Needless to say, this is creating havoc with the backups because they fail with a "Device busy" error when the device has done nothing.

[Michael Tully · Accepted solution]

Hi Rick,

We had a similar problem to yours,

2 x N class --> Brocade switch --> Surestore
with FC 4/1

Our drives would lock up, and we would have
to reboot bridges, machines and switches.

We solved the problem by installing the
following patches/drivers/kernel parameters
and procedures.

Patches
PHKL_21834
PHKL_23790
PHKL_22759
PHSS_24044

Driver
A5158A B11.00.06 (obtain this from www.software.hp.com)
I am not sure what the drivers are for the 'k' class, but I would make sure you have the latest version.

change the kernel parameter 'st_ats_enabled' to 0

Turn off the EMS monitoring for Tapes drives
Fabric mode must be used as the switches do not
support arbitrated loop.

Make sure that only one server drives the robotics in the SAN or you will find your servers sending SCSI resets, which is probably why your SAN locks up.

HTH
-Michael

[Rick Garland]

Hi Michael:

Thanks for the info. Not sure how the EMS comes into play here because we do have an L class system with EMS monitoring and this seems to be the only set of DLT drives that is cooperating. I will be checking the the info you have provided to see if the differences do exist.

Again, many thanks!

[Michael Tully]

Hi Rick,

The suggestions that I've outlined were from
a white paper given to me by HP, this
included the disabling of EMS monitoring of
the tape drives.

I have made one error in my previous note
about where to use 'fabric'. Fabric mode must be used in both the switch and the bridge. HP do not support arbitrated loop in the bridges, at least in the model I've got. I don't see that there would be any difference to the model that you have. There was a few sites here in OZ, that had this particular problem and it was sorted out by implementing the above recommendations.

HTH
-Michael

[Rick Garland]

Michael:

Do you know where I can find the white paper.

(Be lots of points for you!)

Thanks!

[Michael Tully]

Hi Rick,

Send me your e-mail address to
michael.tully@metcash.com and I'll send the paper I have. It is only a single sheet of paper with basically the same information and a bit of a write-up on firmware.

Regards
-Michael

[Steve Bonds]

Michael Tully wrote:

-----
Make sure that only one server drives the robotics in the SAN or you will find your servers sending SCSI resets, which is probably why your SAN locks up.
-----

This is very important-- even a single host running an "ioscan" on the same SAN can interrupt a backup in progress, confuse the tape drives, and in general wreak havoc on your tape infrastructure.

If you must use tapes on a SAN, you should use zoning to ensure that the smallest number of hosts possible have access to those devices, and educate your sysadmins about how fragile the tape infrastructure is.

Of course, I've always chosen to directly connect tape drives rather than use a SAN because of these problems, but it may be too late for you.