Date: Tue, 16 Dec 1997 10:51:44 -0500 (EST) From: Thomas David Rivers <rivers@dignus.com> To: ivt@gamma.ru, tlambert@primenet.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: blkfree: freeling free block/frag Message-ID: <199712161551.KAA13808@lakes.dignus.com>
next in thread | raw e-mail | index | archive | help
"Igor Timkin" <ivt@gamma.ru> writes: > > Terry Lambert writes: > > > Every 4-8 days my news server (~10 full incoming feeds, ~50 > > > outgoing feeds) crash: > > > panic: blkfree: freeing free block > > > or > > > panic: blkfree: freeing free frag > > > > Long Answer: > > > > Generally, this type of problem means you should rebuild the news spool, > > since *any* corruption could result in invalid information on the disk > > that could result in a panic. > > > > Most likely, you crashed once, and you expected fsck to do something > > that it can't do reliably: recover an async mounted partition. The > > partition was "recovered" and marked clean, but when you reference > > a particular disk metadata construct, it goes off into the weeds > > because the recovery was imperfect. > > Unfortunally, I still have this problem. > I had make newfs 5 days ago. But yestarday I got the same panic > (uptime 5.2 days): Yep - this looks _exactly_ like my "daily panic" problem I had on a full news feed... I wonder - did you happen to see John Dyson's recent post regarding a small VM patch to 2.2.5. It seems unrelated, but it could be a contributor to the problem. I haven't yet tried it on my stand-alone reproduction; but it might be worthwhile for you to try. A newfs, etc.. isn't going to fix this. For example; you can probably recreate it rather quickly by scribbling all over the disk (i.e. write 0xff all over the partition), doing a newfs - which should initialize things to their proper values, then doing an fsck to find out some of the 0xff values incorrectly remain (that's my stand-alone reproduction.) The "bug" - is that somehow a buffer is being incorrectly reused; but it seems to be _very_ timing dependent.. when I put nice printf()s in the kernel to try and track this down - the problem goes away. Making it extremely difficult to find... I've demonstrated it on a aha1542, and a 2748, and a IDE disk drive, so I don't believe it's hardware dependent (although the two SCSI versions were with the same SCSI disk drive - the IDE one, of course, was not) and with a 486 and a 386 and a 386sx. Sorry I don't have good news to add - but I wanted to add my experiences to help any curious readers... Also - if anyone has time and feels like debugging this; I have a serial-console setup on the machine that reproduces it. I can make accounts available to anyone to connect via the internet to this setup and have a "whack" at it. (i.e. log into the machine to which the serial console is connected... ) - Dave Rivers - > > ivt@news:/var/tmp/innfeed:2:306>gdb -k /sys/compile/NEWS/kernel /usr/local/news/crash/vmcore.1 > GDB is free software and you are welcome to 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. > GDB 4.16 (i386-unknown-freebsd), > Copyright 1996 Free Software Foundation, Inc... > IdlePTD 1f0000 > current pcb at 1d79c0 > panic: blkfree: freeing free block > #0 boot (howto=256) at ../../kern/kern_shutdown.c:266 > 266 dumppcb.pcb_cr3 = rcr3(); > (kgdb) where > #0 boot (howto=256) at ../../kern/kern_shutdown.c:266 > #1 0xe01105e2 in panic (fmt=0xe0188a85 "blkfree: freeing free block") > at ../../kern/kern_shutdown.c:390 > #2 0xe0188c57 in ffs_blkfree (ip=0xe3e50500, bno=10, size=4096) > at ../../ufs/ffs/ffs_alloc.c:1230 > #3 0xe018b09a in ffs_indirtrunc (ip=0xe3e50500, lbn=-12, dbn=394248, > lastbn=-1, level=0, countp=0xdfbffd9c) at ../../ufs/ffs/ffs_inode.c:500 > #4 0xe018aac8 in ffs_truncate (ap=0xdfbffe74) at ../../ufs/ffs/ffs_inode.c:317 > #5 0xe018e6a5 in ufs_inactive (ap=0xdfbffea0) at vnode_if.h:1003 > #6 0xe012fb3f in vrele (vp=0xe3b12800) at vnode_if.h:699 > #7 0xe012fa33 in vput (vp=0xe3b12800) at ../../kern/vfs_subr.c:858 > #8 0xe0191e80 in ufs_remove (ap=0xdfbffef4) at ../../ufs/ufs/ufs_vnops.c:697 > #9 0xe0131d25 in unlink (p=0xe4dc6e00, uap=0xdfbfff94, retval=0xdfbfff84) > at vnode_if.h:459 > #10 0xe01ac1ff in syscall (frame={tf_es = 39, tf_ds = -541130713, tf_edi = 1, > tf_esi = 28736, tf_ebp = -541074456, tf_isp = -541065244, > tf_ebx = 28944, tf_edx = 0, tf_ecx = 41472, tf_eax = 10, tf_trapno = 7, > tf_err = 7, tf_eip = 268950145, tf_cs = 31, tf_eflags = 582, > tf_esp = -541074568, tf_ss = 39}) at ../../i386/i386/trap.c:890 > #11 0x1007da81 in ?? () > #12 0x2453 in ?? () > #13 0x2914 in ?? () > #14 0x1095 in ?? ()
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712161551.KAA13808>