Fiber connected STK tape drives

[Tom Jameson]

James:

Got the tusc results, if you really want I can attach them.

The meat of the results is that it's failing in the device open:

open("/dev/rmt/c7t3d0BESTnb", O_RDONLY, 03) .......................................... ER
R#6 ENXIO


Tom

[James Murtagh]

Hi Tom,

I guess the next step is to check whether the other server has the same issues and the results from turning st_ats_enabled on.

You don't need to attach the tusc output, that was what I was looking for. As I don't have a tape drive on my workstation can't test these things myself unfortunately. I would be interested to see what call the "mt -t /dev/rmt/4m status" makes as this worked, in a fashion.

There is a device open patch for 11i but I'm sure it is not relevant in this case:

PHKL_26196 s700_800 11.11 Device open fix & Interrupt Migration update

However, the preceding patch, which fixes the main device open issues is included in the 11i standard patch bundle, PHKL_23999.

Regards,

James.

[Stuart Urquhart]

Try setting st_san_safe to 0. I think having it set means you can only open the non-rewind device.

[Tom Jameson]

James:

Here's the pertinent call from a tusc of "mt -f /dev/rmt/c7t3d0BESTnb status":

open("/dev/rmt/c7t3d0BESTnb", O_RDONLY|O_NDELAY, 06) ..... = 4

We've got the PHKL_23999 patch loaded.

HP has moved this up to an escalation engineer and they are recommending against the st_ats_enabled flag. Since I don't have the "abuseable" box ready yet, I can't reboot this one anytime soon.

Stuart:

I tried setting the "st_san_safe" to 0 a few days ago when I could reboot, it didn't make any difference (same errors) so I set it back.

Thanks,
Tom

[James Murtagh]

Hi Tom,

Thanks for the update. If this is escalated now at HP you should be in good hands. Is there any chance of posting the results when you find the solution? Or if you get the other server we can do some more tests if you have the time.

I was expecting O_NONBLOCK from the open of the status command but I believe O_NDELAY is much the same. The open from the STM log is what you would expect to see with st_san_safe enabled as it tried to open the rewind on close device, it is probably better to have this enabled in your situation. You should have got a message in the syslog regarding this open attempt.

I'll do some checking when I'm back at work anyway tonight, i'll post anything interesting I find.

Good luck!

Regards,

James.

[Tom Jameson]

James:

I really appreciate all the time you've given this. This forum has helped with the HP case since I was able to point them here for all the diags we've done.

I will definitely post the results when/if they solve it.

I'll let you know when we get the other server online.

Thanks again,
Tom

[Tom Jameson]

Well, we found the answer. The first thing I asked our SAN guys to check - fabric mapping/zoning.

Apparently, they had incorrectly mapped the drives, when I asked them to remove them and re-map them, they discovered their error.

At least it's working now.

[James Murtagh]

Hi Tom,

Thanks for updating the post, better than I managed! I did check for you, trouble was there was so much documentation to plough through and a lot of the stuff was internal use only.

I did notice some early issues with the 9940B although I think they have been resolved now.

1) The best density for the drive wasn't set in the standard headers
2) Try it is comaptibility mode as a first troubleshooting step (I know you tried this with the 9840B)

Glad it is working now!

Regards,

James.