fsck_ufs after every reboot
Attilio Rao
attilio at freebsd.org
Wed Nov 12 08:20:58 PST 2008
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
More information about the freebsd-current
mailing list