Subject: UVM/NFS problem?
To: None <firstname.lastname@example.org>
From: Jaromír <email@example.com>
Date: 07/21/2001 11:52:15
I'm experiencing process getting stuck in uvn_flush() ~forever on i386
with math_emulation. At first, I though this is math emulation specific
thing, but I still see this behaviour even with fixed version. I have
noticed this behaviour quite recently (like, couple days ago), but it's
possible this behaviour was there for longer time and I just didn't
happen to encouter it.
I use NFS mounted root for 386DX machine. A program does division by
zero and gets SIGILL from math_emulate(). If I repeat this couple of times,
the process eventually would get stuck in uvn_flush() and never finish.
The DDB stack at that point is like this:
db> t/t 1c
trace: pid 28 at 0xc308a4f0
bpendtsleep(c3087460,204,c01c3752,0,c3087444) at bpendtsleep
uvn_flush(c3087444,0,0,fffff000,7fffffff) at uvn_flush+0x83e
nfs_flush(c3087444,c0299f00,1,c305d55c,0) at nfs_flush+0x23
nfs_close(c308a9d8,0,c308aa34,c01bd0c0,c3087444) at nfs_close+0x44
vn_close(c3087444,2,c0299f00,c305d55c,c305d55c) at vn_close+0x4f
coredump(c305d55c) at coredump+0x3ad
sigexit(c305d55c,4,5,c305d55c,c308afa8) at sigexit+0x2b
postsig(4) at postsig+0x64
trap() at trap+0x5e6
--- trap (number 0) ---
Apparently, it's flushing some pages belonging to the crash dump
and it's waiting for iosync at uvm/uvm_vnode.c:776, which never
happens for some reason.
Since there was a crashdump from previous time the program dies, the crash
dump is actually overwritten. This might trigger the problem.
What information should I collect now to help find what causes this bug?
Anyone else seen such problem?
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!