Re: fsck_ufs after every reboot

From: Attilio Rao <attilio_at_freebsd.org>
Date: Wed, 12 Nov 2008 17:20:56 +0100
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.


> Got it.  Just need to wait a little while for world/kernel to build and
>  then I'll be able to perform the necessary testing.
>
>  I do have one question (and it's a general one): I assume without serial
>  console (I'm excluding firewire because that's not an option here) or
>  taking photos of the monitor, there's no way to effectively log all
>  output from db> to disk for review/access later?  (The obvious answer
>  here is "yes that's correct", being as the kernel itself is more or less
>  suspended at that point, but I thought I'd ask)

You can save the log with log capture for later lookups, but without a
serial line or physical access to the machine there is few you can do.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Wed Nov 12 2008 - 15:20:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:37 UTC