JBP Posted March 24, 2004 Report Share Posted March 24, 2004 Using Xserve, os 10.2.8, Retrospect 6.0.178, backing up an XRaid, using file backup to a second XRaid, getting catalog corruption. If we create a new backup set, we get successful backups for 3-4 days, then failures after that. "Automatic execution unexpectedly quit (terminated) (Possibly due to power failure or system crash)." After the first failure, catalogs will be shown as out of sync. Try to repair catalog via "Update Existing" get another kernel panic. Create a new catalog, ok for 3-4 days again. There is a kernel panic that corresponds to the backup time, beginning: panic(cpu 1): jnl: transaction too big (8380416 >= 8384512 bytes, bufsize 4096, tr 0x42c6fc8 bp 0x1ce2e510) Latest stack backtrace for cpu 1: Backtrace: 0x000857F4 0x00085C24 0x000287B4 0x000C223C 0x001D37A0 0x001D2EF4 0x001D1934 0x001D1A64 0x001D24E4 0x001BC310 0x001C52F8 0x000BA2B0 0x0020FF8C 0x00092950 0x03F2C7E0 Proceeding back via exception chain: Exception state (sv=0x1F83FC80) PC=0x9003450C; MSR=0x0200F030; DAR=0x0308DE36; DSISR=0x00002C1F; LR=0x902630FC; R1=0xBFFFCC10; XCP=0x00000030 (0xC00 - System call) Kernel version: Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Apple says it is a problem with the Dantz "Kernel extension", not a hardware or OS problem. Any ideas? The same panic will come up if you use "Tools>Repair>Update Existing from Directory" when repairing catalogs, however a "Recatalog" will be successful. Link to comment Share on other sites More sharing options...
CallMeDave Posted March 25, 2004 Report Share Posted March 25, 2004 Quote: Apple says it is a problem with the Dantz "Kernel extension", not a hardware or OS problem. The kernel extensions installed with Retrospect are there only to make optical media play nicer with OS X. If Apple is correct, try removing the extensions and restarting and see if things work better. The Finder won't recognize the contents/format of Cd's used by Retrospect, but if that's OK then it's worth a try. Dave Link to comment Share on other sites More sharing options...
JBP Posted March 25, 2004 Author Report Share Posted March 25, 2004 Thanks, could you tell me what extension to remove, & where it is located? Link to comment Share on other sites More sharing options...
CallMeDave Posted March 25, 2004 Report Share Posted March 25, 2004 Use the Retrospect installer to un-install, then do a custom re-install without the system components. Be sure not to un-install your preferences, when prompted by the installer for the choice. Dave Link to comment Share on other sites More sharing options...
JBP Posted April 29, 2004 Author Report Share Posted April 29, 2004 We did as you suggested, Dave. It appeared to work for approximately 8 days, then the problem recurred. The kernel panic is identical, and the Retrospect log states "Unexpectedly quit due to power failure or system crash". Again, if we rebuild catalogs, the backups will go fine for about 4 days now, then the problem will recurr. ANY suggestions are welcome. Thanks, John Link to comment Share on other sites More sharing options...
natew Posted May 12, 2004 Report Share Posted May 12, 2004 Hi Have you updated to the latest version of Retrospect and driver update from the Dantz update site? Can you post the versions you are currently using? Thanks Nate Link to comment Share on other sites More sharing options...
macdoc Posted June 23, 2004 Report Share Posted June 23, 2004 JBP_1... One or more of your hard drive(s) are formatted 'Mac OSX Extended (Journaled)'. Get info on the drive(s) and you will see for sure. For now, Journaling needs to be turned off. Use a unix terminal window and the tool/command 'diskutil'. 'man diskutil' should give you the proper syntax. I think it is 'diskutil disableJournal'. Leave it off for now and see if you can get past the window of time where the error occurs. I had a 48GB crash log file (from an Insyde Software USB keyboard driver) that would cause the same error. Could not 'rm' it, trash it or write /dev/null to it without causing the "jnl: transactrion too big" error. Finally located a unix Guru that suggested the diskutil. It worked great. I re-enabled disk journaling after I rm'd the file. In your case, I don't think you will be able turn journaling on until there is a fix from Apple or Dantz regarding Journaled disks and large file transactions. Hope this helps... Fred... -- Link to comment Share on other sites More sharing options...
macdoc Posted June 25, 2004 Report Share Posted June 25, 2004 Nate, Can you take a look into this? My last post that is regarding the journaled hard drive formatting. TIA Fred... -- Link to comment Share on other sites More sharing options...
CallMeDave Posted June 25, 2004 Report Share Posted June 25, 2004 Quote: I had a 48GB crash log file ... that would cause the same error. While there may indeed be some issues with journaled volumes, 48 GB is not overly large for a Retrospect file. Mine grows to about 75 before I recycle it, and it hasn't shown any corruption (or caused any panics). Journaling is on by default in Panther (previously it was a default only on Server), so there would probably be a slew of these reports if 10.3.x was unable to work with large files at all. Note that the original poster's last entry was three months ago, and he declined to update the Forum on his progress. So maybe removing the Retro extensions helped. I don't have them installed... Dave Link to comment Share on other sites More sharing options...
JBP Posted July 6, 2004 Author Report Share Posted July 6, 2004 Hello all, The last few weeks have provided more info... the kernel panic occurs when running the "Recycle" backup only. That is why you can back up for several days straight with no problems. The customer is running two backup sets, each runs Mon.-Thurs. with the previous week's set running a recycle backup on Fridays. That is when the kernel panic occurs. If you "rebuild" catalog before the recycle backup it *usually* works, not always. Journaling has been switched off, but I have not gone into the terminal as instructed by The MacDoctor, LLC . I will try that next. Link to comment Share on other sites More sharing options...
macdoc Posted July 6, 2004 Report Share Posted July 6, 2004 Keep us posted. It certainly has my interest... Fred... -- Link to comment Share on other sites More sharing options...
natew Posted July 7, 2004 Report Share Posted July 7, 2004 Hi This doesn't make much sense yet. A recycle backup empties the catalog completely. Rebuilding before a recycle backup shouldn't make a difference. Can you reproduce this error every time you run a recycle backup? If so does the problem occur right after the backup starts (when the backup set is emptied) or later after more data has been copied. A recycle backup is going to copy a lot more data that incrementals. Accordingly the operation is longer and requires more resources. I'm really curious to see how much data is copied before it fails. Thanks Nate Link to comment Share on other sites More sharing options...
pvision Posted April 6, 2006 Report Share Posted April 6, 2006 Well I never. I just Googled "site:dantz.com kernel panic recycle" and found this thread. Running 10.2.8 Server here and had a kernel panic when I recycled a hard disc backup with a 450 Gb data file on a journaled external drive. Sounds like this is a very reproducible problem! I suspect that the Xserve will restart after the panic but the backup won't recycle leading to the drive filling prematurely. It's a difficult one to test as people work late here and I can't crash the server willy-nilly. I used Disk Utility to wipe the drive & remove journaling & will see what happens See the similarities in the crash log! panic(cpu 0): jnl: transaction too big (8385024 >= 8388096 bytes, bufsize 4096, tr 0x675ffc8 bp 0x1ce46820) Latest stack backtrace for cpu 0: Backtrace: 0x000857F4 0x00085C24 0x000287B4 0x000C223C 0x001D37A0 0x001D2EF4 0x001D1934 0x001D1A64 0x001D24E4 0x001BC310 0x001C52F8 0x000BA2B0 0x0020FF8C 0x00092950 0x711A7466 Proceeding back via exception chain: Exception state (sv=0x229C7780) PC=0x9003450C; MSR=0x0200F030; DAR=0x03068456; DSISR=0x00002C1F; LR=0x902630FC; R1=0xBFFFCC00; XCP=0x00000030 (0xC00 - System call) Kernel version: Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC 10.2.8, Xserve 2 Gb RAM, RS 6.1.126, external La Cie Firewire 400 drive Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.