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 |Received on Wed Nov 12 2008 - 17:21:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:37 UTC