Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Mar 2010 22:01:38 -0600
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Christopher Smith <drsmithy@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: VMDirectPath with FreeBSD 8 VM under ESXi 4.0
Message-ID:  <20100310040138.GI12122@dan.emsphone.com>
In-Reply-To: <3c6517d51003091834h520f7415t7e657bce3e0f9157@mail.gmail.com>
References:  <3c6517d51003091834h520f7415t7e657bce3e0f9157@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Mar 09), Christopher Smith said:
> I wasn't 100% on where this should go, but -hackers seemed like a reasoned
> starting point.
> 
> My overall objective is to setup a ZFS fileserver VM, and for my first
> attempt I am trying to use VMDirectPath (ie: PCI pass-through) with a
> FreeBSD 8.0 VM under ESXi 4 to pass-through the moterboard chipset SATA
> controller (and when I expand in the future, the SAS controller I get). 
> Unfortunately, whenever I add the mapped PCI device to the VM, it powers
> itself off about halfway through the boot sequence.
> 
> I have confirmed it's not a fundamental problem by trying Linux and
> OpenSolaris VMs - both can see the PCI device (an Intel 3420 chipset SATA
> controller) and the drives attached to it.  This problem only occurs with
> the FreeBSD 8.0 (and 7.3RC2) VMs.
> 
> I've also tried booting up the FreeBSD installer DVD on the bare hardware,
> to make sure it's not a problem with that particular controller.
> 
> The relevant part of the vmware.log that is generated is:
> Code:
> 
> Sep 19 05:19:26.676: vcpu-0| PCIPassthru: 000:31.2 : barSize: 2048 is not pgsize multiple
> Sep 19 05:19:26.677: vcpu-0| PCIPassthru: 000:31.2 : barSize: 2048 is not pgsize multiple
> Sep 19 05:19:26.677: vcpu-0| ASSERT bora/vmcore/vmx/main/physMem.c:2148 bugNr=254266
> Sep 19 05:19:30.295: vcpu-0| Backtrace:
> Sep 19 05:19:30.295: vcpu-0| Backtrace[0] 0x5e521d88 eip 0xbbf58ed
> Sep 19 05:19:30.295: vcpu-0| Backtrace[1] 0x5e5221c8 eip 0xb7f405c
> Sep 19 05:19:30.295: vcpu-0| Backtrace[2] 0x5e522218 eip 0xb9cafca
> Sep 19 05:19:30.295: vcpu-0| Backtrace[3] 0x5e522248 eip 0xb9b929e
> Sep 19 05:19:30.295: vcpu-0| Backtrace[4] 0x5e5222a8 eip 0xb9e92fd
> Sep 19 05:19:30.295: vcpu-0| Backtrace[5] 0x5e5222d8 eip 0xb9e9442
> Sep 19 05:19:30.295: vcpu-0| Backtrace[6] 0x5e5222e8 eip 0xb9b8c5d
> Sep 19 05:19:30.295: vcpu-0| Backtrace[7] 0x5e5223c8 eip 0xb8efea1
> Sep 19 05:19:30.295: vcpu-0| Backtrace[8] 0x5e5224b8 eip 0x173a24fb
> Sep 19 05:19:30.295: vcpu-0| Backtrace[9] 00000000 eip 0x17489e3e
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[0] 0x5e521d88 eip 0xbbf58ed in function (null) in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[1] 0x5e5221c8 eip 0xb7f405c in function Panic in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[2] 0x5e522218 eip 0xb9cafca in function (null) in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[3] 0x5e522248 eip 0xb9b929e in function (null) in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[4] 0x5e5222a8 eip 0xb9e92fd in function (null) in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[5] 0x5e5222d8 eip 0xb9e9442 in function (null) in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[6] 0x5e5222e8 eip 0xb9b8c5d in function (null) in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[7] 0x5e5223c8 eip 0xb8efea1 in function (null) in object /bin/vmx loaded at 0xb795000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[8] 0x5e5224b8 eip 0x173a24fb in function (null) in object /lib/libpthread.so.0 loaded at 0x1739d000
> Sep 19 05:19:30.295: vcpu-0| SymBacktrace[9] 00000000 eip 0x17489e3e in function clone in object /lib/libc.so.6 loaded at 0x173b8000
> Sep 19 05:19:30.295: vcpu-0| Msg_Post: Error
> Sep 19 05:19:30.295: vcpu-0| [msg.log.error.unrecoverable] VMware ESX
> unrecoverable error: (vcpu-0)
> Sep 19 05:19:30.295: vcpu-0| ASSERT
> bora/vmcore/vmx/main/physMem.c:2148 bugNr=254266
> Sep 19 05:19:30.295: vcpu-0| [msg.panic.haveLog] A log file is
> available in "/vmfs/volumes/4aaf3595-47d35fcc-a053-0030489f04bf/FreeBSD
> 8.0/vmware.log".  [msg.panic.haveCore] A core file is available in
> "/vmfs/volumes/4aaf3595-47d35fcc-a053-0030489f04bf/FreeBSD
> 8.0/vmx-zdump.003".  [msg.panic.requestSupport.withLogAndCore] Please
> request support and include the contents of the log file and core
> file.  [msg.panic.requestSupport.vmSupport.vmx86]
> Sep 19 05:19:30.296: vcpu-0| To collect data to submit to VMware
> support, run "vm-support".
> Sep 19 05:19:30.296: vcpu-0| [msg.panic.response] We will respond on
> the basis of your support entitlement.

Looks like you crashed VMWare.  That shouldn't happen.  Send the log and
core file to VMWare support and they should be able to help you.

-- 
	Dan Nelson
	dnelson@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100310040138.GI12122>