Date: Sun, 6 Jul 2014 21:07:47 +0000 From: Steve Wills <swills@freebsd.org> To: Neel Natu <neelnatu@gmail.com> Cc: "freebsd-virtualization@freebsd.org" <virtualization@freebsd.org>, "current@freebsd.org" <current@freebsd.org> Subject: Re: tmpfs panic Message-ID: <20140706210746.GA85257@mouf.net> In-Reply-To: <CAFgRE9E0aTwDk_KMkwSi4OF0VJPhGVh-TdDTO0nQP66UC_ZBNQ@mail.gmail.com> References: <20140706135333.GA80856@mouf.net> <20140706154621.GA81830@mouf.net> <CAFgRE9E0aTwDk_KMkwSi4OF0VJPhGVh-TdDTO0nQP66UC_ZBNQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <swills@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140706210746.GA85257>