dev = ad4s1a, block = 846584, fs = / panic: ffs_blkfree: freeing free flag cpuid = 0 KDB: enter: panic db>bt Tracing pid 1515 tif 100202 td 0xffffff011a290700 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 ffs_blkfree() at ffs_blkfree+0x699 ffs_truncate() at ffs_truncate+0x9db ufs_rmdir() at ufs_rmdir+0x1af VOP_RMDIR_APV() at VOP_RMDIR_APV+0x34 kern_rmdirat() at kern_rmdirat+0x2a5 syscall() at syscall+0x255 Xfast_syscall() at Xfast_syscall+0xab --- syscall(137,FreeBSD ELF64,rmdir), rip = 0x801044e5c, rsp = 0x7fffffffa528, rbp = 0x5122c0 --- How-To-Repeat: Unknow system panic when zpool export backup
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Hi, I think i've also the bug with panic: ffs_blkfree but my panic is : fsync: giving up on dirty 0xc3ff3114: tag devfs, type VCHR usecount 1, writecount 0, refcount 771 mountedhere 0xc3fac300 flags () v_object 0xc1045600 ref 0 pages 3836 lock type devfs: EXCL (count 1) by thread 0xc41a6690 (pid 1831) dev ad4s1f fsync: giving up on dirty 0xc3ff3114: tag devfs, type VCHR usecount 1, writecount 0, refcount 771 mountedhere 0xc3fac300 flags () v_object 0xc1045600 ref 0 pages 3836 lock type devfs: EXCL (count 1) by thread 0xc41a6690 (pid 1831) dev ad4s1f dev = ad4s1f, block = 1, fs = /usr panic: ffs_blkfree: freeing free block I've got this, two times i think when rebuilding the kernel, this is a FreeBSD 7.2-RELEASE installed last day in 7.2-RC2 and recompilled in 7.2-RELEASE. I can't reproduce this bug for the moment... Is it related ? Any informations about this bug ? Thx.
I just saw this on AMD64 on FreeBSD 8.0. I'm kind of surprised to see this still lingering around. Should I continue this problem report or submit a new one? Rusty Nejdl
On 9.3-i386 as well... http://flashback.sorbs.net/packages/crash/9.3-i386/core.txt.0.1424267734 Unread portion of the kernel message buffer: dev = ada0p2, block = 807357, fs = / panic: ffs_blkfree_cg: freeing free frag cpuid = 1 KDB: stack backtrace: #0 0xc0b0f96f at kdb_backtrace+0x4f #1 0xc0ad65af at panic+0x16f #2 0xc0d08172 at ffs_blkfree_cg+0x502 #3 0xc0d083ee at ffs_blkfree+0x9e #4 0xc0d2055b at freework_freeblock+0x51b #5 0xc0d22cf9 at handle_workitem_freeblocks+0x329 #6 0xc0d2166a at process_worklist_item+0x26a #7 0xc0d26241 at softdep_process_worklist+0x91 #8 0xc0d29070 at softdep_flush+0x3e0 #9 0xc0aa243f at fork_exit+0xcf #10 0xc0f88764 at fork_trampoline+0x8 Uptime: 17m3s Physical memory: 3499 MB Dumping 418 MB: 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump (textdump=1) at pcpu.h:250 250 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:250 #1 0xc0ad62f5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:454 #2 0xc0ad65f2 in panic (fmt=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:642 #3 0xc0d08172 in ffs_blkfree_cg (ump=0xc8493300, fs=0xc84a0000, devvp=0xc848d000, bno=807357, size=12288, inum=401407, dephd=0xee76eba4) at /usr/src/sys/ufs/ffs/ffs_alloc.c:2186 #4 0xc0d083ee in ffs_blkfree (ump=0xc8493300, fs=0xc84a0000, devvp=0xc848d000, bno=807357, size=12288, inum=401407, vtype=VREG, dephd=0xee76eba4) at /usr/src/sys/ufs/ffs/ffs_alloc.c:2292 #5 0xc0d2055b in freework_freeblock (freework=0xca18b500) at /usr/src/sys/ufs/ffs/ffs_softdep.c:7563 #6 0xc0d22cf9 in handle_workitem_freeblocks (freeblks=0xca0ce500, flags=512) at /usr/src/sys/ufs/ffs/ffs_softdep.c:7717 #7 0xc0d2166a in process_worklist_item (mp=0xc848bd34, target=10, flags=512) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1807 #8 0xc0d26241 in softdep_process_worklist (mp=0xc848bd34, full=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1591 #9 0xc0d29070 in softdep_flush () at /usr/src/sys/ufs/ffs/ffs_softdep.c:1447 #10 0xc0aa243f in fork_exit (callout=0xc0d28c90 <softdep_flush>, arg=0x0, frame=0xee76ed08) at /usr/src/sys/kern/kern_fork.c:996 #11 0xc0f88764 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:279 (kgdb)
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
This panic occurs when a disk write has an unrecoverable or undetected failure. Thus without further information on disk error statistics, it is impossible to determine what caused it. Several bugs have been fixed that used to lead to the ``fsync: giving up on dirty'' error (which was often triggered by earlier write failures). And there is on-going work to better handle write failures so that the filesystem is taken offline rather than crashing the system when disks fail.