Bug Report - Kernel Panic with 64-bit Solaris 10

[scott_lowe1]

(Refer to parallel topic "Control 32-bit/64-bit status?")

Attempting to install Solaris 10 x86 on Core 2 Duo MacBook Pro causes kernel panic as soon as the Solaris kernel initializes in the VM. This is Solaris 6/06 (Update 2, I believe?).

Regards,

Scott

[admin]

Scott, you've probably already done this, but would you put in a support request about this issue if not? (Because I'm not a member of the Fusion team, I'm not in a position to shed any light on the issue; sorry.)

Be sure to say whether it's a Mac OS (host) kernel panic or a Solaris (guest) kernel panic. Any traceback details you can report could be helpful.

[rcardona2k]

I would think this is a VMM issue affecting Workstation 6 equally, albeit I'm unsure of the status of the Fusion VMM version vs. Workstation 6.

Here's a posting from another virtualization product:

The Solaris 10 issue has been discussed in the public VPC 2004 newsgroup.

If you can get your hands on the 03/05 release of Solaris 10 for x86, it

WILL install on both VPC 2004 and 2007. The 01/06 release and all later

releases will not.

If you do not already have the 03/05 release, the ONLY way to obtain it is

to call Sun and order Part No. SOLZ9-10AC9A7M. This is for DVD-ROM media.

The phone number for ordering will vary based on your country and type of

customer you are (e.g. government, corporate, individual, etc.) so check the

Sun site for the appropriate phone number. In the U.S. it should cost

somewhere in the neighborhood of $50-75.

Do NOT waste your time trying to find 03/05 online for download. (Someone is

guaranteed to ignore this and valiantly attempt to find a way to download

older versions. Sorry, Sun simply does not allow it.)

[admin]

Scott's original post left open the possibility that he was experiencing a host panic, not a guest panic (as described in that VPC posting). Let's hope it's the latter! Scott, can you confirm?

Needless to say, panics in the host OS, if they were in fact occurring, would be exceptionally important to resolve.

[scott_lowe1]

This is indeed a host OS kernel panic, not a guest OS panic. The problem is repeatable (I had it happen multiple times at exactly the same point) and is most definitely related to the fact that Solaris 10 (this is the 6/06 release) is trying to boot a 64-bit kernel.

Some background information:

\- The ISOs I'm using to install Solaris 10 have been used successfully a number of times to create VMs running on ESX on CPUs without 64-bit support. In those instances, Solaris attempts to boot a 32-bit kernel (successfully) and everything seems to work fine.

\- The laptop I'm using is a new MacBook Pro with the Core 2 Duo CPU with both the Intel VT and 64-bit extensions enabled, as best I can tell.

\- Solaris definitely attempts to boot a 64-bit kernel on my MBP, even using the exact same ISOs (as mentioned above) as used to build 32-bit Solaris 10 VMs.

\- When I add monitor_control.disable_longmode = 1 to the VMX file for this VM, Solaris no longer attempts to boot a 64-bit kernel (booting a 32-bit kernel instead) and the host OS kernel panic does not occur.

I will file a support request with the Fusion team and continue from there.

Please let me know if anyone needs any additional information.

Regards,

Scott

[admin]

Hi Scott, if you remember from before -- or don't mind trying this again -- does the machine show onscreen further info about the panic, or just the grey multilingual "you need to restart your computer"? If it has a call stack or assert message or any text about where in the kernel it panicked, that would be most helpful. Thanks!

[rcardona2k]

The file you want with the details of the kernel panic is /Library/Logs/panic.log. Its contents look like:

Sun Jun 4 14:10:03 2006

panic(cpu 1 caller 0x0019CAEF): Unresolved kernel trap (CPU 1, Type 14=page fault), registers:

CR0: 0x8001003b, CR2: 0x00000000, CR3: 0x00d55000, CR4: 0x000026a0

EAX: 0x02e74800, EBX: 0x02892d80, ECX: 0x0076d180, EDX: 0x02d84c00

ESP: 0x00000000, EBP: 0x13d8b958, ESI: 0x00000000, EDI: 0x0076c642

EFL: 0x00010202, EIP: 0x00000000, CS: 0x00000008, DS: 0x00000010

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

0x13d8b7f4 : 0x128b5e (0x3bbeb8 0x13d8b818 0x131bbc 0x0)

0x13d8b834 : 0x19caef (0x3c1340 0x1 0xe 0x3c10f8)

0x13d8b8e4 : 0x197b53 (0x13d8b8f8 0x13d8b958 0x0 0x13d80048)

0x13d8b8f0 : 0x0 (0x13d80048 0x3a0010 0x27e0010 0x10)

0x13d8b958 : 0x38e108 (0x2931e00 0x2e74800 0x0 0x0)

0x13d8b998 : 0x76d140 (0x2892d80 0x76c642 0x2e74800 0x0)

0x13d8b9f8 : 0x38e108 (0x2931e00 0x29f4c00 0x0 0x0)

0x13d8ba38 : 0x76df85 (0x2890a40 0x76c56a 0x29f4c00 0x0)

0x13d8ba68 : 0x76b168 (0x2931e00 0x29f4c00 0xffffffff 0x0)

0x13d8bab8 : 0x55dcf8 (0x29f4c00 0x0 0x29f4c50 0x13bd34)

0x13d8bad8 : 0x55c900 (0x2893480 0x0 0x429d40 0x3aeb9d)

0x13d8bb28 : 0x55cd0b (0x2a21c00 0xa000005 0x7 0x2000)

0x13d8bb68 : 0x1e3b49 (0xa000005 0x7 0x2000 0x309a3e8)

0x13d8bbd8 : 0x1d7987 (0x13d8bc08 0x2e50bdc 0x13d8bc38 0x1c321e)

0x13d8bc38 : 0x1d1edb (0x2e50bdc 0x7 0x13d8bf68 0x13d8bf68)

0x13d8bc88 : 0x1c9c96 (0x13d8bcd8 0x13d8be4c 0x13d8be8c 0x0) Backtrace continues...

Kernel loadable modules in backtrace (with dependencies):

com.apple.iokit.IOBluetoothSerialManager(1.7.3f4)@0x768000

dependency: com.apple.iokit.IOSerialFamily(9.0.0d30)@0x558000

com.apple.iokit.IOSerialFamily(9.0.0d30)@0x558000

Kernel version:

Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386

*********

[scott_lowe1]

Here's the contents of the last panic.log that I have:

Sun Nov 12 18:48:32 2006

panic(cpu 1 caller 0x4EAA20BB): vmmon: ASSERT bora/modules/vmmon/macos/pageHiddenMap.cpp:751

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

0x2513bac8 : 0x128d08 (0x3c9afc 0x2513baec 0x131de5 0x0)

0x2513bb08 : 0x4eaa20bb (0x4eaad208 0x4eaad1e8 0x2513bb30 0x2513bb30)

0x2513bc48 : 0x4eaa20df (0x3e2d9 0x0 0x2513bc78 0x19218e)

0x2513bc78 : 0x4eaa53fa (0x4eaad248 0x4eaada4c 0x2ef 0x0)

0x2513bcd8 : 0x4eaa459a (0x3e2d9 0x2513bcfc 0x624c440 0xd000)

0x2513bd08 : 0x4eaa2d54 (0x3e2d9 0xb03855cc 0x0 0x80)

0x2513bd68 : 0x1ef46e (0x9000001 0x80085617 0x2513beb8 0x3)

0x2513bda8 : 0x1e62f0 (0x2513bdd0 0x297 0x2513be08 0x4d9fbb8)

0x2513be08 : 0x1de149 (0x5807000 0x80085617 0x2513beb8 0x3)

0x2513be58 : 0x330669 (0x5816b70 0x80085617 0x2513beb8 0x4d9fbb8)

0x2513be88 : 0x34e9c5 (0x5816b70 0x80085617 0x2513beb8 0x4d9fbb8)

0x2513bf58 : 0x3787be (0x4d9fbb8 0x43c52b0 0x43c52f4 0x0)

0x2513bfc8 : 0x19acde (0x433e9a0 0x0 0x10 0x433e9a0) No mapping exists for frame pointer

Backtrace terminated-invalid frame pointer 0xb0385588

Kernel loadable modules in backtrace (with dependencies):

com.vmware.kext.vmmon(1.0.0d1)@0x4eaa1000

Kernel version:

Darwin Kernel Version 8.8.2: Thu Sep 28 20:43:26 PDT 2006; root:xnu-792.14.14.obj~1/RELEASE_I386

*********

Sun Nov 12 23:11:11 2006

panic(cpu 0 caller 0x4E70A0BB): vmmon: ASSERT bora/modules/vmmon/macos/pageHiddenMap.cpp:751

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

0x2517bac8 : 0x128d08 (0x3c9afc 0x2517baec 0x131de5 0x0)

0x2517bb08 : 0x4e70a0bb (0x4e715208 0x4e7151e8 0x2517bb30 0x2517bb30)

0x2517bc48 : 0x4e70a0df (0x3d141 0x0 0x2517bc78 0x19218e)

0x2517bc78 : 0x4e70d3fa (0x4e715248 0x4e715a4c 0x2ef 0x0)

0x2517bcd8 : 0x4e70c59a (0x3d141 0x2517bcfc 0x458ae6c 0x2517bd6c)

0x2517bd08 : 0x4e70ad54 (0x3d141 0xb03855cc 0x0 0xe5)

0x2517bd68 : 0x1ef46e (0xb000001 0x80085617 0x2517beb8 0x3)

0x2517bda8 : 0x1e62f0 (0x2517bdd0 0x297 0x2517be08 0x48f37d0)

0x2517be08 : 0x1de149 (0x5086b58 0x80085617 0x2517beb8 0x3)

0x2517be58 : 0x330669 (0x49a5fb0 0x80085617 0x2517beb8 0x48f37d0)

0x2517be88 : 0x34e9c5 (0x49a5fb0 0x80085617 0x2517beb8 0x48f37d0)

0x2517bf58 : 0x3787be (0x48f37d0 0x457e158 0x457e19c 0x0)

0x2517bfc8 : 0x19acde (0x42e1c80 0x0 0x10 0x0) No mapping exists for frame pointer

Backtrace terminated-invalid frame pointer 0xb0385588

Kernel loadable modules in backtrace (with dependencies):

com.vmware.kext.vmmon(1.0.0d1)@0x4e709000

Kernel version:

Darwin Kernel Version 8.8.2: Thu Sep 28 20:43:26 PDT 2006; root:xnu-792.14.14.obj~1/RELEASE_I386

*********

As you can see, I tried a couple of times.

I also tried to recreate the problem again this morning, and cannot. Every time I boot a new Solaris image, it boots the 32-bit kernel (which works just fine). I'm not sure if the 64-bit support in my CPU has been disabled or not recognized, but ever since adding the monitor_control.disable_longmode parameter to the VMX file for the other Solaris system I have not been able to recreate the problem, even with new VMs. (BTW, the old VM dies at boot when I remove that parameter from the VMX file.)

I will continue to see if I can recreate the problem.

Regards,

Scott

[bgertzfield]

Hi eplus_slowe,

You'll be happy to hear that the kernel panic issue has been fixed. The fix will be available in the next release.

There is a known issue with some Apple hardware where the Intel VT extensions are not reliably enabled on all CPU cores. This may be causing your OS to default to 32-bit behavior.

[scott_lowe1]

Ben,

Thanks for the update. Is there a way to determine if the VT extensions (and/or the 64-bit extensions, which I thought were different features, yes?) are enabled? Anybody know of a fix for enabling the extensions?

Scott

[bgertzfield]

On Intel CPUs, VMware utilizes VT extensions for 64-bit guest support.

I think there may be some free utility out there that can tell you what extensions are enabled on a per-CPU basis, but I can't remember the name offhand.

[rcardona2k]

You might want to see if Solaris 10 Update 3 (11/06) is any better. I read that this was just released.

[rcardona2k]

Look for CPUID in this thread:

http://www.vmware.com/community/thread.jspa?messageID=514631

It describes Intel's MacCPUID utility for OS X.