From owner-freebsd-hackers Wed Dec 17 10:48:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA01538 for hackers-outgoing; Wed, 17 Dec 1997 10:48:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01054 for ; Wed, 17 Dec 1997 10:42:55 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA14741; Wed, 17 Dec 1997 11:42:50 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd014684; Wed Dec 17 11:42:45 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA02077; Wed, 17 Dec 1997 11:42:40 -0700 (MST) From: Terry Lambert Message-Id: <199712171842.LAA02077@usr02.primenet.com> Subject: Re: panic: blkfree: freeling free block/frag To: mike@smith.net.au (Mike Smith) Date: Wed, 17 Dec 1997 18:42:38 +0000 (GMT) Cc: sclawson@bottles.cs.utah.edu, ivt@gamma.ru, tlambert@primenet.com, freebsd-hackers@freebsd.org In-Reply-To: <199712170635.RAA01913@word.smith.net.au> from "Mike Smith" at Dec 17, 97 05:05:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've been getting ``freeing free block'' panics fairly often when > > our main server is doing a bunch of large compiles. A couple weeks > > ago I finally caught it in the act. One of my compiles died and I > > found a source file with exactly 8k of gunk, sitting nicely on an 8k > > boundary (this was on an 8k/1k filesystem). The interesting thing > > about the file was it's list of direct blocks: > > > > 0: 179bb8 > > 1: 179bc0 > > 2: 179bc8 > > 3: 179bd0 > > 4: 179bd8 > > 5: 79be0 > > 6: 179be8 > > 7: 0 > > > > All nicely clustered...except for that sixth one. At first I > > thought that the clustering code was at fault, but disk block 79be0 > > was untouched, and the `real' disk block (179be0) had the correct data > > for the new file. So, the list of blocks in the inode was corrupted > > sometime after the data blocks for the file were written. > > Single-bit memory error, perhaps? Still, keep an eye on it... If this panic'ed, you need to look at the stack. I would prefer you look at the stack for #5. I do not believe this is a single bit error. I believe this is the same problem I have been seeing. Does your ethernet hardware address begin with 00 00? Look at the stack for the routines up from the routine in which it panic'ed, and see if (and how) it might have been stomped. There is no such thing as random data in the kernel (I will argue the random device with you nit-pickers, if you insist ;-)). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.