Date: Sun, 16 Jul 2006 12:19:25 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Mark Knight <markk@knigma.org> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 6.1 panic after approx. 49 days uptime Message-ID: <20060716091925.GM32624@deviant.kiev.zoral.com.ua> In-Reply-To: <giDNdZC5zfuEFwMa@lap.knigma.org> References: <NCWGF4BvmfuEFwrU@lap.knigma.org> <20060716084210.GL32624@deviant.kiev.zoral.com.ua> <giDNdZC5zfuEFwMa@lap.knigma.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--tBhgiDt8dP1efIIJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 16, 2006 at 09:46:49AM +0100, Mark Knight wrote: > In message <20060716084210.GL32624@deviant.kiev.zoral.com.ua>, Kostik=20 > Belousov <kostikbel@gmail.com> writes > >On Sun, Jul 16, 2006 at 09:32:47AM +0100, Mark Knight wrote: > >>Just awoke to fine my home server (6.1-RELEASE) had panicked during its > >>daily update of /usr/ports with an uptime of 49 days. > >> > >>Stack trace is here: > >> > >> <http://www.knigma.org.uk/scratch/crash_160706.txt>; > >> > >>Looks file system related to me. Any advice appreciated. > > > >If you still have the core dump at hands, go to frame #7 and post the > >output of the commands "p *vp" and "p *(vp->v_mount)". >=20 > Appended to log file (in case of mail formatting) and reproduced here: >=20 > (kgdb) p *(vp) > $3 =3D {v_type =3D VBAD, v_tag =3D 0xc0791704 "none", v_op =3D 0xc07d89e0= , v_data =3D=20 > 0x0, v_mount =3D 0x0, > v_nmntvnodes =3D {tqe_next =3D 0x0, tqe_prev =3D 0xc3250014}, v_un =3D = {vu_mount=20 > =3D 0x0, vu_socket =3D 0x0, > vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0}, v_hashlist =3D {le_next =3D 0x= 0, le_prev=20 > =3D 0xc295f570}, > v_hash =3D 3269747, v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =3D= =20 > {tqh_first =3D 0x0, tqh_last =3D 0xc335cbe0}, > v_dd =3D 0x0, v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D = 0, v_lock =3D=20 > {lk_interlock =3D 0xc08073dc, > lk_flags =3D 64, lk_sharecount =3D 0, lk_waitcount =3D 0, lk_exclusiv= ecount =3D=20 > 0, lk_prio =3D 80, > lk_wmesg =3D 0xc07a24ed "ufs", lk_timo =3D 51, lk_lockholder =3D 0xff= ffffff,=20 > lk_newlock =3D 0x0}, > v_interlock =3D {mtx_object =3D {lo_class =3D 0xc07e0644, lo_name =3D 0= xc07a3a55=20 > "vnode interlock", > lo_type =3D 0xc07a3a55 "vnode interlock", lo_flags =3D 196608, lo_l= ist =3D=20 > {tqe_next =3D 0x0, > tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recur= se =3D 0},=20 > v_vnlock =3D 0xc335cc08, > v_holdcnt =3D 1, v_usecount =3D 0, v_iflag =3D 128, v_vflag =3D 0, v_wr= itecount =3D=20 > 0, v_freelist =3D { > tqe_next =3D 0xc3248990, tqe_prev =3D 0xc080d22c}, v_bufobj =3D {bo_m= tx =3D=20 > 0xc335cc2c, bo_clean =3D {bv_hd =3D { > tqh_first =3D 0x0, tqh_last =3D 0xc335cc74}, bv_root =3D 0x0, bv_= cnt =3D=20 > 0}, bo_dirty =3D {bv_hd =3D { > tqh_first =3D 0x0, tqh_last =3D 0xc335cc84}, bv_root =3D 0x0, bv_= cnt =3D=20 > 0}, bo_numoutput =3D 0, bo_flag =3D 0, > bo_ops =3D 0xc07e6564, bo_bsize =3D 8192, bo_object =3D 0x0, bo_syncl= ist =3D=20 > {le_next =3D 0x0, le_prev =3D 0x0}, > bo_private =3D 0xc335cbb0, __bo_vnode =3D 0xc335cbb0}, v_pollinfo =3D= 0x0,=20 > v_label =3D 0x0} > (kgdb) p *(vp->v_mount) > Cannot access memory at address 0x0 > (kgdb) >=20 > Thanks, Thank you for the data. As I see, the problem could be worked around by the following patch: Index: mount.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/sys/mount.h,v retrieving revision 1.210 diff -u -r1.210 mount.h --- mount.h 5 May 2006 19:32:35 -0000 1.210 +++ mount.h 16 Jul 2006 09:15:32 -0000 @@ -578,7 +578,7 @@ int _locked; \ struct mount *_MP; \ _MP =3D (MP); \ - if (VFS_NEEDSGIANT(_MP)) { \ + if (_MP !=3D NULL && VFS_NEEDSGIANT(_MP)) { \ mtx_lock(&Giant); \ _locked =3D 1; \ } else \ What seems to be quite untrivial is testing. Did you had unmount some filesystem before that panic happen ? To reproduce the situation, the following cojunction of the events is neede= d: 1. you have free vnode pressure 2. some very active fs in unmounted 3. some further file activity is going on --tBhgiDt8dP1efIIJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEugSdC3+MBN1Mb4gRAnilAJ92qyB84eq3du4WDmulhov11ZwAnQCg7JX0 nrlrB9Ie0YmEedmgZAzmplM= =+sfK -----END PGP SIGNATURE----- --tBhgiDt8dP1efIIJ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060716091925.GM32624>