10.4.8 Kernel Panic with Fusion kexts loaded on mini & mbp

[kaolson]

Starting a new thread on the mini & macbook pro kernel panics (was part of this thread: http://www.vmware.com/community/thread.jspa?threadID=68256&tstart=0).

I can reliably reproduce a kernel panic in 10.4.8 by ejecting a volume mounted from a host system (default afp mount) that is either of two macintel systems with Fusion installed. (mini & mbp).

Problem started when I installed Fusion, went away when I de-installed. Both systems also have Parallels (Build 3120) installed. The workaround of unloading the networking kexts (sudo /Library/Application\ Support/VMware\ Fusion/boot.sh --stop) works ok (they can be re-loaded by executing the command with a "start" replacing "stop").

Exact steps:

From one system connect to another with Fusion installed (and kexts loaded).

In the Finder, follow the Network path to the system with Fusion installed and connect, selecting the home directory of the user as whom you're connecting. Then disconnect by ejecting the mount point in the Finder window. System with Fusion installed panics.

These systems are both connected on en0, no AppleTalk, DHCP from a DLink router, and have Parallels Build 3120 installed. Neither system evidenced any problem until Fusion was installed. Fusion is configured for Bridged Networking.

Will post the dump from the last kernel panic as soon as I can get one. The mini has taken to kp'ing when it reboots now, so the trace is from that, not the network dismount.

-K

[kaolson]

Here's the trace:

panic(cpu 0 caller 0x0035BEAC): freeing free mbuf

Backtrace, Format - Frame : Return Address (4 potential args on stack)

0x25123c18 : 0x128d1f (0x3c9540 0x25123c3c 0x131df4 0x0)

0x25123c58 : 0x35beac (0x3e9c7c 0x38849b4 0x36cbe642 0x1)

0x25123c98 : 0x6af4a4 (0x36cc0700 0x35 0x25123cd8 0x23b81e)

0x25123cb8 : 0x980454 (0x237c7000 0x36cc0700 0x0 0xb0d828ce)

0x25123ce8 : 0x97ead0 (0x237c7000 0x36cc0700 0x0 0x4b7000)

0x25123d08 : 0x98a87d (0x237c7000 0x36cbe600 0x56 0x378e5b8)

0x25123ea8 : 0x981c7c (0x237c7000 0x38af800 0x40000000 0x133b25)

0x25123f08 : 0x398a1f (0x237c7000 0x38af800 0x1 0x378b640)

0x25123f58 : 0x397bf1 (0x38af800 0x135ec3 0x0 0x378b640)

0x25123f88 : 0x397927 (0x38b26c0 0x0 0x25123fc8 0x202b3f)

0x25123fc8 : 0x19a74c (0x38b26c0 0x0 0x19d0b5 0x4012348) Backtrace terminated-invalid frame pointer 0x0

Kernel loadable modules in backtrace (with dependencies):

com.apple.iokit.AppleYukon(1.0.7b3)@0x97c000

dependency: com.apple.iokit.IONetworkingFamily(1.5.1)@0x6a8000

dependency: com.apple.iokit.IOPCIFamily(2.1)@0x57c000

com.apple.iokit.IONetworkingFamily(1.5.1)@0x6a8000

Kernel version:

Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386

Model: Macmini1,1, BootROM MM11.0055.B08, 2 processors, Intel Core Duo, 1.66 GHz, 2 GB

Graphics: Intel GMA 950, GMA 950, Built-In, spdisplays_integrated_vram

Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz

Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz

AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), 0.1.27

Bluetooth: Version 1.7.9f12, 2 service, 0 devices, 1 incoming serial ports

Network Service: Built-in Ethernet, Ethernet, en0

Network Service: Parallels Host-Guest, Ethernet, en2

Network Service: Parallels NAT, Ethernet, en3

Serial ATA Device: ST9100824AS, 93.16 GB

Parallel ATA Device: MATSHITADVD-R UJ-846

USB Device: Hub in Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/sec, 500 mA

USB Device: Apple Optical USB Mouse, Mitsumi Electric, Up to 1.5 Mb/sec, 100 mA

USB Device: Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/sec, 250 mA

USB Device: Bluetooth HCI, Up to 12 Mb/sec, 500 mA

USB Device: IR Receiver, Apple Computer, Inc., Up to 12 Mb/sec, 500 mA

FireWire Device: unknown_device, unknown_value, Up to 400 Mb/sec

[admin]

Cool!

Before you can reproduce this the next time, can you capture the output of "sudo kextstat" for us? Then also send us the panic log after the panic happens.

Also, I'm assuming you have the Fusion public beta build 36932 installed?

Thanks! We'll get to the bottom of this and fix this!

[kaolson]

36932 it is.

Here's output from kextstat:

Index Refs Address Size Wired Name (Version)

And the kp report:

panic(cpu 0 caller 0x0035BEAC): freeing free mbuf

Backtrace, Format - Frame : Return Address (4 potential args on stack)

0x251fbdb8 : 0x128d1f (0x3c9540 0x251fbddc 0x131df4 0x0)

0x251fbdf8 : 0x35beac (0x3e9c7c 0x441838 0x0 0x19778c)

0x251fbe38 : 0x6af4a4 (0x36c4ce00 0x0 0x237c7000 0x237c7000)

0x251fbe58 : 0x980454 (0x237c7000 0x36c4ce00 0x0 0x2)

0x251fbe88 : 0x97ead0 (0x237c7000 0x36c4ce00 0x0 0x38c9d00)

0x251fbea8 : 0x981d7c (0x237c7000 0x0 0x40000000 0x0)

0x251fbf08 : 0x398a1f (0x237c7000 0x38c9d00 0x1 0x3789b20)

0x251fbf58 : 0x397bf1 (0x38c9d00 0x0 0x251fbf98 0x0)

0x251fbf88 : 0x397927 (0x38caf00 0x0 0x251fbfc8 0x202b3f)

0x251fbfc8 : 0x19a74c (0x38caf00 0x0 0x19d0b5 0x378bd08) Backtrace terminated-invalid frame pointer 0x0

Kernel loadable modules in backtrace (with dependencies):

com.apple.iokit.AppleYukon(1.0.7b3)@0x97c000

dependency: com.apple.iokit.IONetworkingFamily(1.5.1)@0x6a8000

dependency: com.apple.iokit.IOPCIFamily(2.1)@0x57c000

com.apple.iokit.IONetworkingFamily(1.5.1)@0x6a8000

Kernel version:

Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386

Model: Macmini1,1, BootROM MM11.0055.B08, 2 processors, Intel Core Duo, 1.66 GHz, 2 GB

Graphics: Intel GMA 950, GMA 950, Built-In, spdisplays_integrated_vram

Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz

Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz

AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), 0.1.27

Bluetooth: Version 1.7.9f12, 2 service, 0 devices, 1 incoming serial ports

Network Service: Built-in Ethernet, Ethernet, en0

Network Service: Parallels Host-Guest, Ethernet, en2

Network Service: Parallels NAT, Ethernet, en3

Serial ATA Device: ST9100824AS, 93.16 GB

Parallel ATA Device: MATSHITADVD-R UJ-846

USB Device: Bluetooth HCI, Up to 12 Mb/sec, 500 mA

USB Device: IR Receiver, Apple Computer, Inc., Up to 12 Mb/sec, 500 mA

USB Device: Hub in Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/sec, 500 mA

USB Device: Apple Optical USB Mouse, Mitsumi Electric, Up to 1.5 Mb/sec, 100 mA

USB Device: Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/sec, 250 mA

FireWire Device: unknown_device, unknown_value, Up to 400 Mb/sec

And, in case it's helpful, boot.sh--stop, which makes problem go away:

VMware Fusion 36932: Shutting down VMware Fusion:

No matching processes were found

kextunload: unload kext /Library/Application Support/VMware Fusion/kexts/vmmon.kext succeeded

kextunload: unload kext /Library/Application Support/VMware Fusion/kexts/vmioplug.kext succeeded

kextunload: unload kext /Library/Application Support/VMware Fusion/kexts/vmnet.kext succeeded

Thanks!

-K

[kaolson]

Had a chance to do a tad more testing, in case it helps:

1. From windoze, disconnecting a mapped drive does not seem to cause the KP but then I'm not sure the disconnect worked completely: the mapped drive continued to show in the Disconnect Mapped Drive window but was not clickable after the first time.

2. From OS X, ejecting a mounted windoze share from the Finder did cause immediate kp (on the host of the mounded share).

3. Either windows or OS X, logging off or shutting down with a windows share or OS X volume opened does \_not_ cause kp.

If I get a chance, might test via the umount command instead of the Finder.

-K

[kaolson]

If I get a chance, might test via the umount command

instead of the Finder.

Yep, umount causes the kp too.

[admin]

Hi kaolson,

Can you post the panic log from this latest kernel panic too? Thanks!

[admin]

Also a small clarification:

1. Was the Windows share from an external Windows host on the physical network?

2. How did you mount the Windows share from Mac OS X?

I tried mounting an external Windows host's share using the Mac OS X Finder's "Connect to Server" method, with the URL "cifs://...". I tried the Eject button, as well as "sudo umount", but couldn't reproduce the panics on my MacBook Pro. Same build of Fusion (36932).

Thanks!

[kaolson]

Hi kaolson,

Can you post the panic log from this latest kernel

panic too? Thanks!

The umount command?

Did a different test:

With the mini still the Fusion host, connected from two other 10.4.8 systems, call them A and B.

From A, I separately mounted the user's home and the hd from the mini.

From B, I mounted the user's home.

Then, trying disconnecting in different sequences, I discovered that the kp occurs when the \_last_ mount is disconnected from each system, without regard to sequence. Ie, dismounting from A, the kp occurred when I ejected first one then the other (in any sequence). Dismounting from B always caused the kp since there was only one mount to B. Did this in various orders (first one from A, then B; then two from A; etc). Only significance appeared to be when the last of any number of mounts from a given system was ejected.

Also noted, that when I'd generated the kp by ejecting B's mount and there was still one left on A, while the mini was rebooting I ejected the last mount on A. This caused the typical Finder hang with spinning beachball while it tried the network connection. Apparently it was still trying when the mini came up because it kp'd again about when I'd logged on.

Ok, I know that's way more than you asked for.

You want the panic log from the umount kp?

-K

[admin]

Yes, the panic log from the umount kernel panic. Also as I asked in my previous post, the scenario that led up to the kernel panic (i.e. where was the Windows share? what method did you use to mount it? etc.)

Just one more question: the AirPort NIC is completely out of the picture in all these kernel panics, right? You're connected exclusively over the wired ethernet NIC? Thanks!

[kaolson]

Also a small clarification:

1. Was the Windows share from an external Windows

host on the physical network?

Hmm, not sure I get the question exactly. I have a mini with Parallels and Fusion installed and a MBP same. And a few other macs. All on the same segment. The macintels are on en0 right now.

I'm mounting points on the mini -- either afp or smb/cifs -- from the mbp (dont particularly want the mbp kp'ing right now but did demonstrate same symptoms on it) -- either afp or smb/cifs. So all the kp's right now are the mini's and all the mounts are from either OS X on the mbp or windows in a vm on the mbp.

2. How did you mount the Windows share from Mac OS

X?

Everything's in the same workgroup and each windows system has a share defined. Finder browse: Network/workgroup/system and logged in. The share appears in the Finder sidebar and on desktop, etc.

I tried mounting an external Windows host's share

using the Mac OS X Finder's "Connect to Server"

method, with the URL "cifs://...". I tried the Eject

button, as well as "sudo umount", but couldn't

reproduce the panics on my MacBook Pro. Same build of

Fusion (36932).

Not sure exactly what an "external Windows host" is, but if it's not running in a vm on a macintel with Fusion's kexts installed, you wont see the kp.

I can see we're posting over each other. But I have some time right now if you do to try to iron it out a bit.

-K

[kaolson]

Will do. It'll take a few minutes...

[admin]

Awesome!

So I had misunderstood who was exporting a share and who was mounting it earlier. So basically the Mac OS X "server" exporting the share (in your case, the mini) is the one panicking.

I was able to reproduce this, with my MBP exporting an AFP share, and mounting and ejecting the share from another mini. Couldn't ask for more!

Stay tuned....

[kaolson]

Ah, sorry about that.

Just mounted an os x volume on the mini via the workgroup, meaning it used smb/cifs to mount the vol. When I ejected it, it did \_not_ panic. Would seem to indicate an afp thingie?

Thanks for the effort!

-K

[rcardona2k]

>Would seem to indicate an afp thingie?

I would go further and say it's an Intel-to-Intel AFP 'thingie' or a Fusion host to Fusion host AFP issue.

I've tried relentlessly to reproduce this between a PowerPC G4 and my MacBook Pro to no available. I can cross-mount each other's AFP home directory and unmount all day long. But I do admit the G4 is running OS X 10.3.9 instead of 10.4.8 so that's another possibility: OS X 10.4.8 to OS X 10.4.8 AFP and Fusion networking.

Since VMware has reproduced it, the non-breaking variations above are moot.

[admin]

Here's a hint: it is an IPv6 "thingie"

For some reason, AFP sends/receives IPv6 packets. Looking into it. The good news is that the vmnet driver has been restructured a bit since this last beta (build 36932), so the next beta shouldn't cause panics this way. But obviously we'll be testing to make sure that's the case.

[kaolson]

Here's a hint: it is an IPv6 "thingie"

For some reason, AFP sends/receives IPv6 packets.

Looking into it. The good news is that the vmnet

driver has been restructured a bit since this last

beta (build 36932), so the next beta shouldn't cause

panics this way. But obviously we'll be testing to

make sure that's the case.

Cant wait!

[cchab]

I got the exact same issue:

PowerBook G4 (10.3.9) mount smb share to the mini (Intel - 10.4.8) witch is the Host for Fusion and as soon as I unmount the volume the mini run into Kernel Panic. Event with no VM machine running on the Host...

I guess I will try your next release as soon as available...

[rcardona2k]

As bhaveshdavda says, the fix should be easy enough: disable IPv6 (if you're not using it). I read an OS X hints article that disabling IPv6 speeds up CIFS and AFP transfers. I don't see how IPv6 comes into play with those protocols but whatever works. IPv6 is controlled in System Preferences > Network > TCP/IP > Configure IPv6

[cchab]

Thanks, disabling the IPv6 did the trick. In fact, I did disabled it on all my Macs...