Jump to content

EWTHeckman

Members
  • Posts

    86
  • Joined

  • Last visited

Everything posted by EWTHeckman

  1. I just discovered that Sony has issued a recall on some of their AIT-5 tapes. (That was 2 years ago! So much for paying attention…) Two of those tapes are part of my long term archive from Retrospect 6 which I kept after upgrading to Retrospect 8. Is there any way to copy the contents of these tapes to new tapes?
  2. They're currently using a Windows machine as the Retrospect server. They might be able to use an Xserve as the Retrospect server if necessary.
  3. I've been looking at the costs for backup media. It looks like hard drives have finally reached the magic breakeven point with tape. So now I'm looking at recommending that a client uses hard drives in a point multiplier case for backup instead of tape. But I just want to confirm that this should work. I've found the part in the documentation where "Media Handling Preferences" includes the option to "Use FireWire/USB hard drives as removable disks". I haven't seen it explicitly stated anywhere, but it does seem to be implied that this option also applies to eSATA drives. Is this actually the case? In case it matters: I'm looking at drives in a FirmTek PM5 enclosure attached to a RocketRaid 2522 or 2314MP card. (The enclosure and cards use the Port Multiplier feature to connect multiple drives via a single cable.)
  4. It looks like you've been burned by the same issue which burned me. (See here for the problem I ran into with my new HP StorageWorks drive.) According to the SCSI documentation for your drive, both the drive mechanism and the loader mechanism share the same SCSI ID, but each uses a different LUN (Logical Unit Number) to distinguish the two devices. In my case, and apparently in your case due to its absence from the list of supported commands in the documentation, the library does not support the command REPORT LUNS. Even worse, recent versions of Mac OS X do not go to plan B when this command fails. (Plan B is scanning for LUNS manually.) In short, Mac OS X is apparently broken on this issue, has been for some time, and there's nothing we can do about it with current software. Would it be more effective for EMC to let Apple know about this problem, or us? I suspect EMC would carry more credibility with Apple. Would it be possible to have Retrospect add this manual scan (TEST UNIT READY for each LUN) in a future RDU update?
  5. 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.
  6. 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.
  7. 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.)
  8. As part of my digging yesterday, I came across something (I can't lay my hands on it right now) that implied that the Mac OS may not like the fact that both the loader and the drive mechanism share the same SCSI ID, even though they have different LUN IDs. Since HP probably used this arrangement for other libraries, I would also like to here from someone successfully using ANY HP library on the Mac. How does your library show up in System Profile?
  9. 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.
  10. Over in the Autoloader functions not enabled thread, I have been working on troubleshooting my new HP StorageWorks 40x6 drive. If you have one of these drives and you are successfully using it with Retrospect on your Mac, please go over there and post the switch settings for your drive along with the SCSI card and OS version you are using. Thank you! (Note: I created this separate thread so that my cry for help could be seen without having to dig into the original thread.)
  11. Yes I did. I wish it was that simple. I always shut off both the computer and drive before I made any changes.
  12. 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.
  13. 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?
  14. I installed 10.4.3 on an external drive. (Oddly enough, the 10.4.11 updater refused to update older versions of 10.4 on ANY external drive attached to my machine.) The drive is still showing up only as a single device. It really does seem like HP modified the firmware so it would refuse to work with a Mac. BTW… I did some digging in the Apple Developer area. It seems that Mac OS X does use the SCSI REPORT LUNS command, but if that fails, it attempts a manual scan.
  15. More info: I found that there is another backup software package named BRU which also supports autoloaders. The publisher of that package explicitly states that they do not support Mac OS 10.4.9 (the version I was on) and 10.4.10 due to bugs in the SCSI implementation. That lead to two more troubleshooting ideas: 1 - Upgrade to 10.4.11. This did not solve the issue. The loader still did not appear. 2 - Try an evaluation version of BRU to see if it could see the loader. Again. No joy. The only thing left to try at this point (short of contacting EMI tech support which I can't do 'till Monday) was to move the ATTO card and the HP drive to my Windows XP machine. After installing the ATTO drivers and the configuration tool, the drive AND THE LOADER immediately appeared. This now proves that the drive is working fine, as is the ATTO card and cable. That leaves only the Mac OS or the functional equivalent of "You're a Mac? I'm not talking to you!" in HP's firmware. (Given their apparent antipathy towards the Mac platform, this doesn't seem so farfetched!) I guess my next step is to try a clean install of Mac OS X on a spare drive and see what happens.
  16. More info: Last night I learned that the "Autoloader Option" switch does not set a SCSI ID. It controls the responses given to the host computer. I've now set it back to 7 which is supposed to work with most computers. 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. Could this be the cause? If Mac OS X uses the SCSI REPORT LUNS command and it was never implemented on this drive, then that would be why my machine can't see the loader. Is there a way to have Mac OS X scan for available LUNS?
  17. I just tried the other two DIP switch settings listed in the manual. They didn't make a difference either.
  18. I did see the information in the manual. I can see the drive based on whatever SCSI ID it's set to. (Currently on 4, I've also tried 3, 5, and others.) The Option switch has been tried at the default of 7, which is not supposed to work because that's the ID used by the ATTO card, 1 and currently 0 by recommendation of ATTO tech support. The configuration switches on the bottom are set to their defaults. I really hate HP's documentation at this point because they base the switch recommendations on the OS and version, don't mention Mac and don't specify what each switch is for. I am wondering if one of these switch settings needs to be changed.
  19. It's a single unit. (You can see HP's info on it here.) There are two SCSI ID selector switches on the back, one labeled "SCSI Address" and one labeled "Autoloader Options". The autoloader options switch seems to be the SCSI ID for the loader portion of the unit, the equivalent of the Type 8 device that shows up on your system. That makes sense. I've also been talking with ATTO to see if their card utilities can give any insight into why it's not showing up. Their last communications said that something had to be at ID 0 to be recognized. So now I have the loader ID at 0 and the SCSI address at 4. I'm still seeing only the drive (ID 4) in System Profiler and Retrospect.
  20. Unfortunately, I don't have access to another machine with a SCSI card.
  21. Okay, here are my screen shots of the devices and device status windows.
  22. I was wondering if the license code had gotten messed up somehow. According to my receipt, it is supposed to be Retrospect Workgroup. The link you posted shows that Workgroup comes with 20 client licenses while Desktop comes with only 2. When I checked the license within Retrospect it showed 20 clients permitted, so I guess that does confirm that the license is a valid Workgroup license.
  23. Okay, I'll upload it as soon as I'm able to. I can say that I don't see the loader as a distinct device in either the Configure -> Device window or in the Status window. As far as I can tell. I've already done some experimenting with the SCSI ID's with no success. There is a set of jumper switches on the bottom of the drive. They're currently set to the default settings. The HP documentation only specifies which switch combination to use for particular OS's. But it doesn't list the Mac OS or what each switch means. So I've just made sure they're the default settings and left them alone. The drive is the only device attached to the SCSI card. It is terminated. There isn't anything funky about the ports on the back, just the standard 2 SCSI ports to allow daisy chaining. I've been doing some digging around on the HP forum. According to what I've read there, the loader is supposed to appear as LUN 1. The ATTO configuration tool shows that the setting for the SCSI Bus is supposed to allow LUNs 0 to 7. Thanks. That will make it easier.
  24. I'm currently running a long backup (using the drive in stacker mode), so I can only describe it at the moment. The window displays a list of two drives, my G5's internal DVD burner and the new tape drive. Clicking the reveal triangle for both drives shows the same thing, a single entry for what is in the drive, normally "Empty". If I insert a magazine in the tape drive, the display does not change. I have to select a tape then load it into the drive mechanism using the front panel before anything will show up in the slot. In short, it looks just like it did when I was using the Sony SDT-11000 single tape drive. Is this sufficient or will you still need a screen shot after the backup finishes? Does this board have a simple function for posting screen shots? Or do I need to upload it to my web site and post a link here?
×
×
  • Create New...