From owner-freebsd-current  Tue Mar 18 16:32:13 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id QAA16193
          for current-outgoing; Tue, 18 Mar 1997 16:32:13 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16175
          for <current@freebsd.org>; Tue, 18 Mar 1997 16:32:07 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id LAA28501; Wed, 19 Mar 1997 11:29:18 +1100
Date: Wed, 19 Mar 1997 11:29:18 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703190029.LAA28501@godzilla.zeta.org.au>
To: imp@village.org, scrappy@hub.org
Subject: Re: 2.2 Kernel Unstable
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>I was runing a -current kernel as of Mar 14 and thought that it was
>just the post Lite-2 blues.  I didn't get a good traceback because gdb
>didn't have any symbols.  When I did gdb's job by hand, it showed the
>following traceback:
>
>#0  0xf0111fb3 in boot ()
>#1  0xf0112272 in panic ()
>#2  0xf01b9956 in trap_fatal ()
>#3  0xf01b9444 in trap_pfault ()
>#4  0xf01b911f in trap ()
>#5  0xf010d660 in lockstatus ()
>#6  0xf01a1bfd in ufs_islocked () + 0x15
>#7  0xf0131d78 in vfs_msync () + 0x38
>#8  0xf0132704 in sync () + 0x4c
>#9  0xf0111e7d in boot () + 0x75
>#10 0xf0112272 in panic ()
>#11 0xf01b9956 in trap_fatal ()
>#12 0xf01b9444 in trap_pfault ()
>#13 0xf01b911f in trap ()
>#14 0xf010d660 in lockstats ()
>#15 0xf01a1bfd in ufs_islocked () + 0x15
>#16 0xf0131d78 in vfs_msync () + 0x38
>#17 0xf0132704 in sync () + 0x4c
>#18 0xf012d58b in vfs_update () + 0x3b
>#19 0xf0107ab6 in kproc_start () + 0x32
>#20 0xf0107a54 in main ()

gdb should do this automatically, but kernel symbol lookup is currently
and 2.2ly broken in the backtrace and perhaps elsewhere without full
(-g) symbols (due to to the section limits having been broken in all
versions and gdb-4.16 being fussier about checking section limits).

>P.S.  No, the same traceback on the screen twice isn't a typo!

Recursive panics became normal with the Lite2 merge.  sync() in panic()
has never run in the quite the right context, and now that there is a
lot more locking in sync(), the panic sync() is likely to stumble over
a lock, especially if the first panic was for a lock.  Panics aren't
much more common than before the merge.

Bruce