From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 15:42:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 638E11065673; Wed, 27 Jun 2012 15:42:50 +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 F31338FC1E; Wed, 27 Jun 2012 15:42:48 +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 q5RFgaqf038076; Wed, 27 Jun 2012 18:42:36 +0300 (EEST) (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 q5RFgZVa091454; Wed, 27 Jun 2012 18:42:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5RFgYQA091453; Wed, 27 Jun 2012 18:42:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Jun 2012 18:42:33 +0300 From: Konstantin Belousov To: Kevin Lo Message-ID: <20120627154233.GO2337@deviant.kiev.zoral.com.ua> References: <1340589808.2192.1.camel@nsl> <20120625095548.GD2337@deviant.kiev.zoral.com.ua> <1340685505.2170.5.camel@nsl> <20120626102424.GL2337@deviant.kiev.zoral.com.ua> <1340763363.2147.1.camel@nsl> <1340774954.2147.3.camel@nsl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gZyN7ilQ5rV5bB+g" Content-Disposition: inline In-Reply-To: <1340774954.2147.3.camel@nsl> 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: freebsd-fs@freebsd.org, freebsd-current Subject: Re: Tmpfs panic in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:42:50 -0000 --gZyN7ilQ5rV5bB+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote: > Kevin Lo wrote: > > Konstantin Belousov wrote: > > > On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: > > > > Konstantin Belousov wrote: > > > > > On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: > > > > > > I've observed a panic in recent -current several times but I on= ly > > > > > > have a picture of the backtrace: > > > > > > http://people.freebsd.org/~kevlo/panic_tmpfs.jpg > > > > > >=20 > > > > > > Does this look at all familiar to anyone? > > > > >=20 > > > > > Can you look up the line corresponding to tmpfs_reg_resize + 0x62= 7 address > > > > > in your kernel ? > > > >=20 > > > > Sure. > > > >=20 > > > > > The screenshot looks strange. The instruction on which the kernel= trapped > > > > > is int 0x28 which should not appear in the compiled code. > > > >=20 > > > > # gdb tmpfs.ko > > > > (gdb) l *tmpfs_reg_resize+0x627 > > > > 0xbf37 is in tmpfs_reg_resize (/usr/src/sys/modules/tmpfs/../../fs/= tmpfs/tmpfs_subr.c:1005). > > > > 1000 in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c > > > >=20 > > > > In tmpfs_subr.c: > > > > 999 if (m !=3D NULL) { > > > > 1000 if ((m->oflags & VPO_BUSY) != =3D 0 || > > > > 1001 m->busy !=3D 0) { > > > > 1002 vm_page_sleep(m, "tmfs= sz"); > > > > 1003 goto retry; > > > > 1004 } > > > > 1005 MPASS(m->valid =3D=3D VM_PAGE_= BITS_ALL); > > > > 1006 } else if (vm_pager_has_page(uobj, idx= , NULL, NU > > > > LL)) { > > > >=20 > > > Hm, can you get a core and > > > - obtain backtrace in kgdb; > > > - print the *m content for the page that triggered the assertion ? > > >=20 > > > The only possible 'new size' value for the truncation from open(2) is= zero, > > > so I do not understand why the asserted block was executed at all. > >=20 > > Thanks for looking into it. Unfortunately I can't get a crash dump=20 > > due to lack of disk space and memory. >=20 > I triggered the KASSERT on a different machine in the last hour. It is not 'the' KASSERT, it is something different. Are you sure that you do not have some systematic build issues on your machines ? Although I do not think that tmpfs is 'ready for production use' for arbitrary low value of this statement, there is no steady flow of similar reports from other users. This makes me somewhat suspicious that either you might have inconsistent build issues, or unrelated memory corruption problems. >=20 > panic: Assertion (vp) !=3DNULL && (vp)->v_data !=3D NULL failed at=20 > @/fs/tmpfs/tmpfs.h:527 >=20 > The bad news is my coworker rebooted that machine after panic :-( >=20 > Kevin --gZyN7ilQ5rV5bB+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/rKekACgkQC3+MBN1Mb4hYwgCfYWOIBPD9WwnenIfhB12y4He+ uuYAoNvto31Rpl2RKFa+YaYOEpdhVsZ/ =jwy7 -----END PGP SIGNATURE----- --gZyN7ilQ5rV5bB+g--