fsck_ufs after every reboot
Jeremy Chadwick
koitsu at FreeBSD.org
Wed Nov 12 10:21:52 PST 2008
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.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-current
mailing list