Date: Tue, 15 Aug 2023 18:21:41 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@freebsd.org> Cc: current@freebsd.org Subject: Re: ZFS deadlock in 14 Message-ID: <CAGudoHHGeC4qaZpmTc15-Rimo78qVUmg8-oYveMfo0_JO45TSw@mail.gmail.com> In-Reply-To: <86350kqokl.fsf@ltc.des.no> References: <86leeltqcb.fsf@ltc.des.no> <86h6p4s64h.fsf@ltc.des.no> <86a5utrafp.fsf@ltc.des.no> <86350kqokl.fsf@ltc.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/15/23, Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> wrote: > Dag-Erling Sm=C3=B8rgrav <des@FreeBSD.org> writes: >> I managed to geat a deadlock with 4e8d558c9d1c. Its predecessor >> 5ca7f02946 appears to be working. I'm going to try to come up with a >> more efficient way to reproduce the deadlock than running poudriere. > > I wrote a script that creates multiple filesystems, snapshots them, > populates them and rolls them back continuously but so far I have not > succeeded in triggering the deadlock without poudriere. I guess my > script doesn't consume enough vnodes. > > Also, 9228ac3a69c4 (9 August, last commit before the contrib/googletest > breakage) still deadlocks. > Given that the custom reproducer failed I think the most prudent course of action is to reproduce again with poudriere, but this time arrange to have all stacktraces dumped. this should do it: sbin/ddb/ddb.conf:script kdb.enter.panic=3Dtextdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; textdump dump; reset it is a slightly finicky beast so I would trigger a panic by hand first to validate it works as expected. --=20 Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHHGeC4qaZpmTc15-Rimo78qVUmg8-oYveMfo0_JO45TSw>