From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 19:28:17 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B444E1065673; Wed, 22 Feb 2012 19:28:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 43FCB8FC1C; Wed, 22 Feb 2012 19:28:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1MJOGBO006179; Wed, 22 Feb 2012 21:24:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1MJOFiE039961; Wed, 22 Feb 2012 21:24:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1MJOEgv039960; Wed, 22 Feb 2012 21:24:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Feb 2012 21:24:14 +0200 From: Konstantin Belousov To: Rick Macklem Message-ID: <20120222192414.GU55074@deviant.kiev.zoral.com.ua> References: <20120222.233814.1255848524636250830.hrs@allbsd.org> <810873252.1742743.1329928180108.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1PHmS26pdpOR3Xc0" Content-Disposition: inline In-Reply-To: <810873252.1742743.1329928180108.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org, John Baldwin Subject: Re: panic in 8.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:28:17 -0000 --1PHmS26pdpOR3Xc0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote: > Hiroki Sato wrote: > > Hi, > >=20 > > Just a report, but I got the following panic on an NFS server running > > 8.3-PRERELEASE: > >=20 > > ----(from here)---- > > pool.allbsd.org dumped core - see /var/crash/vmcore.0 > >=20 > > Tue Feb 21 10:59:44 JST 2012 > >=20 > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu > > Feb 16 19:29:19 JST 2012 hrs@pool.allbsd.org:/usr/obj/usr/src/sys/POOL > > amd64 > >=20 > > panic: Assertion lock =3D=3D sq->sq_lock failed at > > /usr/src/sys/kern/subr_sleepqueue.c:335 > >=20 > Oops, I didn't know that mixing msleep() and tsleep() calls on the same > event wasn't allowed. > There are two places in the code where it did a: > mtx_unlock(); > tsleep(); > left over from the days when it was written for OpenBSD. This sequence allows to lost the wakeup which is happen right after cache unlock (together with clearing the RC_WANTED flag) but before the thread enters sleep state. The tsleep has a timeout so thread should recover in 10 seconds, but still. Anyway, you should use consistent outer lock for the same wchan, i.e. no lock (tsleep) or mtx (msleep), but not mix them. >=20 > I don't think the mix would actually break anything, except that the > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have been > the author of the sleep() stuff. >=20 > Anyhow, please try the attached patch which replaces the mtx_unlock(); ts= leep(); with > msleep()s using PDROP. If the attachment gets lost, the patch is also her= e: > http://people.freebsd.org/~rmacklem/tsleep.patch >=20 > Thanks for reporting this, rick > ps: Is mtx_lock() now preferred over msleep()? What do you mean ? --1PHmS26pdpOR3Xc0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9FQN4ACgkQC3+MBN1Mb4gw4ACdHm3DYVwa4IgiNsKItQHq/v3n F34AoMxhJ6kp65aGIHlpxTUqo9d4LeMG =M9Gi -----END PGP SIGNATURE----- --1PHmS26pdpOR3Xc0--