 |
 |
copying file causes kernel panic
|
 |
|
 |
|
Senior User
Join Date: Mar 2000
Location: London
Status:
Offline
|
|
Hi All,
When I copy a certain file from one drive to another, I get a kernel panic. The problem is isolating that file (and I'm assuming it's just one file): it sits somewhere inside a folder that contains a very large project (26Gb of files, including thousands of photos).
Running Disk First Aid doesn't fix it, neither does DiskWarrior.
I have two questions:
1) how do I isolate that file so I can delete it?
2) what can happen to a file such that it can cause a kernel panic when it is copied?
Any help would be greatly appreciated,
Chas
|
|
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status:
Offline
|
|
|
|

"The natural progress of things is for liberty to yield and government to gain ground." TJ
|
| |
|
|
|
 |
|
 |
|
Senior User
Join Date: Mar 2000
Location: London
Status:
Offline
|
|
Thanks for taking a look. This is what I've got:
panic.log:
Description: Panic (system crashes) log
Size: 2.11 KB
Last Modified: 12/02/2006 17:27
Location: /Library/Logs/panic.log
Recent Contents: Sun Feb 12 16:16:04 2006
panic(cpu 0 caller 0x008A60A0): DART entry exception: HyperTransport write logical page 0x01240
Latest stack backtrace for cpu 0:
Backtrace:
0x00095718 0x00095C30 0x0002683C 0x008A60A0 0x007FFD70 0x007FFDA8 0x00661048 0x002D0060
0x002CEF28 0x000A9894
Kernel loadable modules in backtrace (with dependencies):
com.apple.driver.AppleGPIO(1.1.9d0)@0x7fd000
dependency: com.apple.driver.IOPlatformFunction(1.8.0d12)@0x4d 8000
com.apple.driver.MacIOGPIO(1.1.9d0)@0x65f000
com.apple.driver.AppleMacRISC4PE(1.8.5d0)@0x89f000
dependency: com.apple.iokit.IOPCIFamily(1.7)@0x458000
dependency: com.apple.driver.IOPlatformFunction(1.8.0d12)@0x4d 8000
Proceeding back via exception chain:
Exception state (sv=0x00E31280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)
Kernel version:
Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC
*********
Sun Feb 12 17:27:11 2006
panic(cpu 1 caller 0x008A30A0): DART entry exception: HyperTransport write logical page 0x00CE1
Latest stack backtrace for cpu 1:
Backtrace:
0x00095718 0x00095C30 0x0002683C 0x008A30A0 0x007FFD70 0x007FFDA8 0x00661048 0x002D0060
0x002CEF28 0x000A9894
Kernel loadable modules in backtrace (with dependencies):
com.apple.driver.AppleGPIO(1.1.9d0)@0x7fd000
dependency: com.apple.driver.IOPlatformFunction(1.8.0d12)@0x4d 8000
com.apple.driver.MacIOGPIO(1.1.9d0)@0x65f000
com.apple.driver.AppleMacRISC4PE(1.8.5d0)@0x89c000
dependency: com.apple.iokit.IOPCIFamily(1.7)@0x458000
dependency: com.apple.driver.IOPlatformFunction(1.8.0d12)@0x4d 8000
Proceeding back via exception chain:
Exception state (sv=0x00E39280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)
Kernel version:
Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC
*********
|
|
|
| |
|
|
|
 |
|
 |
|
Mac Enthusiast
Join Date: Oct 2004
Status:
Offline
|
|
Firstly, I'd copy the stuff in sections alphabetically. Say copy 1/5th of the folder and see if you get a problem and then another 1/5th and so on until it kernel panics. Then you can narrow down the problem. You can initially narrow it down quite far if you know roughly where in the copy stage the kernel panic happened because I'm sure OS X copies alphabetically.
Say it was at 50% that it panicked. You would then say it happened at around 50% of 26GB = 13GB. So select files/folders from the top in alphabetical order and check to see when the size approaches 13 GB. The problem file should lie around the folders at the bottom of the selection.
I haven't seen a bad file cause a kernel panic but I have seen a corrupt folder that hung up the Finder every time I opened it. It was the result of a bad copy and fortunately it wasn't important so I just trashed it.
If you need the files copied and have the space, you could try either zipping the folder or making a dmg of it, copying that file and then extract to the drive.
|
|
|
| |
|
|
|
 |
|
 |
|
Senior User
Join Date: Mar 2000
Location: London
Status:
Offline
|
|
:-)
It's a good suggestion (did you ever use the util "ConflictCatcher" under OS9? It used a similar strategy when resolving conflicts among extensions and control panels).
The folder hierarchy in question is deep and complicated, so I'm not quite sure where exactly the OS is stopping its copy. I did start doing exactly what you suggested, but I'm quite worried about corrupting some part of the OS (I just spent literally two days rebuildng OSX after the Finder got damaged by another issue).
Your suggestion about zipping or making a disc image is a good one, I'm going to try that (but mainly to see if I can find out where the problem lies, without risking continual kernel panics, I hope!).
What I really want to do is fully archive this project to DVD. perhaps I'll get Toast to do a multi-disc span and see where it failed.
Good suggestions, I appreciate the time you've taken to help me out (I am still quite curious to find out what it is about a file that can cause kernel panics when it is copied though...)
Chas
|
|
|
| |
|
|
|
 |
|
 |
|
Mac Enthusiast
Join Date: Oct 2004
Status:
Offline
|
|
Kernel panics in relation to file copying are usually either corrupt directories or there could be a bad sector on your hard drive:
http://www.macmaps.com/kernelpanic.html#DIRECTORY
If your disk utils didn't see anything wrong then I'm guessing it could be a bad sector. They can even be as little as a few hundred k in size. Quite frustrating when you have a 26GB folder.
I like Techtool Pro out of all the diagnostic tools. I've never found much use for Diskwarrior. Here a quote on Bad sectors from http://db.tidbits.com/getbits.acgi?tbart=07696:
Bad Sector! Bad sectors are a common problem and can occur when a sector on the disk becomes unreadable, either due to damage to the disk surface, or because the data on the sector becomes scrambled. Although the data will be toast either way, it's relatively easy to repair the disk. In the first case, the bad sector is replaced from a set of spare sectors the disk maintains. In the latter case, new data is written to the sector, replacing the scrambled data. In either case, the original contents of the sector are lost.
Using a special tool, I created bad sectors with scrambled data. (I had to perform this test on a real disk.) Tech Tool Pro detected the bad sectors, but couldn't fix them. It also didn't say which unlucky files contained the bad sectors, so it doesn't give you any hints as to which files are damaged. This result puts it on par with Drive 10 and Disk Guardian. Disk Utility, Norton Disk Doctor and DiskWarrior didn't even detect the bad sectors.
It's fairly easy to fix bad sectors on modern disks, and its not that hard to find out which file contains a bad sector. I'm surprised no disk utility has mastered this trick yet, since it would give them a distinct advantage.
|
|
|
| |
|
|
|
 |
 |
|
 |
|
|
|
|
|

|
|
 |
Forum Rules
|
 |
 |
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
 |
 |
 |
 |
|
 |
|