Date: Wed, 23 Feb 2000 23:34:01 +0000 From: Nick Sayer <nsayer@sftw.com> To: freebsd-current@freebsd.org Subject: [Fwd: sync hang] Message-ID: <38B46E69.1A711A21@sftw.com>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------352EFC8A1EECAD238528CA6A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Oh... one more thing on the hang...
(kgdb)
#10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at
../../kern/vfs_default.c:138
138 return (VOCALL(default_vnodeop_p,
ap->a_desc->vdesc_offset, ap));
(kgdb) print ap
$3 = (struct vop_generic_args *) 0x0
if ap is NULL, then ap->a_desc->vdesc_offset is probably a bad idea. :-(
Looking at the actual disassembly, it looks like another case of a
register getting a 0
stuffed into it at the oddest of times.
--------------352EFC8A1EECAD238528CA6A
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <38B469D3.A7FA57FF@sftw.com>
Date: Wed, 23 Feb 2000 23:14:27 +0000
From: Nick Sayer <nsayer@sftw.com>
Reply-To: nsayer@freebsd.org
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: sync hang
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm full of all sorts of good news today. :-(
The machine I'm having such problems with just hung. Fortunately, I was
able to get at it with
ddb and force it to dump. The resulting core gives me this stack trace:
#8 0xc026bde7 in siointr (arg=0xc0afe000) at ../../isa/sio.c:1679
#9 0xc0250b37 in Xfastintr4 ()
#10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at
../../kern/vfs_default.c:138
#11 0xc01d1023 in nfs_sync (mp=0xc0bc7200, waitfor=3, cred=0xc073b780,
p=0xc84b7780) at vnode_if.h:27
#12 0xc0181571 in sync_fsync (ap=0xc84c5f7c) at
../../kern/vfs_subr.c:2827
#13 0xc017faf7 in sched_sync () at vnode_if.h:537
From 9 on up it is undoubtedly the result of the drop into DDB and the
subsequent dump and
boot.
A ps on the core shows that indeed, the syncer is the running "process".
vop_default() is very short, but there's no stack entry from VOCALL().
Perhaps it "wandered off..."? vmware was booting NT4 at the time.
I'm begining to think that vmware isn't ready for prime time, but I
can't
quite come up with a mechanism in my head for how it's causing this
and that I am somehow the only person in the world seeing it. :-)
--------------352EFC8A1EECAD238528CA6A--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38B46E69.1A711A21>