From yar@bsd.chem.msu.ru  Thu Dec 13 09:49:44 2001
Return-Path: <yar@bsd.chem.msu.ru>
Received: from bsd.chem.msu.ru (bsd.chem.msu.ru [195.208.208.23])
	by hub.freebsd.org (Postfix) with ESMTP id 1086737B41A
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 13 Dec 2001 09:49:43 -0800 (PST)
Received: (from yar@localhost)
	by bsd.chem.msu.ru (8.11.6/8.11.6) id fBDHncZ87257;
	Thu, 13 Dec 2001 20:49:38 +0300 (MSK)
	(envelope-from yar)
Message-Id: <200112131749.fBDHncZ87257@bsd.chem.msu.ru>
Date: Thu, 13 Dec 2001 20:49:38 +0300 (MSK)
From: Yar Tikhiy <yar@comp.chem.msu.su>
To: FreeBSD-gnats-submit@freebsd.org
Subject: yet another panic while syncing disks after a panic
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         32809
>Category:       kern
>Synopsis:       yet another panic while syncing disks after a panic
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 13 09:50:01 PST 2001
>Closed-Date:    Mon Aug 23 10:52:23 GMT 2004
>Last-Modified:  Mon Aug 23 10:52:23 GMT 2004
>Originator:     Yar Tikhiy
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
Moscow State University
>Environment:
System: FreeBSD stylish.chem.msu.su 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Thu Dec 13 18:49:28 MSK 2001     yar@stylish.chem.msu.su:/usr/obj/usr/src/sys/STYLISH  i386

CVSup'ed on December,11

The kernel configuration is as primitive as possible:

# Based on
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.330 2001/12/04 11:12:20 des Exp $

machine		i386
cpu		I586_CPU
cpu		I686_CPU
ident		STYLISH
maxusers	32

makeoptions	DEBUG=-g		#Build kernel with gdb(1) debug symbols

options 	INET			#InterNETworking
options 	FFS			#Berkeley Fast Filesystem
options 	PROCFS			#Process filesystem (requires PSEUDOFS)
options 	PSEUDOFS		#Pseudo-filesystem framework
options 	COMPAT_43		#Compatible with BSD 4.3 [KEEP THIS!]
options 	KTRACE			#ktrace(1) support

# Debugging for use in -current
options 	DDB			#Enable the kernel debugger
options 	INVARIANTS		#Enable calls of extra sanity checking
options 	INVARIANT_SUPPORT	#Extra sanity checks of internal structures, required by INVARIANTS
options 	WITNESS			#Enable mutex checks to detects deadlocks and cycles

device		isa
device		pci

# Floppy drives
device		fdc

# ATA and ATAPI devices
device		ata
device		atadisk			# ATA disk drives
options 	ATA_STATIC_ID		#Static device numbering

# atkbdc0 controls both the keyboard and the PS/2 mouse
device		atkbdc	1	# At keyboard controller
device		atkbd		# at keyboard

device		vga		# VGA screen

# syscons is the default console driver, resembling an SCO console
device		sc	1

# Floating point support - do not disable.
device		npx

# Serial (COM) ports
device		sio		# 8250, 16[45]50 based serial ports

# Parallel port
device		ppc
device		ppbus		# Parallel port bus (required)
device		lpt		# Printer

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device		miibus		# MII bus support
device		fxp		# Intel EtherExpress PRO/100B (82557, 82558)

# Pseudo devices - the number indicates how many units to allocate.
device		random		# Entropy device
device		loop		# Network loopback
device		ether		# Ethernet support
device		pty		# Pseudo-ttys (telnet etc)

>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

dumping to dev ad0s1b, offset 139376
dump ata0: resetting devices ..
[the system hangs dead at this point sometimes]

A stack trace looks like as follows (sorry, the above bp pointer
doesn't match the stack trace):

#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492
#1  0xc0167847 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335
#2  0xc0167c81 in panic (fmt=0xc0224c01 "bremfree: bp %p not locked")
    at /usr/src/sys/kern/kern_shutdown.c:634
#3  0xc01935d1 in bremfree (bp=0xc218debc) at /usr/src/sys/kern/vfs_bio.c:545
#4  0xc0194bcd in vfs_bio_awrite (bp=0xc218debc)
    at /usr/src/sys/kern/vfs_bio.c:1535
#5  0xc01cc6d4 in ffs_fsync (ap=0xc68819d4)
    at /usr/src/sys/ufs/ffs/ffs_vnops.c:239
#6  0xc01caf12 in ffs_sync (mp=0xc0dcae00, waitfor=2, cred=0xc05a6e00,
    td=0xc02a2b24) at vnode_if.h:441
#7  0xc019fb8d in sync (td=0xc02a2b24, uap=0x0)
    at /usr/src/sys/kern/vfs_syscalls.c:657
#8  0xc0167490 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:244
#9  0xc0167c81 in panic (fmt=0xc0235c5e "test panic")
    at /usr/src/sys/kern/kern_shutdown.c:634

>How-To-Repeat:

Just make a system of a close version panic.

>Fix:

I had better left it to the disk/fs subsystem wizards for now.
>Release-Note:
>Audit-Trail:

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
 
Responsible-Changed-From-To: freebsd-bugs->sos 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Sun Dec 30 04:32:38 PST 2001 
Responsible-Changed-Why:  
bde thinks the problem has to do with addump(). 

Soren, perhaps you can get more specific information out of Bruce? 
:-) 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32809 
Responsible-Changed-From-To: sos->freebsd-bugs 
Responsible-Changed-By: sos 
Responsible-Changed-When: Mon Jan 7 11:19:35 PST 2002 
Responsible-Changed-Why:  
Hmm, Dumping works just fine here, the problem might be more 
entangled ... 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32809 

From: "KAREN THODE" <thode12@msn.com>
To: <freebsd-gnats-submit@FreeBSD.org>, <yar@comp.chem.msu.su>
Cc:  
Subject: Re: kern/32809: yet another panic while syncing disks after a panic
Date: Tue, 24 Dec 2002 07:36:21 -0600

 ------=_NextPart_001_0000_01C2AB1F.27C82840
 Content-Type: text/plain; charset="iso-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 I have a suspicion that the KASSERT macro is panicking the system when it=
  is called from bremfree().
 
 ------=_NextPart_001_0000_01C2AB1F.27C82840
 Content-Type: text/html; charset="iso-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 <HTML><BODY STYLE=3D"font:10pt verdana; border:none;"><DIV>I have a suspi=
 cion that the KASSERT macro is panicking the system when it is called fro=
 m bremfree().<BR><BR></DIV></BODY></HTML>
 
 ------=_NextPart_001_0000_01C2AB1F.27C82840--

From: Yar Tikhiy <yar@FreeBSD.org>
To: KAREN THODE <thode12@msn.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/32809: yet another panic while syncing disks after a panic
Date: Wed, 25 Dec 2002 12:03:00 +0300

 On Tue, Dec 24, 2002 at 07:36:21AM -0600, KAREN THODE wrote:
 > I have a suspicion that the KASSERT macro is panicking the system when it is called from bremfree().
 
 It's the purpose of KASSERT() to panic the system if the assertion
 fails.
 
 -- 
 Yar
State-Changed-From-To: open->closed 
State-Changed-By: tjr 
State-Changed-When: Mon Aug 23 10:51:30 GMT 2004 
State-Changed-Why:  
-CURRENT no longer syncs disks after panics. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=32809 
>Unformatted:
