Jump to content

Retrospect hangs when scanning the SCSI bus


Recommended Posts

Quicksilver G4/933GHz running 6.1 Server with driver update 6.1.5.102. Using an Atto ExpressPCI UL3D card, with latest drivers and firmware connecting an Exabyte EZ-17 autoloader. Card and drive were just transferred over from an OS9 machine running Retrospect Server 5 without issues.

 

When I go to Configure> Device Retrospect sees the SCSI bus (I see it identifying it in the progress window), but then hangs at the window asking Scanning Drives, Scanning inventory. The SCSI termination is on and in the same configuration as it was before, so I wouldn't suspect that as the cause.

Link to comment
Share on other sites

I think you've got the EXACT same problem that I diagnosed with the help of Dantz support earlier this year. With us, our Xserve G5 would hang at the instant Retrospect scanned the SCSI bus for devices on our ATTO UL4D ("Scanning... Checking SCSI A 0:0"). The problem (in my opinion) turned out to be the presence of another device (LVD SCSI drive, very active, that was a RAID 1 mirror of our OS volume) on the same ATTO UL4D SCSI channel as our Exabyte VXA-2 1x10 1u PacketLoader (LVD SCSI interface), and I believe that Retrospect causes some sort of a SCSI bus init or something as a part of its device scan that caused a pending response for the SCSI disk on the same channel to be dropped, causing the driver for the disk to spin wait at high priority. We have high quality LVD cables with ferrites and high quality LVD terminators, etc. Happened occasionally with Mac OS X Server 10.4.3 and 10.4.4, happened very frequently with Mac OS X Server 10.4.5 (I think the change in frequency was caused by some unrelated timing change in the low-level drivers); all versions of Retrospect Workgroup 6.1 through 6.1.126, no RDU and all RDU through RDU 6.1.4.103; SoftRAID 3.2 and 3.3; all versions of Exabyte firmware through current.

 

When our system went into this hang mode, always when Retrospect was doing its scan ("Scanning... Checking SCSI A 0:0"), we could ping the Xserve and get a ping response (low-level network is at a higher priority than disk) but all services were non-responsive, could not ssh in, could not ARD in, etc. Hung with all Xserve activity lights solid on, indicating some sort of spin-wait at a low level. Only way to recover was hard power down.

 

Only thing that was changed to fix the issue completely was to let Retrospect's tape drive and autoloader (the Exabyte) be on SCSI A (the first one scanned by Retrospect) with no other devices, put all other non-Retrospect devices (i.e., disks) on SCSI B of the ATTO UL4D. Never a hang since when Retrospect does its device scan. As a further precaution (but I believe, not needed), we told Retrospect to ignore the Superdrive DVD - we only back up to tape on the Exabyte. Why don't you give it a try to take everything off the SCSI chain with your tape drive?

 

Admittedly, our hardware is a little different (we have headless Xserve G5, single 2.0 GHz processor, 2 GB RAM, and ATTO UL4D), but it sounds like EXACTLY the same problem as yours. It's encouraging that someone else besides us has this problem; maybe the programmers can be prodded to stare at their code for the device scan.

 

If you need more config info, I'll provide.

 

Russ

Link to comment
Share on other sites

The behavior sounds similar-unfortunately we have only one device on the bus. We're running a dedicated Retrospect server so there's nothing else SCSI in it (and the OS is 10.3.9 Client). The frustrating part is that it works just fine with 5.0xxx in our old machine under OS9. We may elect to switch our backup device soon anyway, but it seems like if it was working once it shouldn't break after. I'll try reflashing the Atto card (though when nothing is connected to the card it scans past it just fine).

Link to comment
Share on other sites

  • 1 month later...

I'm having the a similar problem on an Xserve 1Ghz running 10.3.9 with Retrospect 6.1.129 using an Exabyte 1x7 VXA-2 drive. If there is a tape in the drive, when you go to Devices or Script starts, Retrospect hangs at Scanning Inventory....

 

Have tried a different 1x7 and terminator with no help.

 

Any suggestions?

Link to comment
Share on other sites

See my post above. What SCSI card do you have? If ATTO, do you have the latest driver and firmware?

Quote:

Any suggestions?

 


Again, see my post above because this sounds EXACTLY like our issue, which was solved when the Retrospect tape drives and autoloader were put on their own SCSI chain, away from the volume used by SoftRAID's OS mirror volume. I'm convinced that the problem was that Retrospect's device scan somehow caused loss of a disk transaction, perhaps by a bus init. We had (and have) top quality cables and LVD terminators. Tried many things, but moving Retrospect's tape drives and autoloader to their own SCSI chain on the ATTO UL4D solved it. We were seeing this a couple of times a week before, but not a single recurrence in three months since the change.

 

Russ

Link to comment
Share on other sites

Quote:

If there is a tape in the drive, when you go to Devices or Script starts, Retrospect hangs at Scanning Inventory....

 


Eric, when you say "Retrospect hangs" - are other services available? (i.e., can you still log in via ARD or ssh over the network?) Is tape motion happening (rewinding?) that will eventually complete? You still don't say what SCSI card you have and whether its firmware is up-to-date. Some SCSI cards are not supported in 10.4.x (but you indicate you've got 10.3.9) because Adaptec has exited the Mac market.

 

Russ

Link to comment
Share on other sites

Quote:

The SCSI card is a Atto UL3S. When Retrospect hangs at "Scanning Inventory...", the rest of the Xserve is responsive. There is no drive activity when Retrospect hangs. They have left Retrospect hung all night without a change.

 


Ok, you've got something different than we had. There was an earlier, different hang when we were evaluating the SoftRAID 3.x driver, and the demo version of SoftRAID would hang with Retrospect, but the actual product was OK. Have you recently installed SoftRAID's demo?

 

Otherwise, I'm clueless.

 

Russ

Link to comment
Share on other sites

hi eric,

 

if you get a chance, try moving the SCSI card to another slot (if you have one). also check the card if you can't move it, and try pulling it out and reseating. trying another SCSI cable is a good idea also.

 

check the card with ATTO's command line utility also if you have not done that yet.

Link to comment
Share on other sites

The G4 XServe PCI slots are not all the same and ATTO SCSI cards seem to really notice the difference. Typically, there is one PCI riser with 2 slots - one for the video card and a second PCI slot. Then there is a PCI riser with a solo slot - typically with an ethernet adapter. The ATTO SCSI cards are not happy in the Solo port PCI riser. Try to keep ATTO SCSI cards on the same riser as the video card.

Link to comment
Share on other sites

I'm not as technically knowledgable as some of the previous posters, but I identified a similar problem and told the Retrospect team about it 2 years ago when I was frustrated with the early v6-6.5 release. I assume they haven't taken it onboard as not a lot seems to change in the 'buggy area'

 

OK, so what I found is that when Retrospect does the scan it reads back the device ID's. Some devices like my oem card reader would get scanned, but the device ID field or response may not have conformed or been correct so Retrospect just sits there waiting, not intelligently timing out then carrying on down the table. I've never had this with IDE drives, but I think card or media readers emulate the exchanges across the interface and their device ID strings do not get given when asked for in the Retrospect scan.

 

The solution I found was to use an option I found buried somewhere in the Retrospect menu to 'Exclude' or 'Skip' devices or addresses from the scan, other than the device used for backup. I remember marking all the sequential device location addresses, leaving only the backup drive. No problems now. Don't know if this helps

Link to comment
Share on other sites

Quote:

but I identified a similar problem and told the Retrospect team about it 2 years ago when I was frustrated with the early v6-6.5 release. I assume they haven't taken it onboard as not a lot seems to change in the 'buggy area'

 


The Retrospect team HAS made major strides in addressing this. I worked with SoftRAID people on some of these issues, and they confirmed that Retrospect changed its strategy of walking the device chain. Your results from 2 years ago are not applicable. The product is not perfect, but I, for one, do see the issues being addressed, and the support has been excellent in working to isolate/identify the problem and provide workarounds until a true fix is available. Just one user's experience.

 

Russ

Link to comment
Share on other sites

hi everybody,

 

just a note regarding Voxmanga's post:

 

Retrospect 6.5 is a Windows product. since the Windows and Macintosh versions do not share the same codebase the issue is not relevant to this discussion.

 

that said, you can certainly set devices to be 'ignored' in either version. it can be a big help in troubleshooting.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...