Xserve and Retrospect Server 5.1.175 crashing

[downeast]

Ever time I try and run a normal backup with Retrospect on our Xserver it crashes. I have reinstalled retrospect, fixed permissions, ran a hardware ram check (to see if it had bad ram installed), ran disk utility, deleted and remade my catalogs and nothing seems to fix this problem. I have called Dantz tech support and they say its a SCSI problem because of how OSX deals with SCSI cards going from a 50 Pin interface to a 68 Pin interface on the Xserve and they blame Apple, I called Apple and they say there is no known issues with the SCSI cards in the Xserve and they blame Dantz. I just wish I could get my $5000 DLT drive to work with my Xserve, please help!

 

Retrospect Server version 5.1.175

Retrospect Driver Update, version 4.2.105

5.1 SCSI update applied

 

Hardware: Apple Xserve Dual 1.33 GHZ G4

Ram: 1024 MB

Hard Drives (3) 60 GB

OS: 10.2.8 (server)

SCSIcard: ATTO ExpressPCI PRO UL366 (default card, came with Xserve)

TAPE Drive: Quantum Super DLT1 (SDLT220)

Model# TR-S12BA-YF

 

This is a copy of my crash log... (same crash results each time) 50 + times now...

 

Date/Time: 2003-12-18 14:45:36 -0500

OS Version: 10.2.8 (Build 6R73)

Host: Xserve

 

Command: Retrospect

PID: 24600

 

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0381004c

 

Thread 0 Crashed:

#0 0x001be0ec in 0x1be0ec

#1 0x001be440 in 0x1be440

#2 0x001be674 in 0x1be674

#3 0x00202894 in 0x202894

#4 0x00205a20 in 0x205a20

#5 0x001d43e4 in 0x1d43e4

#6 0x00349604 in 0x349604

#7 0x00349ddc in 0x349ddc

#8 0x001d43e4 in 0x1d43e4

#9 0x0034e718 in 0x34e718

#10 0x001d43e4 in 0x1d43e4

#11 0x0034a4d0 in 0x34a4d0

#12 0x001fa034 in 0x1fa034

#13 0x001fa230 in 0x1fa230

#14 0x0034aaa8 in 0x34aaa8

#15 0x001d43e4 in 0x1d43e4

#16 0x00263460 in 0x263460

#17 0x00263db4 in 0x263db4

#18 0x001d43e4 in 0x1d43e4

#19 0x002451cc in 0x2451cc

#20 0x001a90b0 in 0x1a90b0

#21 0x001d43e4 in 0x1d43e4

#22 0x001b3f0c in 0x1b3f0c

#23 0x001b3f50 in 0x1b3f50

#24 0x001d43e4 in 0x1d43e4

#25 0x001d6ed4 in 0x1d6ed4

#26 0x001d43e4 in 0x1d43e4

#27 0x0022716c in 0x22716c

#28 0x001d43e4 in 0x1d43e4

#29 0x00228108 in 0x228108

#30 0x001c2240 in 0x1c2240

#31 0x001fa034 in 0x1fa034

#32 0x001fa230 in 0x1fa230

#33 0x001c2728 in 0x1c2728

#34 0x001cd9c4 in 0x1cd9c4

#35 0x001fa034 in 0x1fa034

#36 0x001fa230 in 0x1fa230

#37 0x001cdb10 in 0x1cdb10

#38 0x001fa034 in 0x1fa034

#39 0x001fa230 in 0x1fa230

#40 0x001cdc08 in 0x1cdc08

#41 0x001cdd64 in 0x1cdd64

 

Thread 1:

#0 0x9000508c in syscall

#1 0x90515d0c in BSD_waitevent

#2 0x905156dc in CarbonSelectThreadFunc

#3 0x90020c28 in _pthread_body

 

Thread 2:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x9051dbf0 in CarbonOperationThreadFunc

#3 0x90020c28 in _pthread_body

 

Thread 3:

#0 0x90073ba8 in mach_msg_trap

#1 0x90005ed0 in mach_msg

#2 0x901489f0 in __CFRunLoopRun

#3 0x90180f58 in CFRunLoopRunSpecific

#4 0x005a9594 in thTop (thread.c:99)

#5 0x90020c28 in _pthread_body

 

PPC Thread State:

srr0: 0x001be0ec srr1: 0x0200f030 vrsave: 0x00000000

xer: 0x00000000 lr: 0x001be1f8 ctr: 0x00000000 mq: 0x00000000

r0: 0xffff6000 r1: 0xbfffd470 r2: 0x004d9000 r3: 0xfffd8000

r4: 0x00000000 r5: 0x010aa3d8 r6: 0x0000a200 r7: 0xfffe51e9

r8: 0xffffffcf r9: 0xffffffff r10: 0xffffff9f r11: 0xffffff7f

r12: 0x0390d548 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000

r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000

r20: 0x00000000 r21: 0x00000068 r22: 0x00000064 r23: 0x00000000

r24: 0x000000e0 r25: 0x000000dc r26: 0xbfffd948 r27: 0x020120e8

r28: 0x049b792c r29: 0x0381004c r30: 0x03838000 r31: 0x0407f654

[CallMeDave]

Quote:

---

I have called Dantz tech support and they say its a SCSI problem because of how OSX deals with SCSI cards going from a 50 Pin interface to a 68 Pin interface on the Xserve and they blame Apple, I called Apple and they say there is no known issues with the SCSI cards in the Xserve and they blame Dantz.

 

---

 

Blame is an interesting word here.

 

Issues about SCSI support in OS X have been reported and discussed on this Forum since the day Retrospect 5 first appeared. That Retrospect is unable to communicate with tape drives on unsupported host adapters is well documented on their website.

 

One of the earliest tech support hints that emerged from Dantz was this issue about pinout, and it makes sense. If your SCSI host adapter has 68 pins, and you use a cable that changes this to 50 pins, then _where does the communication data that was on those other 18 pins go?_

 

Apple doesn't ship software that communicates with SCSI tape drives; perhaps if they did they'd have a different answer about how cards such as this work in OS X.

 

Dave

[downeast]

Quote:

---

 

Blame is an interesting word here.

 

Issues about SCSI support in OS X have been reported and discussed on this Forum since the day Retrospect 5 first appeared. That Retrospect is unable to communicate with tape drives on unsupported host adapters is well documented on their website.

 

One of the earliest tech support hints that emerged from Dantz was this issue about pinout, and it makes sense. If your SCSI host adapter has 68 pins, and you use a cable that changes this to 50 pins, then _where does the communication data that was on those other 18 pins go?_

 

Apple doesn't ship software that communicates with SCSI tape drives; perhaps if they did they'd have a different answer about how cards such as this work in OS X.

 

Dave

 

---

 

This is a good argument, but it seems that a company with years of software development like Dantz could figure out a fix for this.

 

Previously to our moving retrospect to a Xserver we were running Retrospect server 5.0 on a old Beige G3 300 MHz desktop running OSX 10.2.6 with a PCI Adaptec card (68 pin). Our SuperDLT has a 50 pin SCSI interface, and we had no issues running it on the old G3 (were did the data on those 18 pins go?). Only when we moved to the Xserve did we start to have the retrospect application crash.

 

Their are other software backup products out there for OSX that do not seem to be effected by this like "BRU for MAC OS X". We have tried BRU and it works like a charm, but they do not have remote client support or the interface I like from Retrospect. We have always enjoyed Retrospect in the past and would like to continue to use it.

[downeast]

Question about SCSI compatibility. In the Dantz knowledgebase article.

 

TITLE: Mac OS X SCSI Host Adapter Compatibility List

 

http://www.retrospect.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27381

 

It talks about the 68-pin Wide Storage Device Issue with OSX.

 

Quote:

---

 

68-pin Wide Storage Device Issue

If your storage device has a wide 68-pin interface, make sure it is connected

to a wide 68-pin SCSI adapter. Many issues have been found when wide devices

have been connected to a narrow 50-pin or 25-pin SCSI adapter when using

Mac OS X and therefore this is not a supported configuration.

 

 

---

 

Here is says "If your storage device has a wide 68-pin interface, make sure it is connected

to a wide 68-pin SCSI adapter." does this mean its only effected if your storage device is 68 pin?

My SuperDLT (storage device) is a 50-pin interface going to a 68-pin SCSI adapter.

 

Does this mean that my problems with Retrospect are not a result of this?

 

Please clarify, thank you.

[francini]

This is the exact same crash I'm seeing on my XServe -- and I'm not even writing to a tape drive! I get this when I back up to a Macintosh File doing a Normal Backup. Retrospect was running quite fine before when it was on a dedicated G4 AGP box talking to a VXA1 autoloader via an Adaptec/Apple 2940. I moved the VXA1 and the Adaptec to the XServe, but I'm not using them at the moment.

 

Oh, yes: no volume is anywhere near the 1 TB limit in size. The source volumes are no bigger than 180 GB, and the targets are no larger than 345 GB.

 

I'm planning on moving to a SpectraLogic Bullfrog AIT-2 jukebox as soon as I get the Retrospect problems under control.

 

In another thread a poster suggested a RAM problem. Since it's quite possible, thanks to the lack of ECC memory checking on XServes (and they call it a server-class machine), I'll have to take that possibility seriously. Nevertheless, any info would be greatly welcome!

 

Thanks.

 

John Francini

 

[natew]

Hi downeast,

 

As long as the numbers of pins are mismatched you are going to have trouble. It does not matter which side of the connection has fewer pins.

 

Nate

[natew]

Hi

 

How far along does the backup get before the crash occurs?

 

Thanks

nate

[downeast]

Quote:

---

natew said:

Hi

 

How far along does the backup get before the crash occurs?

 

Thanks

nate

 

---

 

Thank you for the replies. The backup starts to scan the hard drive (local Xserve drive) and when it gets to about 60k files it crashes every time. I have ran all the types of disk utilities on it and they say nothing is wrong with the drive. I have also tested the ram and their is no issue with the ram. I am begging to think Retrospect just is not compatible with a Xserve.

[AmyJ]

Try running scans of the drive under Configure > Volumes > Browse. If you do not see the crashes happening here, then SCSI troubleshooting is a good place to start.

 

If you continue to see the crashes while browsing the volume under Configure > Volumes try making some subvolumes from the root level folders and scanning them individually to see if the problem can be isolated to a specific directory.

[francini]

Quote:

---

AmyJ said:

Try running scans of the drive under Configure > Volumes > Browse. If you do not see the crashes happening here, then SCSI troubleshooting is a good place to start.

 

If you continue to see the crashes while browsing the volume under Configure > Volumes try making some subvolumes from the root level folders and scanning them individually to see if the problem can be isolated to a specific directory.

 

---

 

I tried this Configure > Volumes > Browse nine times on my XServe's system disk. The disk has 138,398 files. Here are the results from the different runs.

 

Run 1: Crashed at 68,721 files

Run 2: Crashed at 53,765 files

Run 3: Went to completion (138,398 files)

Run 4: Crashed at 83,630 files

Run 5: Went to completion

Run 6: Crashed at 38,010 files

Run 7: Went to completion

Run 8: Enumerated all 138,398 files but died in the next enumeration step.

Run 9: Crashed at 53,765 files

 

Given this behavior, where the crashes appear to be all over the map, I'm really, really confused, not to mention exasperated.

[CallMeDave]

Quote:

---

I have also tested the ram and their is no issue with the ram.

 

---

 

Since it's not possible to test all the memory on this machine, you really don't know that there's no issue with the ram. In many cases, running Retrospect is more of a test of RAM then anythinge else you can do on the computer.

 

What is the memory configuration of the machine? Two 512k chips? I'd suggest taking one out and testing, then swap and test with the other. If one configuration allows continued successful retrospect scans then you're probably due for a new SDRAM card (that's assuming that it's _not_ a SCSI issue, which is what I'd expect given the pin configuration issues, but if Amy says that this test isolates the tape drive then I believe her, although I'd still be more satisfied if you were to physically disconnect the tape drive for this series of tests...)

 

Dave

[downeast]

Quote:

---

AmyJ said:

Try running scans of the drive under Configure > Volumes > Browse. If you do not see the crashes happening here, then SCSI troubleshooting is a good place to start.

 

---

 

Thank you for the replies. I have tried the scan via Configure > Volumes > Browse, and the application still continues to crash. I took the advise of CallMeDave and removed the SuperDLT all together to see if it is a SCSI issue. Without a SCSI Tape Device attached, retrospect runs perfectly. I have done about 10 successful backups to a file on another drive without a hitch. I can scan, verify and rebuild without retrospect crashing. So this leaves me with two options.

 

1. I could dump my $5000 tape drive and look for another $5000+ SCSI drive that has the same pin confuguration.

 

2. I could move the SuperDTL off my Xserve and back to my old G3 desktop running 10.2.8 (were it was before, and ran without issue) and use that for all my backups.

 

I hope that future versions of Retrospect will work better with SCSI on the Xserve.

[ipedro]

what scsi card are you using ? Please use Atto only if you want to avoid problems (only atto cards are certified by apple). But even if your scsi chain will work, expect another problem with xserve+sldt : your system will hang sometimes (and reboot your xserve). I hope they'll fix it for Retrospect 6.

[bioheath]

I hate to be a wet blanket, but I think moving it back to the old server may be the solution that spares you the most grief. After fighting for months with my Xserve and SCSI tape library, I finally moved the whole setup to an old sawtooth G4 tower. Since then, no problems. I wish I had done it three months ago. Shoot me, but I don't think SCSI and Xserves mix, even with the bundled card.

[downeast]

Quote:

---

ipedro said:

what scsi card are you using ? Please use Atto only if you want to avoid problems (only atto cards are certified by apple). But even if your scsi chain will work, expect another problem with xserve+sldt : your system will hang sometimes (and reboot your xserve). I hope they'll fix it for Retrospect 6.

 

---

 

I am using the card that shipped with the Xserve (direct from Apple). It is a Atto card. With the amount of non help I have gotten from Retrospect Tech support (on the phone, not the forums, all the forums people have been good), I probably will not upgrade to version 6.

 

Quote:

---

heath tucker said:

I hate to be a wet blanket, but I think moving it back to the old server may be the solution that spares you the most grief. After fighting for months with my Xserve and SCSI tape library, I finally moved the whole setup to an old sawtooth G4 tower. Since then, no problems. I wish I had done it three months ago. Shoot me, but I don't think SCSI and Xserves mix, even with the bundled card.

 

---

 

Thanks for the reply, I agree with you. I think moving back to the older machine is my only solution. Even with Retrospect 6.0 out soon, I am afraid it might not fix retrospects problems.

[CallMeDave]

Quote:

---

think moving back to the older machine is my only solution. Even with Retrospect 6.0 out soon, I am afraid it might not fix retrospects problems.

 

---

 

If the software works on your desktop mac/SCSI host adapter, but fails on your XServe/SCSI Host adapter, then perhaps you've identified a hardware issue that can't be blamed on Retrospect.

 

For a further test you could replace the SCSI host adapter that works successfully in the desktop mac with the host adapter from the XServe. If it fails, you've all but proven that the card itself is the cause.

 

 

Just a thought,

 

Dave

[downeast]

Quote:

---

CallMeDave said:

 

 

 

If the software works on your desktop mac/SCSI host adapter, but fails on your XServe/SCSI Host adapter, then perhaps you've identified a hardware issue that can't be blamed on Retrospect.

 

---

 

 

 

Retrospect application is crashing, not the Xserve. The Atto SCSi card works great with BRU backup software. This would be simple logic to conclude that it is Retrospect to blame, if that is the only application not working with the SCSI card. If its a hardware issue, which I belive it is, its a issue in the software not compatible with the Hardware. Acroding to the Dantz Knowledgebase artical, the Xserve SCSI are is fully compatible with Retrospect Server.

 

 

 

Quote:

---

 

 

Dantz has completed Retrospect compatibility testing with Apple's Xserve.

 

When configured with the Ultra160 SCSI Card option, the Xserve makes an

 

excellent Retrospect backup server, exhibiting solid performance and

 

stability.

 

---

 

Quote:

---

 

 

SUPPORTED OPERATING SYSTEMS

 

At this time, Retrospect 5.0.236 or later supports the Xserve running Mac OS X Server 10.1.5 or later.

 

---

 

 

 

http://www.retrospect.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27639

 

 

 

If the artical on their site says it works, and it clearly does not exhibit solid performance and

 

stability.. It is a clear issue with Retrospect Server software.

[CallMeDave]

Quote:

---

Retrospect application is crashing, not the Xserve

 

---

 

Just to be sure I'm clear:

 

1 - I never implied that I thought your XServe was crashing; I correctly described your problem as Retrospect failing to work.

 

2- Dantz has explicitly informed you that a 68 pin wide card connected to a 50 pin narrow device is an unsupported configuration.

 

3- You had some previous measure of success in an unsupported configuration using a slower machine, but are unable to get this unsupported configuration to work with a much faster, less tolerant machine. This doesn't change the fact that your SCSI host adapter is mismatched with your tape drive.

 

4- You believe that Dantz should be able to program around unsupported hardware configurations, missing the entire point of having qualified, supported configurations.

 

5- The card you have is supported in Retrospect with devices that match its width and voltage differential; your device does not.

 

6- You believe that it's a hardware issue and find it clear that it's a software issue.

 

7- BRU does everything that Retrospect does without a problem.

 

Am I missing anything?

 

Dave

 

[Konrad]

I also have this kind of Problems.

I will try to summarize my configurations and results:

 

Hardware:

XServe with ATTO-Card, Sony LIB-81/AIT (Customer machine)

G3 (b/w, Adaptec/Adaptec 2906, ADIC FastStor7/DLT (privat testmachine)

 

G3 with 10.2.8 Server -> running perfect

G3 with 10.3.2 Server(+Sec.Updates) -> kernelpanic, high CPU-load till freezing, Retrospect not resonding

G3 with 10.3.2 (+ Sec.Updates) -> running perfect

G3 with 10.3 Server -> running perfect

 

XServe with 10.2.8 Server -> running perfect

XServe with 10.3.2 Server (+sec.Updates) -> high CPU-load till freezing, Retrospect not responding

 

I spend with the G3 a couple of days to crosscheck incompatibility of hardware without any result!

Supported SCSI-cards are:

Adaptec 2906 -2930, 29160, 39160 (all mac-versions)

Apple/Adaptec 2940 U2B (only with firmware 1.2 from Apple!)

Atto-cards

 

I will try to update the G3 step by step to 10.3.2 Server with security updates to find out when the problems will appear.

 

It could be helpful to know the systemversion of the other machine which have the problems.

 

Konrad

[ipedro]

well, it's always the same problem...Retrospect works everywhere except on os x server+xserve..too bad if you are using retrospect on your server i registered to the xserve mailing list from retrospect and still no mail at all about any development for the xserve.