fsck_ufs after every reboot

[Attilio Rao]

2008/11/12, Jeremy Chadwick <koitsu at freebsd.org>:
> On Wed, Nov 12, 2008 at 05:20:56PM +0100, Attilio Rao wrote:
>  > 2008/11/12, Jeremy Chadwick <koitsu at freebsd.org>:
>  > > On Wed, Nov 12, 2008 at 04:52:59PM +0100, Attilio Rao wrote:
>  > >  > 2008/11/12, Jeremy Chadwick <koitsu at freebsd.org>:
>  > >  > > On Wed, Nov 12, 2008 at 04:44:52PM +0100, Attilio Rao wrote:
>  > >  > >  > 2008/11/12, Jeremy Chadwick <koitsu at freebsd.org>:
>  > >  > >  > > On Wed, Nov 12, 2008 at 02:44:05PM +0000, O. Hartmann wrote:
>  > >  > >  > >  > I run FreeBSD 8.0/AMD64 on two boxes (one is a UP older AMD64 Athlon64
>  > >  > >  > >  > 3500, other an 8-Core Dell Poweredge 1950).
>  > >  > >  > >  >
>  > >  > >  > >  > After nearly every reboot the box does fsck on all UFS2 filesystems. In
>  > >  > >  > >  > most cases, while shuting down, the box reports about not willing to die
>  > >  > >  > >  > processes and after a reboot, the filesystems are unclean.
>  > >  > >  > >  >
>  > >  > >  > >  > Is this a common problem at the moment or special?
>  > >  > >  > >
>  > >  > >  > >
>  > >  > >  > > I've seen this happen on my CURRENT box at home when using "shutdown -p
>  > >  > >  > >  now".  Instead of the box powering off, it would lock up near the very
>  > >  > >  > >  end of the shutdown process (before marking the filesystems clean).
>  > >  > >  > >
>  > >  > >  > >  Oddly, this works fine in RELENG_7, so I'm guessing there's some ACPI
>  > >  > >  > >  development going on (I can't complain, it *is* CURRENT).
>  > >  > >  >
>  > >  > >  > This could cames after my VFS works.
>  > >  > >  > Could you spend some time on this?
>  > >  > >  > I will tell you what to look at.
>  > >  > >
>  > >  > >
>  > >  > > Sure thing!
>  > >  > >
>  > >  > >  Let me know what I need to do to help, what information you need, or if
>  > >  > >  I should revert some commits to see if the behaviour changes.  Build
>  > >  > >  date of the box (src-all csup'd about 45 minutes prior to the build
>  > >  > >  date):
>  > >  > >
>  > >  > >  FreeBSD icarus.home.lan 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Nov  7 14:19:03 PST 2008     root at icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_CURRENT_amd64  amd64
>  > >  >
>  > >  > Is this reproducible?
>  > >
>  > >
>  > > I don't have an answer at this time.  I've only performed "shutdown -p
>  > >  now" on this box twice since running CURRENT, and both times the problem
>  > >  described occurred.
>  > >
>  > >
>  > >  > I need you build a kernel with following options:
>  > >  > INVARIANT_SUPPORT
>  > >  > INVARIANTS
>  > >  > DEBUG_VFS_LOCKS
>  > >  > WITNESS
>  > >  > and without WITNESS_SKIPSPIN
>  > >
>  > >
>  > > Will do.  Relevant options I use:
>  > >
>  > >  makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug symbols
>  > >  options         SCHED_ULE               # ULE scheduler
>  > >  options         PREEMPTION              # Enable kernel thread preemption
>  > >  options         BREAK_TO_DEBUGGER       # Sending a serial BREAK drops to DDB
>  > >  options         KDB                     # Enable kernel debugger support
>  > >  options         KDB_TRACE               # Print stack trace automatically on panic
>  > >  options         DDB                     # Support DDB
>  > >  options         GDB                     # Support remote GDB
>  > >  options         INVARIANTS              # Enable calls of extra sanity checking
>  > >  options         INVARIANT_SUPPORT       # Extra sanity checks of internal structures, required by INVARIANTS
>  > >  options         WITNESS                 # Enable checks to detect deadlocks and cycles
>  > >  options         DEBUG_VFS_LOCKS         # vfs lock debugging
>  > >
>  > >  I have physical access to the console of this machine on a regular
>  > >  basis.
>  >
>  > It's fine, great.
>
>
> And as luck would have it, I can't reproduce the problem any more.  I've
>  shutdown -p now'd literally 6 times in a row without any sort of lock
>  up, and this is running on the old kernel.  The same behaviour is now
>  seen with the new kernel.
>
>  So, the 2-3 times I've seen "shutdown -p now" not fully power off the
>  machine were either flukes, or who knows what/why.
>
>  I simply can't reproduce the problem any longer.  I'm sorry.

Can you recompile your kernel with the old option (read: not use the
old kernel, but recompile it with the old options) and see if it
hangs?
Did you update the sources in the while?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein