Date: Sun, 10 Sep 2000 12:17:33 +0200 (CEST) From: Paul Herman <pherman@frenchfries.net> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/21162: panic in ffs_softdep.c: handle_workitem_freeblocks() Message-ID: <200009101017.e8AAHXX00485@bagabeedaboo.security.at12.de>
next in thread | raw e-mail | index | archive | help
>Number: 21162
>Category: kern
>Synopsis: panic in ffs_softdep.c: handle_workitem_freeblocks()
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Sep 10 03:20:01 PDT 2000
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009101017.e8AAHXX00485>
