Jump to content

Misery Index Just Keeps Rising! Kernel Panics...


Recommended Posts

About three weeks now since I upgraded to R5.0 for Workgroups. I am running OS X Server 10.1.3 on a 500 MHz G3 Server with 768 MB RAM. My tape library is the Sony TSL-11000 DDS AUTOLOADER which is Ultra2 (68 PIN--cable is 6' and no other SCSI peripherals attached (fully terminated)) and the PCI card was an older SCSI adapter (72XX). All clients were OS X clients (G4s and a G3 Powerbook, except two windows clients (1 Win2000 and 1 Win ME). By the way, only one server is on this network. At that time, I received my first Kernel Panic referencing the SCSI adapter while attempting to backup my first client (a G3 Powerbook (Bronze Firewire). This was not a client panic, it was a panic of the server on which R5.0 was running.

 

 

 

I checked the Dantz Knowledge Base and purchased (based upon their suggested R5.0 list of OS X compatible adapter cards) the PowerDomain 29160 from Adaptec, which led to my next Kernel Panic. Kernel panics did not happen each time I attempted to run the backup, the other times either caused Retrospect to crash (breaking its thread) or to slow the compare/verification process down to a blazing 4.1 MB/min before inevitably crashing. By the way, the verification process (when it got that far) caused the tape drive to continuously verify for a second, rewind a little, reposition and then begin the verification process again (verify, rewind, reposition...). This at first appeared to be an internal buffer issue in Retrospect, but I would think that their programmers would have designed the buffer to dynamically adjust based upon available RAM (Again, I have 768 MB on this box). At most, I was able to get one and one-half clients backed up before Retrospect either crashed or panicked the OS of the server R5.0 was running on. Again, no client panics. However, looking at the log for completed client backups (which took over a day to verify), the backups were corrupted (unusable with anywhere from 15,000 to 20,000 file errors).

 

 

 

OK, so today I determined (through much searching of this forum) that the 29160 is no longer considered to be a compatible card for R5.0--I didn't think that I would need to recheck the OS X SCSI Adapter compatibility page when I had previously checked and verified that the 29160 was blessed by Dantz. I now go out and buy the Atto EPCI-UL3S--mind you, not relying on Dantz's suggestion, but because I read from a few other user's that they were successful in backing up from R5.0 on OS X and OS X Server with this card. After spending over $400 for the card and the Mini 68 Pin Ultra3/68 Pin Ultra2 cable (6') (not to mention the price of the 29160), I made sure that file sharing (even the server side) was shutdown, I made sure that screen savers and energy savers were set to "never" on all clients and the server, I updated the firmware for the Atto card to 1.66, and confirmed that my Sony Tape Drive had the latest firmware (L100). I confirmed full bandwidth of my Netgear switch (no firmware to update on it, its transparent to the NIC cards)--all clients and server are 10/100 base-t (with the longest ethernet cable run being 10'). I also updated Retrospect to 5.0.203 from 5.0.201--I wouldn't have known that this update existed if a tech hadn't posted the link buried in one of the forum threads I searched. First attempt to run a backup with this configuration was running at anywhere from 125 MB/min to 166 MB/min and resulted in another kernel panic--this panic occurred after the thread broke so I was unable to determine at what stage (writing or verifying) it occurred.

 

 

 

Since I read that some users were able to backup the drives on the server that was running R5.0, but not their clients, I rearranged the backup order so that drives located on the server were backed up before attempting to backup the clients--hoping that I could at least get backups of the server with the plan to then log the server onto each Mac client (i.e., enable file sharing and place each client computer onto the desktop of the server). The writing of the first drive went off without a hitch (speeds averaging from 125 MB/min to 166 MB/min) and the verification process worked for the first 1.1 GB before another kernel panic (speed for the internal drive verification to tape at the time of the panic was Source 147.4 MB/min and Total 142.7 MB/min). Obviously, the time to panic is much faster--rather than a day, its now about 30 min. So at least I no longer have to awake and wonder whether I've solved the backup problem. Now I can toss and turn all night wondering if the companies development files will be there or be unrecoverable the next day. Not bad for only $400 + time, gas and aggravation.

 

 

 

Have I missed something? Any thoughts? By the way, I have taken pictures of the screen for most, if not all of these panics. I tried to find a way to send these to Dantz--you would think that they would be interested in this information so that they would have more info on these panics and could either address their software's problems or contact Apple/Adaptec/Atto/... with some useful info and firepower. You'd think they'd want this, but there isn't a way to send it via email without spending $70 for a single support call (Oh, excuse me, just $69.95 to interact with a live Support person for a product that hasn't worked from day one). Even when I attempted to call, I was placed on hold forever and gave up--I was even willing to expend more $$ to talk about this with a Dantz tech today. I'm about to check into a BSD UNIX backup system if they can't resolve this problem soon--I would think that Apple clients exist or could be developed for a UNIX backup system. Actually, I'm already searching... Misery Index-->>Off the Scale!

Link to comment
Share on other sites

Sorry, I don't have any practical suggestions, but I can sympathize. I won't go into the details, but I also haven't been able to get Retrospect 5 Desktop to work. It makes me wonder if there's something inherently wrong with the way SCSI is implemented under OS X. At this point, I've switched to backing up my hard drive under OS 9 - I won't be able to restore my OS X volume, but at least my data files should be safe.

Link to comment
Share on other sites

Unfortunately, the Server is the only Mac box that has PCI slots. All other Mac workstations are either iMac G4s, Powerbook G3 Firewire, or G4 Cubes. One common thread I discovered is that the Kernel Panics and corrupted backup data occur when copying from or comparing ATA drives that are Mac formatted--i.e., the Server's internal ATA drive (boot drive) and networked Macs that have internal ATA drives. Retrospect successfully backs up WinTel machines with internal ATA drives, the two internal SCSI drives on our G3 Server and an external SCSI drive attached to the Server. The SCSI backups are not corrupted--i.e., I recovered back-up files without a problem. ATA drives sometimes cause kernel panic during compare stage, sometimes hang Retrospect while copying data, and sometimes hangs during compare stage (verification). Data is corrupted on ATA drive back-ups that made it through to backup process.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...