Date: Wed, 23 Feb 2000 23:14:27 +0000 From: Nick Sayer <nsayer@sftw.com> To: freebsd-current@freebsd.org Subject: sync hang Message-ID: <38B469D3.A7FA57FF@sftw.com>
next in thread | raw e-mail | index | archive | help
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. :-)
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?38B469D3.A7FA57FF>