apoloniojr Posted September 24, 2009 Report Share Posted September 24, 2009 I am using Retrospect Backup 6.1.230 on a Powermac G4 with OS 10.4.11. It is a PowerPC with 400 MHz and 2GB SDRAM. Retrospect seems to freeze. It seems to have a hard time recognizing the tape drive which uses AIT tapes. When I try to run a script, it will scan for files and folders and then freeze on execution. I will just get a spinning wheel. I've previously had Retrospect Workgroup 5 and it ran fine on OS 10.2. However, this would crash on 10.4.11. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted September 25, 2009 Report Share Posted September 25, 2009 400MHz seems underpowered. Does Retrospect use 100% CPU when this happens? How is the AIT drive connected? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 25, 2009 Report Share Posted September 25, 2009 What tape drive do you have (so we can check to see if it is supported)? How is the tape drive connected to your G4? SCSI, FireWire? USB? If SCSI, what SCSI card (HBA) do you have? If USB, is this USB 1.1 or 2.0? What Retrospect Driver Update ("RDU") do you have installed? (See the Retrospect log, which prints the RDU and Retrospect versions on launch). Some more details are needed. Russ Quote Link to comment Share on other sites More sharing options...
apoloniojr Posted September 25, 2009 Author Report Share Posted September 25, 2009 The tape drive is connected via firewire. How can I tell if Retrospect uses 100% CPU? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 25, 2009 Report Share Posted September 25, 2009 The tape drive is connected via firewire. Once again, What tape drive do you have (so we can check to see if it is supported)? Also, are there other devices on that same FireWire chain? How can I tell if Retrospect uses 100% CPU? In terminal, observe the %CPU column for the command: top Russ Quote Link to comment Share on other sites More sharing options...
apoloniojr Posted September 25, 2009 Author Report Share Posted September 25, 2009 The tape drive is a LaCie d2 AIT1. It's connection i by FireWire (6-to-6 pin). I just downloaded and installed the latest driver from the Dantz website which was 6.1.16.1. I am still experiencing the same problem with this driver. The tape drive is connected to the G4. I am trying to backup an external hard drive which is connected by a Belkin FireWire 6-Port Hub. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 25, 2009 Report Share Posted September 25, 2009 I just downloaded and installed the latest driver from the Dantz website which was 6.1.16.1. I am still experiencing the same problem with this driver. Current version is 6.1.16.100, not 6.1.16.1 - you might want to check what you have. Retrospect 6.1 Macintosh RDU version history The tape drive is a LaCie d2 AIT1. It's connection i by FireWire (6-to-6 pin). The tape drive is connected to the G4. I am trying to backup an external hard drive which is connected by a Belkin FireWire 6-Port Hub. Is the FireWire tape drive on the same FireWire port of the G4 as the Belkin FireWire Hub that is connected to the external disk drive? That could be the problem. Try putting the tape drive on its own FireWire port of the G4. Russ Quote Link to comment Share on other sites More sharing options...
apoloniojr Posted September 25, 2009 Author Report Share Posted September 25, 2009 Terminal shows Retrospect using 0% to .1%. Quote Link to comment Share on other sites More sharing options...
apoloniojr Posted September 25, 2009 Author Report Share Posted September 25, 2009 Sorry, I meant 6.1.16.100. That is also what shows up in the log. Quote Link to comment Share on other sites More sharing options...
apoloniojr Posted September 25, 2009 Author Report Share Posted September 25, 2009 The G4 has 2 FireWire ports. One port is used by the LaCie tape drive. The second one is for the Belkin Hub. I have 2 external hard drives hooked up to the Hub. Originally, I had a hard drive connected to the G4 port and the tape drive connected to the hub. This didn't work and I switched to the present configuration which isn't working either. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 25, 2009 Report Share Posted September 25, 2009 Ok. (1) What happens if you take the Belkin hub out of the loop, and just have the one external FireWire drive that you are trying to back up? (2) Does the same thing happen when you try to back up the G4's internal drive? (3) Does the same thing happen when you try to back up the other FireWire drive? (4) Belkin makes several 6 port hubs, and they can either operate as powered hubs or unpowered hubs. Is this hub powered by the Belkin power supply? Russ Quote Link to comment Share on other sites More sharing options...
apoloniojr Posted September 25, 2009 Author Report Share Posted September 25, 2009 Thank you by the way for all your input. The hub is powered by the Belking power supply. I will have to try your 3 options later today and see what happens. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted September 25, 2009 Report Share Posted September 25, 2009 Ok. It's still a bit unclear what manufacturer/model of a tape drive you have. The tape drive is a LaCie d2 AIT1. LaCie doesn't make tape drives - they just buy them and put them in an enclosure. What type of tape drive does Retrospect believe you have? Configure > Devices, select the drive, Device Status Also, what does Apple System Profiler report for the drive? Both Retrospect and Apple System Profiler use information provided when they interrogate the device. It may be instructive for you to run diagnostics from the AIT drive's manufacturer on the drive. Sony makes diagnostics that run on Mac OS, perhaps your drive manufacturer has diagnostics that could be run. It's unclear whether your G4's two FireWire ports are on the same FireWire bus / controller chip. You might want to investigate. You haven't provided information about exactly what Macintosh model you have, only that you have a 400 MHz G4. You can gain insight by looking at the report generated by Apple System Profiler, which shows the device tree built at boot time. Here's why I have been asking the questions about what devices were on the same FireWire chain, and why I suggest that you keep investigating in this direction. We saw a similar hang by Retrospect 6.1 (6.1.126, RDU 6.1.4.103, Mac OS X Server 10.4.4 and 10.4.5) back in early 2006 on our xServe G5. We have an Exabyte VXA-2 1x10 1u PacketLoader (SCSI) attached to an ATTO UL4D SCSI HBA. About once every week or two, Retrospect would hang the system when it did its device scan just prior to the first write to tape. Same point you are seeing the hang. We also had a SCSI drive, one member of a RAID 1 for our boot volume, on the same SCSI channel as our tape drive and autoloader. Upon further investigation, working with Retrospect support, it turned out that the system was still live, and could be accessed through the serial console port or an Apple Remote Desktop connection (the server is headless) providing that the login was already established so that no disk activity needed to occur. What I believe is that something that Retrospect 6 does during its device scan was causing a SCSI bus reset to occur, which would cause a pending disk interrupt to be cleared, causing a disk transfer completion interrupt to never be seen, causing deadlock for the virtual memory paging store on the boot volume. Retrospect doesn't talk directly to the SCSI card, but uses Apple's SCSI manager. The only solution that worked was to move the tape drive and autoloader to their own SCSI channel, isolated from the disk drives, so that whatever was happening on the tape drive's SCSI channel wouldn't affect the disk drives. Once we recabled things, the problem never appeared again. So, I suspect that you might be seeing something similar, which is the reason that I have been pushing your investigations in the direction I have. It wasn't 100% repeatable, which is what made our troubleshooting so difficult. But you may be seeing the problem more frequently because the window of opportunity on a slower 400 MHz machine is much larger, during which the particular set of events can occur. Hope this insight helps and can give you a clue as you troubleshoot this issue. Russ Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.