Date: Thu, 16 Nov 1995 12:51:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hwr@pilhuhn.de (Heiko W.Rupp) Cc: joerg_wunsch@uriah.heep.sax.de, hwr@pilhuhn.de, current@freebsd.org Subject: Re: 2.1-stable bombs at umount Message-ID: <199511161951.MAA03640@phaeton.artisoft.com> In-Reply-To: <m0tG0TJ-0005KXC@pilhuhn.de> from "Heiko W.Rupp" at Nov 16, 95 10:19:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
>
> Joerg Wunsch:
> | > | Fatal trap 12: page fault while in kernel mode
> | > | instruction pointer = 0x8:0xf0172ee8
>
> | Please, run ``nm `sysctl -n kern.bootfile` | sort | more'', and
> | examine the region around 0xf0172ee8.
>
> This gives:
> f0172e70 F ufs_inode.o
> f0172e70 T _ufs_init
> f0172eb8 T _ufs_inactive
> f017307c T _ufs_reclaim
> f0173130 F ufs_lookup.o
48 instructions into ufs_inactive() in /sys/ufs/ufs/ufs_inode.c.
int
ufs_inactive(ap)
struct vop_inactive_args /* {
struct vnode *a_vp;
} */ *ap;
{
register struct vnode *vp = ap->a_vp;
register struct inode *ip = VTOI(vp);
[ ... ]
.globl _ufs_inactive
.type _ufs_inactive,@function
_ufs_inactive:
pushl %ebp
movl %esp,%ebp
subl $40,%esp
pushl %edi
pushl %esi
pushl %ebx
movl 8(%ebp),%edx
movl 4(%edx),%esi
movl 100(%esi),%edi
cmpl $0,_prtactive
je L117
cmpw $0,4(%esi)
je L117
pushl %esi
pushl $LC0
call _vprint
addl $8,%esp
Someone passed a NULL vnode to ufs_inactive. When the inode pointer was
dereferenced out, it blew.
My guess is that the offending VOP_INACTIVE() is being called by vclean()
which is being called by vflush(), which is being called with a NULLVP
in /sys/ufs/ffs/ffs_vfsops.c from ffs_flushfiles().
Let me guess: You are running with quotas on this file system.
This seems to be an unforseen side effect of the recent changes to the
way unmounts are done on system shutdown. They are now explicit in
reverse order (per David Greenman's recent posting about the use of
circular queues for the mountlist).
If you explicitly add the line:
qsync(mp);
Before the line:
error = vflush(mp, NULLVP, SKIPSYSTEM|flags);
in /sys/ufs/ffs/ffs_vfsops.c from ffs_flushfiles(), it *might* mask
the problem for you.
If you aren't running with quotas, reverting the unmount code to forward
traverse the mountlist, focing each unmount, will fix the problem, or
at least put the behaviour back the way it was before the problem became
obvious.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511161951.MAA03640>