From owner-freebsd-bugs  Fri Dec 14 18:40: 6 2001
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id B5ACF37B405
	for <freebsd-bugs@hub.freebsd.org>; Fri, 14 Dec 2001 18:40:01 -0800 (PST)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id fBF2e1810896;
	Fri, 14 Dec 2001 18:40:01 -0800 (PST)
	(envelope-from gnats)
Date: Fri, 14 Dec 2001 18:40:01 -0800 (PST)
Message-Id: <200112150240.fBF2e1810896@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: kern/32809: yet another panic while syncing disks after a panic
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-bugs.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-bugs>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-bugs>
X-Loop: FreeBSD.org

The following reply was made to PR kern/32809; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: <FreeBSD-gnats-submit@FreeBSD.ORG>
Subject: Re: kern/32809: yet another panic while syncing disks after a panic
Date: Sat, 15 Dec 2001 13:32:55 +1100 (EST)

 On Thu, 13 Dec 2001, Yar Tikhiy wrote:
 
 > >Description:
 >
 > After any panic, the system tries to sync disks,
 > but gets yet another panic as follows:
 >
 > stylish# sysctl debug.debugger_on_panic=0
 > debug.debugger_on_panic: 1 -> 0
 > stylish# ./666
 > panic: test panic
 >
 > syncing disks... panic: bremfree: bp 0xc217a428 not locked
 > Uptime: 4m43s
 > pfs_vncache_unload(): 1 entries remaining
 
 sync() from panic() only works accidentally.  I'ts like calling a
 non-signal safe function from a signal handler -- when the system
 panics, it quite likely to be executing filesystem code or holding a
 lock that should prevent filesystem code being run, but panic()
 executes filesystem code (the sync()) unless the panic is recursive.
 Addition of locks has greatly increased the chance that the sync()
 in panic will deadlock instead of appearing to work.
 
 > dumping to dev ad0s1b, offset 139376
 > dump ata0: resetting devices ..
 > [the system hangs dead at this point sometimes]
 
 addump() seems to have regressed relative to wddump().  Dump routines
 should not use any normal i/o routines.
 
 Bruce
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message