Subject: Re: panic
To: None <>
From: Mike Long <>
List: current-users
Date: 07/06/1995 11:39:21
>Date: Thu, 06 Jul 1995 09:22:07 -0400
>From: "Gary D. Duzan" <>
>   I had left a /usr/src "make && make install" running last night,
>with a current kernel. This morning it had completed, and I proceeded
>to reboot to get the new daemons going. I did a "shutdown -r +1" while
>in X, exited X cleanly, did a quick MH inc to get the cron mail, and
>logged out before it shut down. Then I got:
>syncing disks... panic: vinvalbuf: dirty bufs
>Stopped at      _Debugger+0x4:    leave
>The stack trace showed: Debugger, panic, vinvalbuf, spec_close,
>ffs_umount, doumount, vfs_unmountall, vfs_shutdown, boot, reboot,
>syscall. I have most of the text of the trace if that would help,
>and I got a dump (accidentally, actually, since I'm not that familiar
>with the debugger) that I could look at if gdb would work with it.
>Any ideas?

Problems like this can occur when you overwrite some binaries.  I've
noticed it with /sbin/init and /sbin/mount_mfs.  I avoid it by doing
the following before before I install new binaries from /usr/src/sbin:

mv /sbin/init /sbin/init.old
mv /sbin/mount_mfs /sbin/mount_mfs.old

The second line isn't necessary if you don't use MFS, or remember to
unmount it before shutting down.

I don't know enough about the kernel's guts to know what the real
problem is.  My guess is that the running init process holds onto a
vnode for its executable image; when you install a new /sbin/init,
that vnode becomes the only thing keeping the old executable's blocks
from being reclaimed by the filesystem.  Apparently vfs_unmountall
doesn't deal with this situation well.

cgd sent in a pair of PRs recently that relate to this situation, and
the fact that fsck -p doesn't clean it up properly when you reboot.
Mike Long <> 
VLSI Design Engineer         finger for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA                assert(*this!=opinionof(Analog));