Persistant autofs crash - 10.5.6

I have a very similar problem on my Powermac g5. It would crash (panic) almost daily. I took it to Apple and they swapped the logic board. Still crashed. Swapped the memory. Still crashed. Reinstalled Leopard. Still crashed. Remove PCI Express cards, still crashed. Swapped fans in case it was a cooling problem. Still crashes.

Started happening a few months ago after 2+ years of flawless operation. Always crashes the same way:

0x68184E54 0x001090D8 0x000EA2FC 0x000EB06C 0x000D9F30 0x0030C6AC
0x000B34C8 0x00000000
backtrace terminated - frame not mapped or invalid: 0xF08AD200

Kernel loadable modules in backtrace (with dependencies):
com.apple.filesystems.autofs(2.0.1)@0x68182000->0x6818efff
Exception state (sv=0x6963b500)
PC=0x909D0138; MSR=0x0000F030; DAR=0xF030AEE4; DSISR=0x42000000; LR=0x906824C0; R1=0xF08AD200; XCP=0x00000030 (0xC00 - System call)

I've begun to wonder if it is some kind of interaction with my NFS/AFP/SMB fileserver or perhaps some kind of error in firewire or usb external drives... Oddly enough, none of my other Macs do this at all. They are a mix of PPCs and Intels (although one Macbook did panic in autofs once).

Help Anyone (Apple?)

--tom

There are some known bugs in SMB support that Apple has inherited from the upstream open source tree.

If you can use straight NFS it should solve the issues, as would writing to any file system other than an SMB share.

Well, I really don't use SMB at all. The machine even crashes when there are no network (NFS/AFP) volumes mounted. I haven't figured this out, but the longest I've had the machine stay up is 3 days -- when there were no external hard disks or firewire devices attached. Could be a coincidence though...

Markson wrote:
Well, I really don't use SMB at all. The machine even crashes when there are no network (NFS/AFP) volumes mounted. I haven't figured this out, but the longest I've had the machine stay up is 3 days -- when there were no external hard disks or firewire devices attached. Could be a coincidence though...

That points to other issues and you should run the diagnostics on the discs included with your machine.

Thanks for the suggestion. The diagnostics have been run by me and by the Apple Store repair people and everything checks out. Almost of the hardware on the machine has been changed.

Got a second panic on a macbook tonight (in com.apple.filesystems.autofs). I now suspect there is some kind of wierd incompability between MacOS and something on my network -- most likely the Linux file server. I have taken your suggestion and completely shut off SMB on the linux machine. Let's see how this goes... Ultimate test: Shut down the network altogether and see if that improves things... I'll report what I discover.

Hi,

I believe I have found a workaround for the mysterious autofs crash. I have forced the kernel not to load com.apple.filesystems.autofs and disabled autofs and automounting.

This has kept my machine up and running for two days under heavy usage without a crash. Here's the commands I ran in terminal (sudo'ing to root):

launchctl unload -w /System/Library/LaunchDaemons/com.apple.autofsd.plist
launchctl unload -w /System/Library/LaunchDaemons/com.apple.automountd.plist
mv /System/Library/Extensions/autofs.kext /System/Library/Extensions/autofs.disabled

Reboot the system and autofs is completely disabled and the crashes go away. To turn it back on:

mv /System/Library/Extensions/autofs.disabled /System/Library/Extensions/autofs.kext
launchctl load -w /System/Library/LaunchDaemons/com.apple.autofsd.plist
launchctl load -w /System/Library/LaunchDaemons/com.apple.automountd.plist


--tom

Just a quick followup: By removing the kernel module and shutting down the facility, I have achieved 7 days of continuous uptime on my Powermac G5 -- This is a record for several months. I'm curious if other people have also had success, as well.

If you're not actively using a network file system, autofs should not be crashing and burning on its own.

Now, it could be due to a bug in the autofs kext, or it could be that you have some bad RAM and the memory locations that used to cause issues with the autofs kext are now either free or being used in a non-critical way by some other kext or application.

Thanks for your thoughts on this. I struggled with this from a hardware angle for weeks. The machine has 12gb, I removed half the memory memory -- panic. Replaced that half with the half that I swapped out -- panic. Applecare replaced the logic board --- panic. Replaced the disk drive. Panic. Reinstalled Leopard. Panic. And it ALWAYS panics in com.apple.filesystems.autofs.

I'm really firmly convinced this is some kind of bug in autofs. I think it has to do with the 10.5.6 update since this only began happening a couple of months ago. Or it could be that my some new update on my Linux fileserver is tickling the bug -- don't know. Since i really don't care about autofs, disabling it is no biggie and has completely solved the panic problem. Since the PowerPC is now effectively dead, I'd be very surprised if this ever got fixed (although the occasional macbook autofs panic offers hope that it might be fixed).

Nonetheless, if there is bad memory, I will eventually hit it again. But going over a week without a panic after weeks of daily crashes is very satisfying.

The problem is, if it was something inherent to the autofs kext for PPC, we'd read a bunch of posts here from PPC users with the same problem, and at least I haven't seen them.

That's what makes me suspect your hardware rather than the kext at this time.

I totally agree that it sounds like hardware and I appreciate your insights. But there isn't any of the original hardware left! It's all been swapped at one point or another without resolving the panic. Apple even swapped the fans on the G5 just in case it was a cooling problem.

Interesting note: My Macbook panic'd again yesterday in autofs. This is too much of a coincidence and really leads me to believe this is not a hardware problem. I have about 5 Macs on my network. The only two which panic are the two which regularly access the file server (via NFS). The machines which never touch the NFS server never panic.

So, my continued hypothesis is that there is some kind of incompatibility between MacOS and the Linux machine that is showing this bug on the Mac. I don't know how many people are using NFS from a Linux machine, but it could be peculiar to a particular combination of versions. For reference, the kernel version on the Linux server is 2.6.26.6.

Now if we had the source to the Mac Kernel module, I would add a bunch of printfs in the autofs module and see what it's doing...

--tom

If you boot your machine and never, ever mount any network file systems (except for from other Macs) and still see the panic, it's hardware.

But as you mentioned, you are using network file systems, and those are the machines that panic, which points to a software bug (and not necessarily on Apple's part, but I digress.)

You said you didn't have any network file systems mounted when the systems panicked, but the fact that you once did is a big piece of information we had been missing.

I apologize for giving misleading information...I've been trying to put 4 weeks of information together into a series of posts across 30-50 reboots.

Yes, the machines at one point or another did have an NFS filesystem mounted. They may or may not have had it mounted at the moment of panic. I do believe this is an Apple bug since a panic should never happen on a client system regardless of what happens on the server.

--tom

I agree, panics should not occur, the issue, as you stated, is why the panic is occurring.

The source to autofs is available to anyone willing to register for a (free) Apple Source License:

http://www.opensource.apple.com/darwinsource/10.5.6/autofs-109.1/

Unfortunately the panic snippet you posted above isn't enough to be able to diagnose the issue any further from it; we'd need much more of the panic.log file.

If the panic message is "No mapping exists for frame pointer" that's indicative of stack pointer corruption elsewhere that may not have anything directly to do with the autofs kext.

Here's two panic logs. The first from the PowerMac G5 which was crashing daily and the second from the Macbook. Any insights into where to go from here would be appreciated...

--tom

------------------------PowerMac G5--------------------
Fri Apr 3 23:10:55 2009


Unresolved kernel trap(cpu 3): 0x300 - Data access DAR=0x0000000000000038 PC=0x000000000082BFAC
Latest crash info for cpu 3:
Exception state (sv=0x6cb1f280)
PC=0x0082BFAC; MSR=0x00009030; DAR=0x00000038; DSISR=0x40000000; LR=0x0082BFA0; R1=0x795CF6A0; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0082BE54 0x001090D8 0x000EA2FC 0x000EB06C 0x000D9F30 0x0030C6AC
0x000B34C8 0x3C2F6B65
backtrace terminated - frame not mapped or invalid: 0xF040A200

Kernel loadable modules in backtrace (with dependencies):
com.apple.filesystems.autofs(2.0.1)@0x829000->0x835fff
Proceeding back via exception chain:
Exception state (sv=0x6cb1f280)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x8b819000)
PC=0x027A6138; MSR=0x0000F030; DAR=0xE1992000; DSISR=0x42000000; LR=0x035524C0; R1=0xF040A200; XCP=0x00000030 (0xC00 - System call)

BSD process name corresponding to current thread: Xcode

Mac OS version:
9G55

Kernel version:
Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01 PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC
System model name: PowerMac11,2
panic(cpu 3 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 3:
Backtrace:
0x0009BCF0 0x0009C694 0x00029EA0 0x000AFA90 0x000B32F8
Proceeding back via exception chain:
Exception state (sv=0x6cb1f280)
PC=0x0082BFAC; MSR=0x00009030; DAR=0x00000038; DSISR=0x40000000; LR=0x0082BFA0; R1=0x795CF6A0; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0082BE54 0x001090D8 0x000EA2FC 0x000EB06C 0x000D9F30 0x0030C6AC
0x000B34C8 0x3C2F6B65
backtrace terminated - frame not mapped or invalid: 0xF040A200

Kernel loadable modules in backtrace (with dependencies):
com.apple.filesystems.autofs(2.0.1)@0x829000->0x835fff
Exception state (sv=0x8b819000)
PC=0x027A6138; MSR=0x0000F030; DAR=0xE1992000; DSISR=0x42000000; LR=0x035524C0; R1=0xF040A200; XCP=0x00000030 (0xC00 - System call)

BSD process name corresponding to current thread: Xcode

-----------MacBook---------------

Mon Apr 13 14:00:26 2009
panic(cpu 0 caller 0x001A9C68): Kernel trap at 0x00c52a17, type 14=page fault, registers:
CR0: 0x80010033, CR2: 0x00000038, CR3: 0x010db000, CR4: 0x00000660
EAX: 0x00000000, EBX: 0x00000002, ECX: 0x21000001, EDX: 0x11a324d0
CR2: 0x00000038, EBP: 0x5b2bf7b8, ESI: 0x134af404, EDI: 0x00000000
EFL: 0x00010246, EIP: 0x00c52a17, CS: 0x00000008, DS: 0x06a20010
Error code: 0x00000000

Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
0x5b2bf568 : 0x12b4f3 (0x45b13c 0x5b2bf59c 0x1335e4 0x0)
0x5b2bf5b8 : 0x1a9c68 (0x464700 0xc52a17 0xe 0x463eb0)
0x5b2bf698 : 0x1a038d (0x5b2bf6b0 0x53f0c0 0x5b2bf7b8 0xc52a17)
0x5b2bf6a8 : 0xc52a17 (0xe 0x132a0048 0x12130070 0xa770010)
0x5b2bf7b8 : 0x1f2c7d (0x5b2bf7d8 0x2 0x5b2bf808 0x451c8a)
0x5b2bf808 : 0x1d464c (0x11a324d0 0x5b2bfa18 0x5b2bfb2c 0x757de84)
0x5b2bf898 : 0x1d53d1 (0x5b2bfa00 0x100 0x5b2bfa20 0x0)
0x5b2bf958 : 0x1c3578 (0x5b2bfa00 0x6e92980 0x0 0x0)
0x5b2bff78 : 0x3df460 (0x6a29338 0x757dd80 0x757ddc4 0x68ee2c0)
0x5b2bffc8 : 0x1a0887 (0x6fad400 0x0 0x10 0x6fad400)
No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0xb02d94f8
Kernel loadable modules in backtrace (with dependencies):
com.apple.filesystems.autofs(2.0.1)@0xc50000->0xc5afff

BSD process name corresponding to current thread: Acrobat

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: MacBook4,1 (Mac-F22788A9)