From owner-freebsd-current@FreeBSD.ORG Sun Jul 6 21:07:57 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A2CD8E5; Sun, 6 Jul 2014 21:07:57 +0000 (UTC) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A0952587; Sun, 6 Jul 2014 21:07:57 +0000 (UTC) Received: from mouf.net (swills@mouf [199.48.129.64]) by mouf.net (8.14.5/8.14.5) with ESMTP id s66L7lI5087928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Jul 2014 21:07:52 GMT (envelope-from swills@mouf.net) Received: (from swills@localhost) by mouf.net (8.14.5/8.14.5/Submit) id s66L7lQn087927; Sun, 6 Jul 2014 21:07:47 GMT (envelope-from swills) Date: Sun, 6 Jul 2014 21:07:47 +0000 From: Steve Wills To: Neel Natu Subject: Re: tmpfs panic Message-ID: <20140706210746.GA85257@mouf.net> References: <20140706135333.GA80856@mouf.net> <20140706154621.GA81830@mouf.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Sun, 06 Jul 2014 21:07:52 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mouf.net X-Virus-Scanned: clamav-milter 0.98.1 at mouf.net X-Virus-Status: Clean Cc: "freebsd-virtualization@freebsd.org" , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 21:07:57 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 06, 2014 at 01:49:04PM -0700, Neel Natu wrote: > Hi Steve, >=20 > On Sun, Jul 6, 2014 at 8:46 AM, Steve Wills wrote: > > I should have noted this system is running in bhyve. Also I'm told this= panic > > may be related to the fact that the system is running in bhyve. > > > > Looking at it a little more closely: > > > > (kgdb) list *__mtx_lock_sleep+0xb1 > > 0xffffffff809638d1 is in __mtx_lock_sleep (/usr/src/sys/kern/kern_mutex= =2Ec:431). > > 426 * owner stops running or the state of the lock= changes. > > 427 */ > > 428 v =3D m->mtx_lock; > > 429 if (v !=3D MTX_UNOWNED) { > > 430 owner =3D (struct thread *)(v & ~MTX_FL= AGMASK); > > 431 if (TD_IS_RUNNING(owner)) { > > 432 if (LOCK_LOG_TEST(&m->lock_obje= ct, 0)) > > 433 CTR3(KTR_LOCK, > > 434 "%s: spinning on %p= held by %p", > > 435 __func__, m, owner); > > (kgdb) > > > > I'm told that MTX_CONTESTED was set on the unlocked mtx and that MTX_CO= NTENDED > > is spuriously left behind, and to ask how lock prefix is handled in bhy= ve. Any > > of that make sense to anyone? > > >=20 > Regarding the lock prefix: since bhyve only supports hardware that has > nested paging, the hypervisor doesn't get in the way of instructions > that access memory. This includes instructions with lock prefixes or > any other prefixes for that matter. If there is a VM exit due to a > nested page fault then the faulting instruction is restarted after > resolving the fault. >=20 > Having said that, there are more plausible explanations that might > implicate bhyve: incorrect translations in the nested page tables, > stale translations in the TLB etc. >=20 > Do you have a core file for the panic? It would be very useful to > debug this further. No, unfortunately I did not have swap or dumpdev setup at the time so I was unable to get a core dump from the crashed kernel. (Bhyve did not crash.) I= 've setup swap in the VM and set the dumpdev as well, so if it happens again I should get a core. Steve --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTubqhAAoJEPXPYrMgexuhGaEIAIPXiqXQoTRWwFWOfiYAuk3Q lTXzSniPbGlogInzSP7F1ZqmYEqdABLnPUYN5oThqG2xbhVky1dJiGsS6gDeNY1e wrWRM77WWPuhPrZduXHUGb0ppBvuXaknoGGep21rTsKMspRCbBk75bEdKlfvskpF 9cl0DdfCPdkpJg3/sv6hIMDNv62vkK3lYHLdBMrWoGaO+aBJ7+SDPb3J5k8yGBMf UhJKE5eOfVKYJnGMdNKZ1vjfEC85BtRbQnLLJOM5M7EYxHRmddo2UFddPcqtr5JO PN3sHwQl64MEXswnxHyyPhjUhKXia1Xqd+nOIwts2rcfioZsiLyV6KIkqrou05s= =ljLU -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g--