Date: Mon, 25 Feb 2002 14:38:40 -0800 From: Kris Kennaway <kris@obsecurity.org> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: Kris Kennaway <kris@obsecurity.org>, mckusick@mckusick.com, fs@FreeBSD.org, dillon@FreeBSD.org, fanf@chiark.greenend.org.uk Subject: Re: UFS panic on -stable Message-ID: <20020225143840.A60688@xor.obsecurity.org> In-Reply-To: <200202252230.aa23166@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Mon, Feb 25, 2002 at 10:30:11PM %2B0000 References: <20020225131714.B59373@xor.obsecurity.org> <200202252230.aa23166@salmon.maths.tcd.ie>
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 Mon, Feb 25, 2002 at 10:30:11PM +0000, Ian Dowse wrote:
> In message <20020225131714.B59373@xor.obsecurity.org>, Kris Kennaway writ=
es:
> >Here you go, hope I got everything:
>=20
> Mostly :-) Could you print out "*(struct proc *)0xcc2fba00", as the
> `p' pointer in frame 18 got lost. I just want to see what process
> was exiting to see if it offers any further hints.
(kgdb) print *(struct proc *)0xcc2fba00
$1 =3D {p_procq =3D {tqe_next =3D 0xcc2fdf60, tqe_prev =3D 0xc0402560}, p_l=
ist =3D {le_next =3D 0xce7809c0,
le_prev =3D 0xce295a48}, p_cred =3D 0xc1f8b720, p_fd =3D 0xc1ed9b00, p_=
stats =3D 0xcdf2ecd0,
p_limit =3D 0xc166d200, p_upages_obj =3D 0xcdf438a0, p_procsig =3D 0xc1ac=
5640, p_flag =3D 8452,
p_stat =3D 2 '\002', p_pad1 =3D "\000\000", p_pid =3D 2216, p_hash =3D {l=
e_next =3D 0x0,
le_prev =3D 0xc15b52a0}, p_pglist =3D {le_next =3D 0xce476700, le_prev =
=3D 0xcc2fcc1c},
p_pptr =3D 0xcc2fcbe0, p_sibling =3D {le_next =3D 0xce476700, le_prev =3D=
0xcc2fcc30}, p_children =3D {
lh_first =3D 0x0}, p_ithandle =3D {callout =3D 0xc67f64e0}, p_oppid =3D=
0, p_dupfd =3D 0,
p_vmspace =3D 0xce3022c0, p_estcpu =3D 295, p_cpticks =3D 106, p_pctcpu =
=3D 7355, p_wchan =3D 0x0,
p_wmesg =3D 0xc036dbc9 "biord", p_swtime =3D 5, p_slptime =3D 0, p_realti=
mer =3D {it_interval =3D {
tv_sec =3D 0, tv_usec =3D 0}, it_value =3D {tv_sec =3D 42188, tv_usec=
=3D 597238}}, p_runtime =3D 32182,
p_uu =3D 0, p_su =3D 0, p_iu =3D 0, p_uticks =3D 2, p_sticks =3D 10278, p=
_iticks =3D 0, p_traceflag =3D 0,
p_tracep =3D 0x0, p_siglist =3D {__bits =3D {0, 0, 0, 0}}, p_textvp =3D 0=
xcde86480, p_lock =3D 0 '\000',
p_oncpu =3D 0 '\000', p_lastcpu =3D 0 '\000', p_rqindex =3D 12 '\f', p_lo=
cks =3D -7, p_simple_locks =3D 0,
p_stops =3D 0, p_stype =3D 0, p_step =3D 0 '\000', p_pfsflags =3D 0 '\000=
', p_pad3 =3D "\000", p_retval =3D {0,
0}, p_sigiolst =3D {slh_first =3D 0x0}, p_sigparent =3D 20, p_oldsigmas=
k =3D {__bits =3D {0, 0, 0, 0}},
p_sig =3D 11, p_code =3D 12, p_klist =3D {slh_first =3D 0x0}, p_sigmask =
=3D {__bits =3D {0, 0, 0, 0}},
p_sigstk =3D {ss_sp =3D 0x0, ss_size =3D 0, ss_flags =3D 4}, p_priority =
=3D 86 'V', p_usrpri =3D 86 'V',
p_nice =3D 0 '\000', p_comm =3D "sshd\000er\000\000\000\000\000\000\000\0=
00\000", p_pgrp =3D 0xc15db000,
p_sysent =3D 0xc03b0140, p_rtprio =3D {type =3D 1, prio =3D 0}, p_prison =
=3D 0x0, p_args =3D 0xc1faa260,
p_addr =3D 0xcdf2e000, p_md =3D {md_regs =3D 0xcdf30fa8}, p_xstat =3D 0, =
p_acflag =3D 19, p_ru =3D 0xc1fba080,
p_nthreads =3D 0, p_aioinfo =3D 0x0, p_wakeup =3D 0, p_peers =3D 0x0, p_l=
eader =3D 0xcc2fba00, p_asleep =3D {
as_priority =3D 0, as_timo =3D 0}, p_emuldata =3D 0x0}
> The superblock claims that this is a 2MB "/dev" filesystem - is
> that a real disk filesystem, or mounted from a vnconfig disk or
> something?
I should have provided more information about the clients in the
initial email: they boot "diskless" via NFS, but also have local disk.
Here's the df output:
Filesystem 1K-blocks Used Avail Capacity Mou=
nted on
216.136.204.23:/a/nfsroots/4.dir4 176873964 99865811 62858236 61% /
mfs:13 3935 1055 2566 29% /etc
mfs:21 32206 856 28774 3% /var
mfs:28 10030 188 9040 2% /tmp
mfs:33 1486 68 1300 5% /dev
/dev/ad0e 2032839 108878 1761334 6% /a
/dev/ad0f 26046238 7158650 16803889 30% /x
> In the vnode we have v_type set to VNON, v_mount is non-NULL, v_data
> is non-NULL, i_mode was 0666. Candidates I could see for leaving
> vnodes like this are getnewvnode() and the weird code in ufs_mknod().
> I guess ufs_mknod is the main suspect since the filesystem is /dev.
>=20
> I wonder is the new vlrureclaim() code somehow reclaiming vnodes
> at a bad time. Maybe try setting kern.maxvnodes to some really large
> value to see if it stops the crashes, or set it very small and see
> if they occur more frequently.
Okay, I'll try this.
Kris
--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8erzvWry0BWjoQKURAn6QAKCURXVGSHiZ8ob5sOZjQoQKrP9fEACdGIsF
vCH4Nzq9LkN9+xShLlRJihM=
=FRnw
-----END PGP SIGNATURE-----
--GvXjxJ+pjyke8COw--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020225143840.A60688>