Kernel panic from com.apple.filesystems.afpfs

Question

Looking back at my panic logs over the last two months, I have 15 kernel panics, 11 of which appear to be coming from com.apple.filesystems.afpfs. This appears to always happen when I mount a drive over AFP, am copying files, and the network connection gets disconnected somehow (system goes to sleep, disable wifi).
Help? I figure I can reduce the amount that this happens manually but a dropped AFP connection shouldn't be cause for a kernel panic.
Tue Feb 3 07:17:01 2009
panic(cpu 1 caller 0x001A9C68): Kernel trap at 0x56d8b1ef, type 14=page fault, registers:
CR0: 0x8001003b, CR2: 0x00000004, CR3: 0x01927000, CR4: 0x00000660
EAX: 0x00000000, EBX: 0x56b9fc34, ECX: 0x00000000, EDX: 0x0000010c
CR2: 0x00000004, EBP: 0x56b9fd48, ESI: 0x56b9feac, EDI: 0x00000000
EFL: 0x00010202, EIP: 0x56d8b1ef, CS: 0x00000008, DS: 0x13570010
Error code: 0x00000000
Backtrace (CPU 1), Frame : Return Address (4 potential args on stack)
0x56b9fa38 : 0x12b4f3 (0x45b13c 0x56b9fa6c 0x1335e4 0x0)
0x56b9fa88 : 0x1a9c68 (0x464700 0x56d8b1ef 0xe 0x463eb0)
0x56b9fb68 : 0x1a038d (0x56b9fb80 0x1 0x56b9fd48 0x56d8b1ef)
0x56b9fb78 : 0x56d8b1ef (0xe 0x48 0x56b90010 0x390010)
0x56b9fd48 : 0x56d5a07c (0x56b9feac 0x134960a4 0x0 0x0)
0x56b9fee8 : 0x56d60397 (0x754f004 0x9399004 0x754f284 0x0)
0x56b9ffc8 : 0x1a017c (0x754f004 0x0 0x1a30b5 0x76b35d0)
Backtrace terminated-invalid frame pointer 0
Kernel loadable modules in backtrace (with dependencies):
com.apple.filesystems.afpfs(9.0)@0x56d53000->0x56d9dfff
BSD process name corresponding to current thread: kernel_task
Mac OS version:
9G55
Kernel version:
Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386
System model name: MacBookPro5,1 (Mac-F42D86C8)

Answer 1

I would suggest trying this.
First, repair your hard drive and permissions:
Boot from your OS X Installer disc. After the installer loads select your language and click on the Continue button. When the menu bar appears select Disk Utility from the Installer menu (Utilities menu for Tiger and Leopard.) After DU loads select your hard drive entry (mfgr.'s ID and drive size) from the the left side list. In the DU status area you will see an entry for the S.M.A.R.T. status of the hard drive. If it does not say "Verified" then the hard drive is failing or failed. (SMART status is not reported on external Firewire or USB drives.) If the drive is "Verified" then select your OS X volume from the list on the left (sub-entry below the drive entry,) click on the First Aid tab, then click on the Repair Disk button. If DU reports any errors that have been fixed, then re-run Repair Disk until no errors are reported. If no errors are reported click on the Repair Permissions button. Wait until the operation completes, then quit DU and return to the installer. Now restart normally.
If DU reports errors it cannot fix, then you will need Disk Warrior (4.0 for Tiger, and 4.1 for Leopard) and/or TechTool Pro (4.6.1 for Leopard) to repair the drive. If you don't have either of them or if neither of them can fix the drive, then you will need to reformat the drive and reinstall OS X.
Next, clear system caches;
Boot into single-user mode. After startup is completed you will be in command line mode and should see a prompt with a cursor positioned after it. At the prompt enter the following then press RETURN after each commandline:
/sbin/fsck -fy
If you receive a message that says "*** FILE SYSTEM WAS MODIFIED ***" then re-run the command until you receive a message that says "** The volume (nameofvolume) appears to be OK." If you re-run the command more than seven times and do not get the OK message, then the drive cannot be repaired this way.
If you were successful then enter:
/sbin/mount -uw /
rm -rf /System/Library/Caches/*
rm -rf /System/Library/Extensions.mkext
rm -rf /Library/Caches/*
reboot
I suggest you print out the above to be sure you do not make any errors when entering the commands. When in single-uwer mode you have 'root' access, so it's important that you not make any mistakes.
See if the above helps. I would also suggest using Ethernet instead of wireless, if you can, to see if the problem is limited to the wireless side of the network.
Also visit The XLab FAQs and read the FAQ on diagnosing kernel panics.