Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Aug 2014 09:34:49 -0500
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        Larry Rosenman <ler@lerctr.org>, Eric van Gyzen <eric@vangyzen.net>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>, Ryan Stone <rysto32@gmail.com>
Subject:   Re: DEADLKRES crash
Message-ID:  <53F36089.3060102@FreeBSD.org>
In-Reply-To: <d12664f386560280c33894cddc68dcf0@thebighonker.lerctr.org>
References:  <20140818152138.GA3481@borg.lerctr.org> <CAFMmRNyabSni_X_YM2qpJAPi3Gc4WrihVo-LJ6RH8BJMbGWb_g@mail.gmail.com> <53F35449.9050608@vangyzen.net> <d12664f386560280c33894cddc68dcf0@thebighonker.lerctr.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--hdBSpUIBSRdCnQnwsbc6bvL1lC6uTbWqf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 8/19/2014 8:53 AM, Larry Rosenman wrote:
> On 2014-08-19 08:42, Eric van Gyzen wrote:
>> On 08/18/2014 16:45, Ryan Stone wrote:
>>> The first thing that I'd like to see is (in kgdb):
>>>
>>> set $td=3D(struct thread)0xfffff8002abeb000
>>> tid $td->td_tid
>>> bt
>>>
>>> That will show us the backtrace of the thread that was blocked for so=

>>> long.
>>
>> Make that:
>>
>> set $td=3D(struct thread *)0xfffff8002abeb000
>> tid $td->td_tid
>> bt
>>
>>
>> Eric
> #0  doadump (textdump=3D1) at pcpu.h:219
> 219    pcpu.h: No such file or directory.
>     in pcpu.h
> (kgdb) set $td=3D(struct thread *)0xfffff8002abeb000
> Current language:  auto; currently minimal
> (kgdb) tid $td->td_tid
> [Switching to thread 469 (Thread 100681)]#0  sched_switch (
>     td=3D0xfffff8002abeb000, newtd=3D<value optimized out>,
>     flags=3D<value optimized out>) at /usr/src/sys/kern/sched_ule.c:193=
1
> 1931            cpuid =3D PCPU_GET(cpuid);
> (kgdb) bt
> #0  sched_switch (td=3D0xfffff8002abeb000, newtd=3D<value optimized out=
>,
>     flags=3D<value optimized out>) at /usr/src/sys/kern/sched_ule.c:193=
1
> #1  0xffffffff80a107d9 in mi_switch (flags=3D260, newtd=3D0x0)
>     at /usr/src/sys/kern/kern_synch.c:493
> #2  0xffffffff80a4c442 in sleepq_switch (wchan=3D<value optimized out>,=

>     pri=3D<value optimized out>) at /usr/src/sys/kern/subr_sleepqueue.c=
:552
> #3  0xffffffff80a4c2a3 in sleepq_wait (wchan=3D0xfffff80070a4dd50, pri=3D=
96)
>     at /usr/src/sys/kern/subr_sleepqueue.c:631
> #4  0xffffffff809eb1fa in sleeplk (lk=3D<value optimized out>,
>     flags=3D<value optimized out>, ilk=3D<value optimized out>,
>     wmesg=3D<value optimized out>, pri=3D<value optimized out>,
>     timo=3D<value optimized out>) at /usr/src/sys/kern/kern_lock.c:225
> #5  0xffffffff809eaa06 in __lockmgr_args (lk=3D0xfffff80070a4dd50,
>     flags=3D<value optimized out>, ilk=3D0xfffff80070a4dd80,
>     wmesg=3D<value optimized out>, pri=3D<value optimized out>,
>     timo=3D<value optimized out>) at /usr/src/sys/kern/kern_lock.c:931
> #6  0xffffffff8092e092 in nfs_lock1 (ap=3D<value optimized out>) at
> lockmgr.h:97
> #7  0xffffffff80f2d57c in VOP_LOCK1_APV (vop=3D<value optimized out>,
>     a=3D<value optimized out>) at vnode_if.c:2082
> #8  0xffffffff80abd22a in _vn_lock (vp=3D0xfffff80070a4dce8,
>     flags=3D<value optimized out>,
>     file=3D0xffffffff8110db88 "/usr/src/sys/kern/vfs_subr.c", line=3D21=
37)
>     at vnode_if.h:859
> #9  0xffffffff80aad4e7 in vget (vp=3D0xfffff80070a4dce8, flags=3D524544=
,
> ---Type <return> to continue, or q <return> to quit---
>     td=3D0xfffff8002abeb000) at /usr/src/sys/kern/vfs_subr.c:2137
> #10 0xffffffff80aa1491 in vfs_hash_get (mp=3D0xfffff8002aa1e990,
>     hash=3D1741450670, flags=3D<value optimized out>, td=3D0xfffff8002a=
beb000,
>     vpp=3D0xfffffe100c75c670, fn=3D0xffffffff80935820 <newnfs_vncmpf>)
>     at /usr/src/sys/kern/vfs_hash.c:88
> #11 0xffffffff809314bd in ncl_nget (mntp=3D0xfffff8002aa1e990,
>     fhp=3D0xfffff80070ccf4a4 "\001", fhsize=3D12, npp=3D0xfffffe100c75c=
6e0,
>     lkflags=3D<value optimized out>)
>     at /usr/src/sys/fs/nfsclient/nfs_clnode.c:114
> #12 0xffffffff809340fd in nfs_statfs (mp=3D0xfffff8002aa1e990,
>     sbp=3D0xfffff8002aa1ea48) at /usr/src/sys/fs/nfsclient/nfs_clvfsops=
=2Ec:288
> #13 0xffffffff80aa7ade in __vfs_statfs (mp=3D0x0, sbp=3D0xfffff8002aa1e=
a48)
>     at /usr/src/sys/kern/vfs_mount.c:1706
> #14 0xffffffff80ab4f5e in kern_getfsstat (td=3D0xfffff8002abeb000,
>     buf=3D<value optimized out>, bufsize=3D<value optimized out>,
>     bufseg=3DUIO_USERSPACE, flags=3D<value optimized out>)
>     at /usr/src/sys/kern/vfs_syscalls.c:511
> #15 0xffffffff80e1625a in amd64_syscall (td=3D0xfffff8002abeb000, trace=
d=3D0)
>     at subr_syscall.c:133
> #16 0xffffffff80df760b in Xfast_syscall ()
>     at /usr/src/sys/amd64/amd64/exception.S:390
> #17 0x00000008010fc83a in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)

Looks like the one I hit recently as well:

http://lists.freebsd.org/pipermail/freebsd-fs/2014-July/019843.html

This lock should probably be excluded from the DEADLKRES.

I have not had time to follow-up on it, but it's a trivial thing to add
it to the list.

--=20
Regards,
Bryan Drewery


--hdBSpUIBSRdCnQnwsbc6bvL1lC6uTbWqf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iQEcBAEBAgAGBQJT82CJAAoJEDXXcbtuRpfP1TUH/1I6fn3LoaGLzKJil0y0BHfl
/sf2Eh3HLD4uyPK5FKlhCuFbPOtEutI4/Wrt4HaBDdsvVb9ER0HYRaCabCBsamMI
siH2Vp44bcYGh2J0UX2r6pkAyvvIx6UfGxEf41rCWyh0h1h+IslHrht79ag/CQW8
C3e0u9askIVkh8t/1eVJnI8bEEVZ9xL+DTET0OGQa4E39Ess689hjIaVeyLyNJTH
0+kDPUXz2JewpLwsRt0hGTBQI4nW+cdG/64Pv/WHrYq8rpEy0kASryNPIL7xFzFc
FxPrdthXz5Yb1iFv/B6gf1TuJe3vthfMvRFsQ0kveClBlF4267p3AMSsofb8dZE=
=NdnZ
-----END PGP SIGNATURE-----

--hdBSpUIBSRdCnQnwsbc6bvL1lC6uTbWqf--



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