Autoloader functions not enabled

[EWTHeckman]

When I tested both the card and the drive on a Windows XP machine, the loader did appear. That says to me that the drive is working as it should and that it's compatible with the card.

 

IMHO, it seems that there may be a switch setting which needs to be changed. Since these drives had been previously tested with Retrospect, I would think there should be records of what switch settings are needed for this drive. Are such records available?

[rhwalker]

Ed,

 

I agree with you. To repeat my prior suggestion:

 

This is why I suggested having EMC support (or some other user) post the Apple System Profile seen for a working drive, and to report the settings of the options switch on such a unit.

Russ

Edited April 22, 2008 by Guest

[EWTHeckman]

That's true, Russ. When I contacted EMC tech support, they wanted to start by seeing a log of the SCSI activity. Robin's post was the first response since that call.

[rhwalker]

When I contacted EMC tech support, they wanted to start by seeing a log of the SCSI activity. Robin's post was the first response since that call.

While I'm a simple soul, I have written my share of Unix device drivers (back in my youth) for problematic devices including tape drives. They all had their quirks.

 

Your earlier post noted:

 

The SCSI ID switch sets the ID for both the drive AND the loader. The drive appears as LUN 0 for that ID and the loader is supposed to show up as LUN 1 for the same ID. I've now set the SCSI ID to 0 because of ATTO's earlier suggestion.

 

I also found two support documents on HP's site that describe the same problem of the loader not being visible to the host computer. The only difference between the two is that they each deal with different versions of Suse Linux.

 

In both cases, the OS uses the SCSI command SCSI REPORT LUNS to discover the existence of the loader. At the time these documents were written (2004) that command was not implemented for this drive. I do have the latest firmware installed, but HP doesn't make the full firmware history available, so I don't know if they ever got this command implemented. The solution given in the documentation is to have the OS scan for available LUNs.

This is a quality tape drive from a major vendor. I have to believe, even if it takes an incredible hack, that any major backup software would have to support it. The fact that you are able to take the same card, cable, and autoloader/drive to another computer, changing "only" the OS from Mac to Windows, tells me, as it does you, that the HBA, cable, and autoloader/drive are working.

 

I still think that the best advice is for a Retrospect user with this drive (working) to provide a set of "good" switch settings and an Apple System Profiler report.

 

As for whether settings appropriate for BRU would work for Retrospect, no, that doesn't follow. For example, BRU can't use our autoloader (Exabyte) in random-access mode, and you have to configure the autoloader differently (so that tape member changing is handled by the autoloader, transparent to the backup software) for BRU than for Retrospect.

 

Surely, if Retrospect supported this drive at one time, there must be a record of the settings that worked. It's also possible that some RDU change has introduced an incompatibility for this drive (it happened recently for the Exabyte VXA-320).

 

Another possibility is if the reported library version string is odd (you briefly mention this in one of your early posts), causing Retrospect's driver to miss that it needs to go into "heavy hack" workaround mode for this library.

 

You might try searching the RDU version history in the KnowledgeBase to find when this drive/autoloader began being supported, and try regressing to one of those RDU versions. But I still think that the best approach is to get a report from someone who has this drive, working with Retrospect, so that you can compare notes. The RDU version history is here (with links to downloads):

RDU version history

 

Or, what the heck, man, you might give the current beta version of Retrospect (for use with the Universal Binary client) a shot. It works (at least for us) with the older clients, too, and does have a few fixes not specifically for the UB client. Note that some people are having issues, but at least you could see whether it recognizes your drive/autoloader combination, even if you don't do backups.

 

Russ

[rhwalker]

Ed,

 

I have one more comment/suggestion. It's not clear to me where you have the various switches because a lot of things have changed, but I believe I understand from your sequence of posts that you've got (and I must say, the HP documentation is an amazing piece of obscurity):

 

SCSI ID: (selector switch next to the SCSI cables): 0

 

"Options" Switch: (selector switch remote from SCSI cables): 7 (default)

 

"Unix configuration" DIP switches: all on except for switch 3, which is off (default)

 

Here is my comment: One other thing changed when you moved the drive/HBA/cable to the Windows system - you powered the drive off then on and booted the computer. Many devices only read configuration switches at power on (POST). All (that I am aware of) operating systems read configuration at boot, not every pass through the drivers.

 

After you set your switches, etc., to the defaults (see above), did you power off the drive, power on the drive, and reboot the Mac computer? Perhaps the drive and OS didn't get a chance to see all of your switch changes.

 

Just a desperate thought. Grabbing at straws here. You really need to exchange notes with someone who has this drive working with Retrospect.

 

Russ

[EWTHeckman]

After you set your switches, etc., to the defaults (see above), did you power off the drive, power on the drive, and reboot the Mac computer? Perhaps the drive and OS didn't get a chance to see all of your switch changes.

 

Yes I did. I wish it was that simple. I always shut off both the computer and drive before I made any changes.

 

[EWTHeckman]

Are there any SCSI probe utilities available? It might be useful if I could send specific commands to the drive—for instance, SCSI REPORT LUNS—and see how the drive responds.

[rhwalker]

The only utilities of which I am aware (other than writing your own) would be the ATTO Configuration Tool (available for OS X), which should show LUNs, and the HP tool for this drive (available for Windows only).

 

You might be able to use an interpretive language like Python (installed by default with Mac OS X Tiger and Leopard) to do this, but I've never used Python to poke at devices (I used to just write some lines of code). The Python documentation is here:

Python docs

and there is some special Python on Mac documentation here:

Python on Mac docs

 

It would require using the Apple docs to figure out how to talk to the SCSI manager, etc.

Apple man pages

 

Good luck.

 

Russ

[EWTHeckman]

In my continued attempts to understand this problem, I've gone diving into SCSI command codes and the driver log available through the ATTO driver. Here's what I found.

 

The SCSI command code 0xA0 is the command REPORT LUNS. In other words, this is the command asking the drive to tell the OS what logical units are available.

 

Here's what the ATTO log tells me:

(Note: commands sent to other SCSI ID's removed for clarity.)

 

Channel 7.4.0: SCSI Error, Status 0x02, Sense Key 0x06, ASC 0x29, Command 0x00, Target ID 0x05, LUN 0x00 

Channel 7.4.0: Request Error - Data Overrun, Command 0xA0, LBA 0x00000000, Target ID 0x05, LUN 0x00

Channel 7.4.0: SCSI Error, Status 0x02, Sense Key 0x02, ASC 0x3A, Command 0x00, Target ID 0x05, LUN 0x00 
Channel 7.4.0: SCSI Error, Status 0x02, Sense Key 0x02, ASC 0x3A, Command 0x00, Target ID 0x05, LUN 0x00 
Channel 7.4.1: Request Error - Selection Timeout, Command 0x12, LBA 0x00006400, Target ID 0x05, LUN 0x00 
Channel 7.4.1: Request Error - Selection Timeout, Command 0x00, LBA 0x00000000, Target ID 0x05, LUN 0x00 

The line I've marked is the request for a listing of LUNs for the drive. As you can see, the line is reporting an error. Furthermore, once the error occurs, there is apparently no attempt made to scan for available LUNs.

 

This would explain why my Mac can't see the loader. So…

 

What does the Data Overrun error mean? Is the drive returning too much data? Or does it mean that it doesn't recognize the command and is spewing gibberish?

 

Is there anything I can do about this? (I am considering opening the drive and manually setting the SCSI ID for the loader using jumpers.)

[Mayoff]

As I said in my last post:

Our engineers reviewed the log and basically are saying:

I think the loader is broken,

 

Contact HP to see if they can diagnose the problem and decide if a repair is needed.

[EWTHeckman]

Not to seem ungrateful for your efforts (I am grateful!), but that reply simply is not helpful. Consider these facts:

 

1 - I've tested this drive on Windows XP where it appears to work perfectly. (Just to be sure, I've redone the test, installed HP's tape tools and had it check out the drive. It passed all their tests.) Therefore, the only time this drive fails is when connected to a Mac.

 

2 - The last time I called HP's tech support to ask about their firmware history, they tried hard to blow me off because they "don't support Macintosh." In fact, I had to state numerous times that I was not asking them to support the Mac, I was asking if they had followed through on a change to the firmware mentioned in their own tech notes. They're practically hostile to the Mac.

 

3 - This call would then be about an apparent incompatibility between their drive and the Mac.

 

I suspect I would have just as much success asking them to do the dance of the seven veils, though derisive laughter would be slightly more interesting than a flat "We don't support Macintosh."

 

The problem is with the error in response to the REPORT LUNS command and the lack of a followup by the Mac OS. That much is clear.

 

The question now is, can anything be done about it? I don't have much hope for this. (It's not possible to set the loader's SCSI ID to something different via jumpers.)

 

Also, which firmware revision was this drive tested with?

 

It appears that this drive with the latest firmware actually needs to be marked as incompatible with Retrospect on the Mac. It's fine when doing bulk backups, but since it cannot control the loader, it's not much more than an expensive single drive.

 

Does anyone have any suggestions for a DDS4 autoloader that works with the Mac and can be found for a reasonable price? I'd love to move to an AIT5 drive, but that's just not in my budget for the time being.

[EWTHeckman]

One more quick update. I just checked the firmware version using HP's Tape Tools. The current firmware (H312) was apparently released on 2/10/2004. That predates their tech notes which state that the REPORT LUNS command was not implemented and would be in a future version.

 

In short, this firmware is far older than I thought. The REPORT LUNS command is apparently NOT implemented. Mac OS X is apparently NOT checking for individual LUNS when the command fails. Since it has been more than 4 years since the last update, HP is apparently NOT going to ever update the firmware for this drive.

[rhwalker]

Ed, here are my comments.

 

Congratulations on thorough troubleshooting. Looks like you have isolated the problem.

 

It looks like the drive/autoloader should NOT be listed in Retrospect's database as compatible. That surprises me if the Windows version supports it, but that seems to be the way it is unless Retrospect's RDU can be encouraged to have a workaround for this specific drive that will cause the SCSI Manager to send the proper commands to this drive.

 

I understand that you would prefer a DDS4 autoloader or AIT5. Consider, if you might be switching media types, the Exabyte (now Tandberg) drives with autoloaders. They are very reasonably priced from online resellers (PC Connection, etc.). We have the VXA-2 1x10 1u PacketLoader (SCSI) drive/autoloader with Ethernet admin interface, and it has worked well on the ATTO UL4D in our Xserve G5.

 

Exabyte has a similar (but newer) product with a VXA-172 drive (same autoloader) (same capacity as the VXA-2) or a VXA-320 drive (same autoloader, double capacity as VXA-2), and the VXA-172 is field-upgradable by a firmware patch (license) to the VXA-320. I would suggest the SCSI version rather than the FireWire version. PC Connection has the following prices today:

VXA-2 1x10 1u PacketLoader SCSI (w/o Ethernet admin): $1215.90 (USD)

VXA-2 1x10 1u PacketLoader SCSI Plus (w/ Ethernet admin): $1276.90 (USD)

VXA-172 1x10 1u PacketLoader SCSI (w/o Ethernet admin): $1453.32 (USD)

VXA-320 1x10 1u PacketLoader SCSI Plus (w/ Ethernet admin): $1611.32 (USD)

 

All of them have barcode readers included for the tapes.

 

The VXA-2 can be field upgraded to a VXA-320, but it takes a drive swap. The upgrade kit is almost as much as the VXA-2 with autoloader.

 

Russ

[jetdog9]

It may be worth it to plug the thing into Windows, install HP's Tape Library tools (should be on their website), and see if there is a newer firmware if you believe firmware is the issue here. Aside from that, as the technology is a bit old, it may be worth looking into other hardware options as well.