From pherman@frenchfries.net  Sun Sep 10 03:19:20 2000
Return-Path: <pherman@frenchfries.net>
Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103])
	by hub.freebsd.org (Postfix) with ESMTP id 0035F37B422
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 10 Sep 2000 03:19:18 -0700 (PDT)
Received: from bagabeedaboo.security.at12.de (dial-213-168-73-12.netcologne.de [213.168.73.12])
	by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id MAA08774
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 10 Sep 2000 12:19:16 +0200 (MET DST)
Received: (from pherman@localhost)
	by bagabeedaboo.security.at12.de (8.11.0/8.11.0) id e8AAHXX00485;
	Sun, 10 Sep 2000 12:17:33 +0200 (CEST)
	(envelope-from pherman)
Message-Id: <200009101017.e8AAHXX00485@bagabeedaboo.security.at12.de>
Date: Sun, 10 Sep 2000 12:17:33 +0200 (CEST)
From: Paul Herman <pherman@frenchfries.net>
Reply-To: Paul Herman <pherman@frenchfries.net>
To: FreeBSD-gnats-submit@freebsd.org
Subject: panic in ffs_softdep.c: handle_workitem_freeblocks()
X-Send-Pr-Version: 3.2

>Number:         21162
>Category:       kern
>Synopsis:       panic in ffs_softdep.c: handle_workitem_freeblocks()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 10 03:20:01 PDT 2000
>Closed-Date:    Mon Aug 13 16:11:20 PDT 2001
>Last-Modified:  Mon Aug 13 16:12:34 PDT 2001
>Originator:     Paul Herman
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:

	-CURRENT from Sep 8th, 2000, with SOFTUPDATES.
	ufs/ffs/ffs_softdep.c rev1.73

>Description:

	Kernel panics when a snapshot is deleted, and syncer is forced
	to sync.  However, I don't think this has anything to do with
	snapshots, just big files in general.

>How-To-Repeat:

	# mount -u -o snapshot /bigfilesystem/snap /bigfilesystem
	# rm /bigfilesystem/snap
	# sync
	# sync
	# sync
	# sync
	# sync
	[...sync like there's no tomorrow until it panics...]

	I couldn't reproduce this on a filesystem with not very many
	inodes (~4500), so I think you need a lot ( ~112000 in my
	case) to get it to panic.  Probably a race condition of some sort?

>Fix:

	No idea, but here's the stack trace.  I have the vmcore and
	kernel still, so just let me know if you need any more info
	than what's supplied here.

(kgdb) bt -10
#10 0xc017c358 in panic (
    fmt=0xc02c7fe0 "handle_workitem_freeblocks: block count")
    at /usr/src/sys/kern/kern_shutdown.c:553
#11 0xc02437df in handle_workitem_freeblocks (freeblks=0xc09d1880)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:2020
#12 0xc02431b4 in softdep_setup_freeblocks (ip=0xc09c3600, length=0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:1709
#13 0xc023e2da in ffs_truncate (vp=0xc6146dc0, length=0, flags=0, cred=0x0, 
    p=0xc5675f40) at /usr/src/sys/ufs/ffs/ffs_inode.c:199
#14 0xc024c08f in ufs_inactive (ap=0xc5c78efc)
    at /usr/src/sys/ufs/ufs/ufs_inode.c:88
#15 0xc0251195 in ufs_vnoperate (ap=0xc5c78efc)
    at /usr/src/sys/ufs/ufs/ufs_vnops.c:2263
#16 0xc01ac0ee in vput (vp=0xc6146dc0) at vnode_if.h:794
#17 0xc024454c in handle_workitem_remove (dirrem=0xc09d5fc0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:2701
#18 0xc0241b50 in softdep_process_worklist (matchmnt=0x0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:555
#19 0xc01ab97c in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1020
(kgdb) sel 11
(kgdb) frame
#11 0xc02437df in handle_workitem_freeblocks (freeblks=0xc09d1880)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:2020
2020			panic("handle_workitem_freeblocks: block count");
(kgdb) list
2015			blocksreleased += btodb(bsize);
2016		}
2017	
2018	#ifdef DIAGNOSTIC
2019		if (freeblks->fb_chkcnt != blocksreleased)
2020			panic("handle_workitem_freeblocks: block count");
2021		if (allerror)
2022			softdep_error("handle_workitem_freeblks", allerror);
2023	#endif /* DIAGNOSTIC */
2024		WORKITEM_FREE(freeblks, D_FREEBLKS);
(kgdb) print freeblks->fb_chkcnt
$1 = 14048
(kgdb) print blocksreleased
$2 = 14032
(kgdb) print freeblks->fb_oldsize
$3 = 1536000000
(kgdb) quit

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Aug 12 16:35:23 PDT 2001 
State-Changed-Why:  

Is this still happening with more recent sources? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21162 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Mon Aug 13 16:11:20 PDT 2001 
State-Changed-Why:  

Submitter says this can be closed. Thanks! 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21162 
>Unformatted:
