From owner-freebsd-hackers  Tue May 19 05:27:38 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id FAA00156
          for freebsd-hackers-outgoing; Tue, 19 May 1998 05:27:38 -0700 (PDT)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from crocus.gamma.ru (crocus.gamma.ru [194.186.254.24])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA29978
          for <freebsd-hackers@FreeBSD.ORG>; Tue, 19 May 1998 05:27:08 -0700 (PDT)
          (envelope-from ivt@crocus.gamma.ru)
Received: (from ivt@localhost) by crocus.gamma.ru (8.8.8/8.7.3) id QAA16988; Tue, 19 May 1998 16:26:22 +0400 (MSD)
Message-Id: <199805191226.QAA16988@crocus.gamma.ru>
Subject: Re: panic: blkfree: freeling free block/frag
In-Reply-To: <199712051953.MAA16124@usr08.primenet.com> from Terry Lambert at "Dec 5, 97 07:53:14 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Tue, 19 May 1998 16:26:22 +0400 (MSD)
Cc: ivt@gamma.ru, freebsd-hackers@FreeBSD.ORG
From: "Igor Timkin" <ivt@gamma.ru>
Organization: Gamma Ltd., Moscow, Russia
X-Class: Fast
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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
> 
> [ ... ]
> 
> > /dev/ccd0c	/var/spool/news	ufs	rw,async,noatime,noexec,nosuid 0 2
> 
> [ ... ]
> 
> > dev=0x1502, block=20372, fs=/var/spool/news
> > panic: blkfree: freeing free frag
> > syncing disk 
> > (unfortunately at this point the system is freeze and I have
> > make the hardware reset, so I don't have crash dump).
> 
> [ ... ]
> 
> > Any suggestion ?
> 
> Short answer:
> 
> Your options are:
> 
> (1)	Live with it
> (2)	Don't mount the device async
> 
> 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.
> 
> 
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 

I solved this problem. After upgrade 2.2.5-REL to 3.0-971225-SNAP
my nntp server has uptime:
 4:20PM  up 38 days, 17:46, 7 users, load averages: 1.92, 1.68, 1.92
kernel configs and patches for 512M RAM are identical for both 2.2.5 and 3.0.
No any panics.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message