Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Jul 2014 18:04:45 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Steve Wills <swills@freebsd.org>
Cc:        virtualization@freebsd.org, current@freebsd.org
Subject:   Re: tmpfs panic
Message-ID:  <20140714150445.GJ93733@kib.kiev.ua>
In-Reply-To: <20140706154621.GA81830@mouf.net>
References:  <20140706135333.GA80856@mouf.net> <20140706154621.GA81830@mouf.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--tby8mjhWFMo012j0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 06, 2014 at 03:46:22PM +0000, Steve Wills wrote:
> I should have noted this system is running in bhyve. Also I'm told this p=
anic
> may be related to the fact that the system is running in bhyve.
>=20
> Looking at it a little more closely:
>=20
> (kgdb) list *__mtx_lock_sleep+0xb1
> 0xffffffff809638d1 is in __mtx_lock_sleep (/usr/src/sys/kern/kern_mutex.c=
:431).
> 426                      * owner stops running or the state of the lock c=
hanges.
> 427                      */
> 428                     v =3D m->mtx_lock;
> 429                     if (v !=3D MTX_UNOWNED) {
> 430                             owner =3D (struct thread *)(v & ~MTX_FLAG=
MASK);
> 431                             if (TD_IS_RUNNING(owner)) {
> 432                                     if (LOCK_LOG_TEST(&m->lock_object=
, 0))
> 433                                             CTR3(KTR_LOCK,
> 434                                                 "%s: spinning on %p h=
eld by %p",
> 435                                                 __func__, m, owner);
> (kgdb)=20
>=20
> I'm told that MTX_CONTESTED was set on the unlocked mtx and that MTX_CONT=
ENDED
> is spuriously left behind, and to ask how lock prefix is handled in bhyve=
=2E Any
> of that make sense to anyone?
>=20
> Thanks,
> Steve
>=20
> On Sun, Jul 06, 2014 at 01:53:37PM +0000, Steve Wills wrote:
> > Hi,
> >=20
> > Just experienced this tmpfs panic on r268160:
> >=20
> > Freed UMA keg (TMPFS node) was not empty (16 items).  Lost 1 pages of m=
emory.
> >=20
> >=20
> > Fatal trap 12: page fault while in kernel mode
> > cpuid =3D 12; apic id =3D 0c
> > fault virtual address   =3D 0x378
> > fault code              =3D supervisor read data, page not present
> > instruction pointer     =3D 0x20:0xffffffff809638d1
> > stack pointer           =3D 0x28:0xfffffe07243800a0
> > frame pointer           =3D 0x28:0xfffffe0724380120
> > code segment            =3D base 0x0, limit 0xfffff, type 0x1b
> >                         =3D DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags        =3D interrupt enabled, resume, IOPL =3D 0
> > current process         =3D 65339 (pkg-static)
> > [ thread pid 65339 tid 101641 ]
> > Stopped at      __mtx_lock_sleep+0xb1:  movl    0x378(%rax),%ecx
> > db> bt
> > Tracing pid 65339 tid 101641 td 0xfffff80286b2e490
> > __mtx_lock_sleep() at __mtx_lock_sleep+0xb1/frame 0xfffffe0724380120
> > free_unr() at free_unr+0x9d/frame 0xfffffe0724380160
> > tmpfs_free_node() at tmpfs_free_node+0xf2/frame 0xfffffe07243801a0
> > tmpfs_reclaim() at tmpfs_reclaim+0xdc/frame 0xfffffe07243801d0
> > VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xa7/frame 0xfffffe0724380200
> > vgonel() at vgonel+0x24c/frame 0xfffffe0724380280
> > vrecycle() at vrecycle+0x84/frame 0xfffffe07243802c0
> > tmpfs_inactive() at tmpfs_inactive+0x18/frame 0xfffffe07243802d0
> > VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xa7/frame 0xfffffe0724380300
> > vinactive() at vinactive+0x181/frame 0xfffffe0724380360
> > vputx() at vputx+0x30d/frame 0xfffffe07243803d0
> > vn_close() at vn_close+0x13e/frame 0xfffffe0724380450
> > vn_closefile() at vn_closefile+0x48/frame 0xfffffe07243804d0
> > _fdrop() at _fdrop+0x29/frame 0xfffffe07243804f0
> > closef() at closef+0x2ae/frame 0xfffffe0724380580
> > fdescfree() at fdescfree+0x64c/frame 0xfffffe0724380630
> > exit1() at exit1+0x682/frame 0xfffffe07243806c0
> > sigexit() at sigexit+0x929/frame 0xfffffe0724380980
> > postsig() at postsig+0x3c4/frame 0xfffffe0724380a70
> > ast() at ast+0x487/frame 0xfffffe0724380ab0
> > doreti_ast() at doreti_ast+0x1f/frame 0x7fffffffc6e0
> > db>=20
> >=20
> > Any further debugging I can do?
> >=20
> > Thanks,
> > Steve
>=20
>=20


This is supposedly fixed with r268617.

--tby8mjhWFMo012j0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJTw/GMAAoJEJDCuSvBvK1BOVoP+wT6cFd+bEPrId4k2CXtd8Gm
RP34XpfopJaGiTl56W8ETIop+bVO6t9Z6uVmky2N1rVUaJqTfiAXuNBTCLG4U8Rd
uNO/kK1D6G/Y1ZzW8P5QxVomdaabF/k2HWYa08UV+0Yl5QXrhIa0eaxccP6TBISz
V8/HTXj2VvkXDBuQsquc6k10OGxZjmaj113TCoRBUXCKGgMk0kGb15PN7zefbr5Y
bJXgf49WU5AJp2M2Dmpk2JFjXJ8GSapo/FdQVTxHfAdGa2sV3Vl0i8lWiFqm7oaf
a1irBQwdV6HTvoIg1OXviOk30ZFRQ/UfVRxsXVU0QmDCe4aLJc1uGwndr8XeJmaP
J/CJEidDQJA8oVGaTL7UvOkExgQpDm6RXvh8/pVkbo1Lw1EmVhnaSBWAXR1zSIap
ORZ7UNGD6p76GEn4Ic2HfgFsnTeDuw8sFdPaIJYzWJrucZciWFS17EpOHeVLxxJ7
FRCKeRoPwXqyaxZJHpSdx6KGrKeVNNS+D24bPqORSLyO4lfbXmiR4PLl3lDyNY/d
K9jXoZVOxtdHUU/ulU7jEOtAshvAyv2nxPUmfiiVlJIs1QybSY+8bEOgL6/OYzUD
r8wHuq92gSg7OXOYzgI1ECA2znHjP5zydSgkgiz8d53Ok09S3JfviG/4b8pgsVUf
1yXg13mE3Kop9kjYWUY8
=74qe
-----END PGP SIGNATURE-----

--tby8mjhWFMo012j0--



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