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
[-- Attachment #1 --]
On Mon, Feb 25, 2002 at 10:30:11PM +0000, Ian Dowse wrote:
> In message <20020225131714.B59373@xor.obsecurity.org>, Kris Kennaway writes:
> >Here you go, hope I got everything:
>
> 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 = {p_procq = {tqe_next = 0xcc2fdf60, tqe_prev = 0xc0402560}, p_list = {le_next = 0xce7809c0,
le_prev = 0xce295a48}, p_cred = 0xc1f8b720, p_fd = 0xc1ed9b00, p_stats = 0xcdf2ecd0,
p_limit = 0xc166d200, p_upages_obj = 0xcdf438a0, p_procsig = 0xc1ac5640, p_flag = 8452,
p_stat = 2 '\002', p_pad1 = "\000\000", p_pid = 2216, p_hash = {le_next = 0x0,
le_prev = 0xc15b52a0}, p_pglist = {le_next = 0xce476700, le_prev = 0xcc2fcc1c},
p_pptr = 0xcc2fcbe0, p_sibling = {le_next = 0xce476700, le_prev = 0xcc2fcc30}, p_children = {
lh_first = 0x0}, p_ithandle = {callout = 0xc67f64e0}, p_oppid = 0, p_dupfd = 0,
p_vmspace = 0xce3022c0, p_estcpu = 295, p_cpticks = 106, p_pctcpu = 7355, p_wchan = 0x0,
p_wmesg = 0xc036dbc9 "biord", p_swtime = 5, p_slptime = 0, p_realtimer = {it_interval = {
tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 42188, tv_usec = 597238}}, p_runtime = 32182,
p_uu = 0, p_su = 0, p_iu = 0, p_uticks = 2, p_sticks = 10278, p_iticks = 0, p_traceflag = 0,
p_tracep = 0x0, p_siglist = {__bits = {0, 0, 0, 0}}, p_textvp = 0xcde86480, p_lock = 0 '\000',
p_oncpu = 0 '\000', p_lastcpu = 0 '\000', p_rqindex = 12 '\f', p_locks = -7, p_simple_locks = 0,
p_stops = 0, p_stype = 0, p_step = 0 '\000', p_pfsflags = 0 '\000', p_pad3 = "\000", p_retval = {0,
0}, p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_oldsigmask = {__bits = {0, 0, 0, 0}},
p_sig = 11, p_code = 12, p_klist = {slh_first = 0x0}, p_sigmask = {__bits = {0, 0, 0, 0}},
p_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}, p_priority = 86 'V', p_usrpri = 86 'V',
p_nice = 0 '\000', p_comm = "sshd\000er\000\000\000\000\000\000\000\000\000", p_pgrp = 0xc15db000,
p_sysent = 0xc03b0140, p_rtprio = {type = 1, prio = 0}, p_prison = 0x0, p_args = 0xc1faa260,
p_addr = 0xcdf2e000, p_md = {md_regs = 0xcdf30fa8}, p_xstat = 0, p_acflag = 19, p_ru = 0xc1fba080,
p_nthreads = 0, p_aioinfo = 0x0, p_wakeup = 0, p_peers = 0x0, p_leader = 0xcc2fba00, p_asleep = {
as_priority = 0, as_timo = 0}, p_emuldata = 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 Mounted 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.
>
> 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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8erzvWry0BWjoQKURAn6QAKCURXVGSHiZ8ob5sOZjQoQKrP9fEACdGIsF
vCH4Nzq9LkN9+xShLlRJihM=
=FRnw
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020225143840.A60688>