panic: ffs_blkfree: freeing free block (7.0-RC1)
Miroslav Lachman
I got kernel panic after removing 2GB file previously created by dd.
root@retezat ~/# dd if=/dev/zero of=/vol1/test.file bs=1m count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 132.726566 secs (16179757 bytes/sec)
root@retezat ~/# rm /vol1/test.file
and then I wanted to create same file on another mountpoint with
dd if=/dev/zero of=/vol0/test.file bs=1m count=2048
but system paniced and rebooted.
I done this many times before on the same machine and on the other
machines with the same version of FreeBSD without panic, so I don't know
why system paniced this time.
I am using gmirror from whole two disks.
/vol0 = USF2 + gjournal
/vol1 = UFS2 + SU
This is the first time I am reporting kernel panic, so let me know if I
can provide some more informations.
Note: this is 'production' machine, so I can't try to reproduce the panic.
See kgdb backtrace on the end of this e-mail
Miroslav Lachman
> gmirror list
Geom name: gm0
State: COMPLETE
Components: 2
Balance: round-robin
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 2
ID: 482383735
Providers:
1. Name: mirror/gm0
Mediasize: 494994980352 (461G)
Sectorsize: 512
Mode: r8w8e10
Consumers:
1. Name: ad4
Mediasize: 500107862016 (466G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: DIRTY
GenID: 0
SyncID: 2
ID: 877246835
2. Name: ad6
Mediasize: 500107862016 (466G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: DIRTY
GenID: 0
SyncID: 2
ID: 757379427
> gjournal list
Geom name: gjournal 344136938
ID: 344136938
Providers:
1. Name: mirror/gm0s2e.journal
Mediasize: 417680393728 (389G)
Sectorsize: 512
Mode: r1w1e1
Consumers:
1. Name: mirror/gm0s2d
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Mode: r1w1e1
Jend: 2147483136
Jstart: 0
Role: Journal
2. Name: mirror/gm0s2e
Mediasize: 417680394240 (389G)
Sectorsize: 512
Mode: r1w1e1
Role: Data
> df -ih
Filesystem Size Used Avail Capacity iused
ifree %iused Mounted on
/dev/mirror/gm0s1a 496M 129M 327M 28% 1830
63960 3% /
devfs 1.0K 1.0K 0B 100% 0
0 100% /dev
/dev/mirror/gm0s1e 7.7G 1.9G 5.2G 27% 206466
853372 19% /usr
/dev/mirror/gm0s1d 33G 2.8G 27G 9% 26519
4448359 1% /var
/dev/mirror/gm0s1f 2.4G 2.1M 2.2G 0% 1079
328647 0% /tmp
/dev/mirror/gm0s2e.journal 377G 18G 328G 5% 611265
50449469 1% /vol0
/dev/mirror/gm0s2f 19G 2.0G 16G 11% 3
2637819 0% /vol1
FreeBSD 7.0-RC1 #0: Mon Dec 24 12:18:24 UTC 2007
ro...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
root@retezat ~/# kgdb /boot/kernel/kernel /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
dev = mirror/gm0s2e.journal, block = 6417368, fs = /vol0
panic: ffs_blkfree: freeing free block
cpuid = 0
Uptime: 1d19h21m35s
Physical memory: 2035 MB
Dumping 290 MB: 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51
35 19 3
#0 doadump () at pcpu.h:195
195 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0xc0753f07 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc07541c9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc092becd in ffs_blkfree (ump=0xc59b7900, fs=0xc54a6000,
devvp=0xc597acc0, bno=6417368, size=16384, inum=4) at
/usr/src/sys/ufs/ffs/ffs_alloc.c:1893
#4 0xc093456a in ffs_indirtrunc (ip=0xc8c51108, lbn=-139276,
dbn=25591968, lastbn=-1, level=0, countp=0xe84bf920) at
/usr/src/sys/ufs/ffs/ffs_inode.c:619
#5 0xc0934525 in ffs_indirtrunc (ip=0xc8c51108, lbn=-2061, dbn=376384,
lastbn=-1, level=1, countp=0xe84bfa04) at
/usr/src/sys/ufs/ffs/ffs_inode.c:614
#6 0xc0935a3b in ffs_truncate (vp=0xc7a04110, length=0, flags=Variable
"flags" is not available.
) at /usr/src/sys/ufs/ffs/ffs_inode.c:418
#7 0xc0960056 in ufs_setattr (ap=0xe84bfb68) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:566
#8 0xc0a7d3c2 in VOP_SETATTR_APV (vop=0xc0bb2100, a=0xe84bfb68) at
vnode_if.c:583
#9 0xc07d7c76 in kern_open (td=0xc8470c60, path=0x38202043 <Address
0x38202043 out of bounds>, pathseg=UIO_USERSPACE, flags=Variable "flags"
is not available.
) at vnode_if.h:315
#10 0xc07d7de0 in open (td=0xc8470c60, uap=0xe84bfcfc) at
/usr/src/sys/kern/vfs_syscalls.c:995
#11 0xc0a67955 in syscall (frame=0xe84bfd38) at
/usr/src/sys/i386/i386/trap.c:1035
#12 0xc0a4dfb0 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:196
#13 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Pieter de Goeje
--
Pieter de Goeje
Miroslav Lachman
> What revision of sys/vm/vm_object.c do you have?
__FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19
05:48:45 alc Exp $");
System is FreeBSD 7.0-RC1 i386 installation.
Miroslav Lachman
Oliver Fromme
> panic: ffs_blkfree: freeing free block
I had exactly the same panic, also on a FreeBSD 7 system
with gmirror. I'm not sure if it's related, but I tell
you my story anyway ...
Apparently it was caused by a bug that caused corruption
in the file system. The bug was fixed in October, IIRC,
but the corruption remained and eventually crashed the
machine again. A forced fsck ("fsck -f -y") seems to have
fixed it for me finally.
So, my recommendation is this:
- Make sure you update to the latest sources.
- "fsck -f -y" all your filesystems in single-user mode.
Alternatively, newfs them and restore from backup.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"I invented Ctrl-Alt-Delete, but Bill Gates made it famous."
-- David Bradley, original IBM PC design team
Miroslav Lachman
> Miroslav Lachman wrote:
> > panic: ffs_blkfree: freeing free block
>
> I had exactly the same panic, also on a FreeBSD 7 system
> with gmirror. I'm not sure if it's related, but I tell
> you my story anyway ...
>
> Apparently it was caused by a bug that caused corruption
> in the file system. The bug was fixed in October, IIRC,
> but the corruption remained and eventually crashed the
> machine again. A forced fsck ("fsck -f -y") seems to have
> fixed it for me finally.
>
> So, my recommendation is this:
> - Make sure you update to the latest sources.
> - "fsck -f -y" all your filesystems in single-user mode.
> Alternatively, newfs them and restore from backup.
This was on 1 week old (brand new HW) machine. Just installed and put it
in production (migration from one datacenter to another) so I think that
it is not affected by anything from October or before. /vol0 and /vol1
was newfs-ed about 2 days befor kernel panic.
But thank you for suggesion anyway.
Miroslav Lachman
Pieter de Goeje
> Pieter de Goeje wrote:
> > What revision of sys/vm/vm_object.c do you have?
>
> __FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19
> 05:48:45 alc Exp $");
>
Hmm that's odd, some time ago I tracked this issue down to this commit, but
apparently there's still something wrong or the issue was fixed in another
commit in the same timeframe.
> System is FreeBSD 7.0-RC1 i386 installation.
Can you please try updating to the latest 7.0 (and/or 7-stable) to see if you
still can still reproduce this?
I will try to reproduce this here.
>
> Miroslav Lachman
--
Pieter de Goeje
Kostik Belousov
> On Tuesday 19 February 2008, Miroslav Lachman wrote:
> > Pieter de Goeje wrote:
> > > What revision of sys/vm/vm_object.c do you have?
> >
> > __FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19
> > 05:48:45 alc Exp $");
> >
>
> Hmm that's odd, some time ago I tracked this issue down to this commit, but
> apparently there's still something wrong or the issue was fixed in another
> commit in the same timeframe.
a post-check for something already gone wrong.
I would first check the filesystem with fsck and somehow verified
consistency of the mirror.
Another reason for the panic was fixed in rev. 1.50.10.1 of the
sys/ufs/ffs/ffs_balloc.c. But the conditions that caused panic fixed
in this rev. usually appear when filesystem becomes full.
Miroslav Lachman
> On Tuesday 19 February 2008, Miroslav Lachman wrote:
>
>>Pieter de Goeje wrote:
>>
>>>What revision of sys/vm/vm_object.c do you have?
>>
>>__FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19
>>05:48:45 alc Exp $");
>>
>
>
> Hmm that's odd, some time ago I tracked this issue down to this commit, but
> apparently there's still something wrong or the issue was fixed in another
> commit in the same timeframe.
>
>
>>System is FreeBSD 7.0-RC1 i386 installation.
>
>
> Can you please try updating to the latest 7.0 (and/or 7-stable) to see if you
> still can still reproduce this?
>
> I will try to reproduce this here.
I can't try to reproduce it, because it is production machine and I have
no other spare machine to play with. :(
Maybe in next two weeks I will buy another machine and will have time to
test it.
Miroslav Lachman