Date: Wed, 25 Aug 2004 17:07:24 +0200 From: Christian Brueffer <chris@unixpages.org> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: panic: nfssvc_nfsd(): debug.mpsafenet=1 && Giant Message-ID: <20040825150724.GA33080@unixpages.org> In-Reply-To: <Pine.NEB.3.96L.1040824231219.89999N-100000@fledge.watson.org> References: <20040824203210.GA30220@unixpages.org> <Pine.NEB.3.96L.1040824231219.89999N-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 24, 2004 at 11:18:55PM -0400, Robert Watson wrote: >=20 > On Tue, 24 Aug 2004, Christian Brueffer wrote: >=20 > > I'm getting the following panic on 6-CURRENT as well as 5.3-BETA1 with > > sources from today. It's easily reproducible on both, with > > debug.mpsafenet=3D1.=20 >=20 > Hmm. Looks like something has acquired and failed to release Giant in the > NFS server. It could be we're leaking Giant in an error case that didn't > turn up in previous testing, but for some reason is more common in your > environment. Unfortunately, as Giant can be acquired recursively, the > "last acquired" information presented by WITNESS isn't useful to us. > There are a couple of ways we could approach debugging this. I think the > easiest might be the following: >=20 > - Recompile your kernel with the following options: >=20 > options KTR > options KTR_COMPILE=3D(KTR_LOCK|KTR_PROC) > options KTR_ENTRIES=3D16384 >=20 > - At run-time, before triggering the crash, use sysctl to set the > following settings: >=20 > sysctl debug.ktr.cpumask=3D0xff > sysctl debug.ktr.mask=3D`sysctl -n debug.ktr.compile` >=20 > - When the crash occurs, use "show ktr" to list recent lock operations. > Using your serial console, copy and paste a few pages of locking > operations into an e-mail, probably until you hit the next context > switch (mi_switch: new thread). You'll notice that the entries are > sorted by event id, which generally results in reverse-chronological > order with most recent event earliest. We'd like to look at all > acquisitions of Giant and releases of Giant since that context switch. > There should be one or more acquires than releases in the event stream, > and we'd like to figure out which is the one not associated with a > matching unlock. >=20 The complete output is available at http://people.freebsd.org/~brueffer/screenlog.0.gz - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBLKssbHYXjKDtmC0RAvIbAKDY8KN0wDNwZY/05/s0HGPFof0p7wCg+nGx MNBuh6hbdNXrr9UF1CwivKI= =Bk0A -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040825150724.GA33080>