Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Nov 2008 08:16:44 -0800
From:      Jeremy Chadwick <koitsu@FreeBSD.org>
To:        Attilio Rao <attilio@freebsd.org>
Cc:        freebsd-current@freebsd.org, "O. Hartmann" <ohartman@zedat.fu-berlin.de>
Subject:   Re: fsck_ufs after every reboot
Message-ID:  <20081112161644.GA98426@icarus.home.lan>
In-Reply-To: <3bbf2fe10811120752k5e42b912nd0933771696519e0@mail.gmail.com>
References:  <491AEBB5.8010001@zedat.fu-berlin.de> <20081112154240.GA28818@icarus.home.lan> <3bbf2fe10811120744hd740388s25e7413e84bbb8c1@mail.gmail.com> <20081112154744.GA28943@icarus.home.lan> <3bbf2fe10811120752k5e42b912nd0933771696519e0@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 12, 2008 at 04:52:59PM +0100, Attilio Rao wrote:
> 2008/11/12, Jeremy Chadwick <koitsu@freebsd.org>:
> > On Wed, Nov 12, 2008 at 04:44:52PM +0100, Attilio Rao wrote:
> >  > 2008/11/12, Jeremy Chadwick <koitsu@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@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.

> once it hangs you have to break in DDB and look the state of the threads with:
> db> ps
> 
> This would be a start.
> Other instructions will follow based on this result.

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)

-- 
| 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 |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081112161644.GA98426>