Jump to content
mtriplett1

Lost Connnection from 6.1.230 with LTO3 HH

Recommended Posts

Worked fine for months and suddenly, it can't see the tape drive.

 

I was in the midst of a lenghty restore when this happened.

 

I'm using an ATTO UL5D

Retro Driver Ver6.1.15.101

 

and here's the report from the Apple profiler

_____

SCSI Parallel Domain 0:

 

Initiator Identifier: 7

 

SCSI Target Device @ 0:

 

Manufacturer: TANDBERG

Model: TS800

Revision: 0412

SCSI Target Identifier: 0

SCSI Device Features: Wide, Sync, DT

SCSI Initiator/Target Features: Wide, Sync, DT

Peripheral Device Type: 1

 

SCSI Logical Unit @ 0:

 

Manufacturer: TANDBERG

Model: TS800

Revision: 0412

SCSI Logical Unit Identifier: 0

 

Share this post


Link to post
Share on other sites

I'm not sure how the LTO3 autoloader and drive are supposed to show up (one SCSI ID or two). Our Tandberg (f/k/a/ Exabyte) VXA-2 1x10 1u PacketLoader (SCSI) attached to an ATTO UL4D on our Xserve shows up as two SCSI IDs - 0 and 1, one for the drive and one for the autoloader. However, your "peripheral device type 1" entry seems to match the entry for our drive (autoloader is type 8).

 

Is what you are seeing what you expect in Apple System Profiler? To ask the obvious, have you tried a reboot? What does the ATTO utility show is attached to the card?

 

Here's the relevant stuff we see in Apple System Profiler for our drive on one channel of our Xserve's UL4D:

 

ATTO ExpressPCI UL4D:

     Name: ATTO,ExpressPCIProUL4D
     Type: scsi-2
     Bus: PCI
     Slot: SLOT-3
     Vendor ID: 0x117c
     Device ID: 0x0030
     Subsystem Vendor ID: 0x117c
     Subsystem ID: 0x8013
     ROM Revision: 1.5.2
     Revision ID: 0x0008

   ATTO ExpressPCI UL4D:

     Name: ATTO,ExpressPCIProUL4D
     Type: scsi-2
     Bus: PCI
     Slot: SLOT-3
     Vendor ID: 0x117c
     Device ID: 0x0030
     Subsystem Vendor ID: 0x117c
     Subsystem ID: 0x8013
     ROM Revision: 1.5.2
     Revision ID: 0x0008

...

   SCSI Parallel Domain 2:

     Initiator Identifier: 7

       SCSI Target Device @ 0:

         Manufacturer: EXABYTE
         Model: VXA 1x10 1U
         Revision: A110
         SCSI Target Identifier: 0
         SCSI Device Features: Wide, Sync
         SCSI Initiator/Target Features: Wide, Sync
         Peripheral Device Type: 8

           SCSI Logical Unit @ 0:

             Manufacturer: EXABYTE
             Model: VXA 1x10 1U
             Revision: A110
             SCSI Logical Unit Identifier: 0

       SCSI Target Device @ 1:

         Manufacturer: EXABYTE
         Model: VXA-2
         Revision: 2143
         SCSI Target Identifier: 1
         SCSI Device Features: Wide, Sync
         SCSI Initiator/Target Features: Wide, Sync
         Peripheral Device Type: 1

           SCSI Logical Unit @ 0:

             Manufacturer: EXABYTE
             Model: VXA-2
             Revision: 2143
             SCSI Logical Unit Identifier: 0

 

Russ

 

 

Share this post


Link to post
Share on other sites

This has been a mystery for a week or so now.

 

I got Tandberg to send me a replacement unit and it's just as missing as the original. I located an old SCSI drive and it formats and runs just fine.

 

I've rebooted so many times, my finger is worn out.

 

The ATTO utility seems to have given some guidance though. It says "Unknown, Driver Not Loaded."

 

Any thoughts?

Share this post


Link to post
Share on other sites
The ATTO utility seems to have given some guidance though. It says "Unknown, Driver Not Loaded."

Well, actually, that part is normal (unless you are running a backup utility like BRU, which uses standard Unix drivers).

 

Retrospect has its own driver that loads when Retrospect is running.

 

See screen shots for our Exabyte (now Tandberg) VXA-2 and autoloader attached to one channel of our UL4D in our Xserve.

 

Again, I don't know how your LTO3 is supposed to present itself to Retrospect on the SCSI bus.

 

Is a Tandberg diagnostic able to access and control the drive? There is a "vxatool" command line diagnostic provided by Exabyte (Tandberg) on their web site for exercising the VXA drives. At a quick glance, I don't see a similar utility for the LTO3 HH, but there may be one:

Tandberg LTO3 HH downloads

 

What is showing in Retrospect's "Configure > Devices" window? Is it possible that somehow Retrospect has been instructed to ignore that SCSI ID? See the attached Screen Shot for what I see.

 

Perhaps it's something such as corrupt preferences for Retrospect, causing Retrospect to believe that it should ignore that SCSI ID. If so, try:

 

quit Retrospect,

move "/Library/Preferences/Retrospect/Retro.Config (6.0)" to the Desktop so that Retrospect won't find it,

launch Retrospect, enter the License Code, see if tape drive seen. If not, quit Retrospect, move config file back.

 

I don't have any other thoughts, assuming you have tested all of the usual suspects (SCSI terminator, cables, tried other channel of UL5D, etc.).

 

Russ

Share this post


Link to post
Share on other sites

First, thanks for all your help.

 

I've got the Tandberg/Exabyte LTO Tool for mac and it shows no tape drives on the system. Also after rechecking my ATTO tool, it looks pretty much like your VXA-2.

 

The prefs thing was about the first thing I tried.

 

Retrospect used to show the LTO, but now it just shows "SCSI-A:0:0

 

I've got plenty of drives and I think the next thing I'm looking at is a clean install of Leopard and then Retrospect.

 

I did a upgrade from Tiger and all went very well and even Retrospect made the transition as well.

 

So if that works, it's possible that there's something corrupt and I'll have to do a reinstall on my main drive.

 

Thanks again.

Share this post


Link to post
Share on other sites
I've got the Tandberg/Exabyte LTO Tool for mac and it shows no tape drives on the system.

Well, that pretty much rules out a Retrospect problem. If Tandberg's own diagnostic can't see the drive, there is no hope for Retrospect to see it.

 

Your planned reinstall, etc., sounds a bit drastic, because it's still unclear to me whether you have a software issue or a hardware issue.

 

Don't know about you, but I made a disaster recovery DVD boot disk from the MacOS install disk and Retrospect's install disk (make a sparseimage using Disk Utility of the MacOS install disk, do a Retrospect install onto that, update Retrospect and RDU, install ATTO drivers, etc., hack a bit with the files so that Retrospect appears in the Utility menu, etc.), burn DVD so I can boot from that.

 

Or, before you blow away your boot volume with a new install, you might try attaching a firewire drive and doing a small install on that with Retrospect, just to let you know whether it's a hardware issue or a software issue.

 

Good luck.

 

Russ

Share this post


Link to post
Share on other sites

Russ and others, I did a fresh install of Leopard on a spare drive, installed the UL5D drivers and Retrospect and now all is well.

 

Retrospect sees the tape and works fine.

 

The bottom line is that I probably have a corrupt driver for the ATTO card. I have a little detective work ahead, but I can boot off of the spare to do backups and restores as necessary.

 

Thanks again for your help.

Share this post


Link to post
Share on other sites
The bottom line is that I probably have a corrupt driver for the ATTO card.

Interesting, but it is consistent with the fact that the Tandberg/Exabyte ltotool couldn't see the drive.

 

It's also possible that something odd was happening during boot when the device tree was being built, which could point to one of Apple's drivers or plists, or a plist for ATTO's driver.

 

Russ

Share this post


Link to post
Share on other sites

One other thing to consider as the root cause of the mystery, if it does turn out to be a corrupt file/driver, etc.:

 

It seems clear that you have an Intel Mac because you have a UL5D (PCIe, not present on PPC Macs).

 

Because of that, you can't be having the exact same problem that I found on our G5 Xserve during shakeout prior to production deployment, but I'll pass it along anyway for your reflection.

 

You don't mention your underlying disk subsystem technology. Some disk HBAs have a firmware bug that causes the disks to become disconnected from the HBA to disk bus before the write caches on the HBA are fully flushed during graceful shutdown. Causes mystery garbage blocks from space in unpredictable locations, which are especially hard to troubleshoot on huge disks and/or RAID 5 arrays. The Apple Hardware RAID card (PCI) (really, an Apple-rebranded LSI Logic MEGARAID card) for the Xserve G5 has this bug in its firmware, and it was never fixed (RADAR Bug ID 4350243 - Apple Hardware RAID card fails to fully flush write cache on graceful shutdown). LSI Logic fixed the bug in their firmware long ago, but Apple never fixed the bug after they split off of LSI Logic's code branch for the card, and LSI Logic's firmware isn't usable on the Apple card in an Xserve. Only workaround is to turn off the write caches on the card.

 

The Intel Xserve has a different card (daughterboard that replaces the disk connector card) than on the Xserve G5, and I don't know if you are using the Hardware RAID card. But it's something for you to check. Just a warning, don't test on your production system. Takes lots of formatting, shutdown, Disk Utility filesystem checking, etc., to troubleshoot and diagnose, and the bad block has to land in the right place to cause issues that you can detect. Took me a long time to figure out what was happening and to develop a repeatable test case, and, even then, Apple never fixed the bug that I reported years ago under our support contract. Sigh.

 

Just a thought because, even if you get a working system again, you still don't know what caused the mystery problem.

 

Russ

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×