jimchampagne Posted June 13, 2002 Report Share Posted June 13, 2002 having trouble getting Retro 4.3 working with my Mac G4/466 and my old DDS-3 tape drive that i purchased a few years back along with a mac 9600/200. the system freezes at start with the DDS-3 drive turned on, but if i switch it off the system continues though it's startup and boots up fine with the tape drive turned off. sometimes i can get it to work by booting the system then turning on the tape drive. any suggestions ??? i tried the 2.5 update with no luck. python DDS-3 Tape Drive Link to comment Share on other sites More sharing options...
AmyJ Posted June 13, 2002 Report Share Posted June 13, 2002 At this point, you are looking at a hardware issue, not a software issue. Retrospect does not access your tape drive or load any drivers on boot. Retrospect communicates with your tape drive only when the program is running and actively looking for devices. If you were to completely uninstall Retrospect, you will still have these issues on boot. That being said, you should try standard SCSI troubleshooting to find the root cause of your issue. SCSI devices must always be turned on before the computer. With a lock up on the backup computer you want to try moving the mouse to see if the hardware bus has locked up as well. If the mouse moves but the Mac is hung up it's most likely that your SCSI bus is hung and you have a SCSI problem. If the mouse doesn't move with a SCSI device that means that the Mac's processor is hung and you should look at System Software and extensions. More often than not you will find that the mouse moves and you can force quit the program (at which point the Mac may or may not completely crash). A SCSI hang or error can be caused by one or more of the following: 1) A dirty tape drive or bad tape. Clean the drive using a cleaning cartridge. Your drive manufacturer recommends that you clean the unit once for every 8-10 hours of run time. Once a week is more than enough for most people. Try another tape. If other tapes work then you just have a tape with a spot that's bad enough to crash your backup. 2) Another device on your SCSI bus is interfering with the tape drive's communication. Make sure your SCSI ID numbers are set correctly. Turn off your computer and the devices. Disconnect all SCSI devices except for the tape drive. 3) You have a bad cable. Replace the SCSI cable that connects the tape drive to the computer after removing other devices and cables from the SCSI chain. 4) You are missing a terminator (SCSI) or have a bad terminator. The last device and ONLY the last device in your SCSI chain needs to be terminated. Try replacing the terminator if you already have one on the chain. 5) The computer may be having a problem. Install Retrospect on another computer and try the tape drive there as the lone device on the SCSI chain. 6) The drive may be defective. If you have implemented all of the preceding steps and get failures on multiple tapes after changing cables terminators and computers then the drive (being the only factor that has not changed) is the culprit--send it back to your vendor for repairs. The steps above are essentially the outline of our device troubleshooting here at Dantz. Hands on testing of device issues is really still the best method and even getting device logging information is usually only to confirm empirical testing. Note that concluding something is a bad device is the LAST thing we assume after all other components and variables have been ruled out. "SCSI voodoo" as they call the nebulous symptoms that can plague a SCSI bus can often lead one to false assumptions of the cause of problems. It's important that once a variable is tested that it be tested more than once for consistency's sake to rule out dumb luck. For example SCSI voodoo accounts for why a tape drive may work fine for many months without proper termination but then suddenly fail in some way later. Although customers will often cite that nothing has changed with their SCSI bus configuration in months and that it was all working before this is really indicative of the inconsistency of SCSI voodoo. The quickest and most conclusive test for most devices is to test it on more than one computer as the only device on the bus and with a different SCSI cable. If the problems can be reproduced on multiple computers it's more than likely a hardware problem with the device itself. Of course there a myriad of other specific issues having to do with a device's own hardware settings like with internal jumper cables dip switches or internal termination that has to be sorted out with the device's manual and/or vendor or manufacturer of the drive, but the kernel of SCSI troubleshooting above is a good general guideline. Link to comment Share on other sites More sharing options...
jimchampagne Posted June 14, 2002 Author Report Share Posted June 14, 2002 i agreee that it is a hardware / SCSI problem. Starting up with the "Python 04106" drive on, Mouse moves while SCSI hangs on a blank gray screen. While system is on and stuck like this, i can turn off the Python and get the system resume it's startup. So, it must be a SCSI problem. The ATTO express control panel locks up the moment it hits the corresponding ID of the Python drive. For some reason It can't make it past this point, under any situation i've tried so far. The Python is on ATTO bus 1, ID#2 (externally). i also have a Cheetah on ID#0 (Internal). The Host Settings for ATTO bus 1 would apply to both the Cheetah on ID#0 and the Python ID#2. haven't been able to access the setting to Python ID for the ATTO control panel. ==================================== Drive name ARCHIVE Python 04106-XXX 7270 Archive Python DDS-DC (4.06) Manufacturer: Seagate/Archive SCSI Interface: Card Name: ATTO, ExpressPCIpro Card ROM#: DC 1.4.4f1 Card Version: 20 Card Vender ID: 1000 Media: DAT (DDS3) Operating System: Mac OS 9.2.2 system: Mac G4/466 Minimum Version: Retro: 4.0 Firmware: ??? ------------------------ Link to comment Share on other sites More sharing options...
AmyJ Posted June 17, 2002 Report Share Posted June 17, 2002 Thank you for the configuration information. If the troubleshooting steps previously outlined do not help you pinpoint the cause of the issue, you may want to contact your hardware vendor for more detailed troubleshooting. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.