autochanger driver configuration

[Bob Bonner]

I've added a C1557a tape autochanger to a K class server running 11.0. The tape device is attached to an HPPB Interface card (28655A). Ioscan shows drivers are claimed for the card, the tape device (tape2 /dev/rmt/2m) and the autoch (autox0 /dev/rac/c4t3d1). However, whenever I run a.out from /usr/contrib/src on the card or the changer, I get an open :Invalid Argument error...Any Ideas?

[Duncan Edmonstone]

what does this command return?

mc -p /dev/rac/c4t3d1 -q

if you get something meaningful try:

mc -p /dev/rac/c4t3d1 -r DIMS

to get the contents of the library

HTH

duncan

[Bob Bonner]

The command mc -p /dev/rac/c4t3d1 -q returns
ERROR: /dev/rac/c4t3d1: Invalid argument. I just checked the scsi card and it's driver is scsi1. I think that should be spt so I'm going to change that and see what effect it has.

[Jan Klier · Accepted solution]

No, scsi1 is the correct driver for the HBA.

On HPPB interface (your case) the pass-through interface cannot co-exist with the class drivers.

Thus, if you want to send pass-through commands to the changer, then you must configure the changer to use the spt driver (with the driver spt) statement in the system file.

The same is true for the tape drive.

[Sandip Ghosh]

I think you need schgr driver also in the kernel to operate that device.

Sandip

[Jan Klier]

Sandip,

You are partially correct.

The schgr driver is the class driver for all libraries other than ones on HPPB I/O cards (those are driven by the autox0 driver).

The schgr driver can accept passhthrough I/O commands simultaneously to changer operations. The autox0 driver cannot (!) do this.

The HPPB I/O interfaces are older and were designed before passthrough I/O was being used for devices, thus it does not have the infrastructure in place to do this. The spt driver was put in place as a special purpose class driver to help with this, allowing passthrough access to HPPB devices. However, since it was added after the fact, and not designed into the driver stack it cannot co-exist with the other driver.

When the newer driver stack was designed (schgr, sdisk, stape, sctl) pass-through was designed into it from the beginning, allowing it to always be executed.

Acutally, if you have a device on a C720 type HBA, you don't even have to use schgr for passhthrough I/O as long as you create the correct device node, as sctl (the pass-through only interface) is defaulted on all unclaimed devices on these interfaces.

[Michael Tully]

Hi,

You need to configure a special device to use the robotics. Follow the information in the attachment. It will fix the problem. (I hope)

Cheers
~Michael~

[Alexander M. Ermes]

Hi there.
If you go by Micheal's advice, it will be ok.
We have gone through this document with our libraries / autochangers for years and they work well.
Rgds
Alexander M. Ermes

[Bob Bonner]

The autochanger works like a champ, thanks to all. The tape drive however responds with an open error, any suggestions on that one?

Thanks again,

Bob Bonner

[Duncan Edmonstone]

Bob,

What command generates the error? What is the exact syntax of the error? Is there a tape in the drive when you issue the command?

Cheers

Duncan

[Bob Bonner]

I've attached some pertinent data concerning the tape drive. Including the exact error message.

[Duncan Edmonstone]

Hmm not sure whether the scsi_io.c program is designed to work on tape drives as well, I thought it was only for pass-thru devices like the robotics...

From your mc -r command it looks like you already have a tape in the drive, so try the following:

mt -f /dev/rmt/2mn stat

HTH

Duncan

[Bob Bonner]

All mt commands return an i/o error..

[Duncan Edmonstone]

Maybe the tape is in the drive, but offlined...

Use the front panel of the robot to put the tape away, and the load another into the drive... the repeat the mt command.

HTH

Duncan

[Michael Tully]

Hi Bob,

A couple of things spring readily to mind
about this problem.

You may wish to disable the potential
SCSI errors that cause tapes to get
stuck in drives. Add to your system kernel
'st_ats_enabled 0'

Disable the EMS monitoring for SCSI tapes.
Attached is a document on how.

If you using Omniback as your backup tool
make sure that you are using a lock for
each logical drive that is created. Also
make sure that the autochanger itself uses
the option to eject tapes back to the slot
if a backup fails, not just abort.

[Bob Bonner]

I don't have any of those monitor files, so I don't think they apply. However, I'll make the kernel addition and continue to search for monitors that could have some effect.