From owner-freebsd-hackers Tue Mar 4 18:20:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA10670 for hackers-outgoing; Tue, 4 Mar 1997 18:20:44 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA10662 for ; Tue, 4 Mar 1997 18:20:41 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA10111; Tue, 4 Mar 1997 21:20:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 4 Mar 1997 21:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id UAA04000; Tue, 4 Mar 1997 20:51:54 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id UAA00285; Tue, 4 Mar 1997 20:57:34 -0500 (EST) Date: Tue, 4 Mar 1997 20:57:34 -0500 (EST) From: Thomas David Rivers Message-Id: <199703050157.UAA00285@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers, ponds!lambert.org!terry Subject: "dup alloc" - nope - kern/2875 wasn't it. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well; it's a sad day in Mudville... Unfortunately, when I built from a pristine source base, with only the vfs_subr.c patch; I was able to reproduce my bad inodes.... Seems that the combination of a couple of printf()s in the kernel and that particular splbio()/splx() masks the problem just as my printf()s in disksort did... So, my previous elation was misplaced. Don't misunderstand; I believe the fix needs to be there - it just didn't address my particular problem. I also note that vfs_subr.c, in 2.1.6.1 didn't have any splxxx() calls in it, was a lot of work done in this area for 2.2? Anyway - I'll keep looking for the culprit.... I have the feeling it's something along these lines (a missing splbio(), or an splbio()/splx mis-match.) - But, that's just a guess... By the way; I have noticed that around the time in the newfs when this particular block should be written; the SCSI light goes off, say, for 1/2 second. This seems to be rather large considering that: 1) The length of the buf queue is never greater than 1. 2) The blocks (during the newfs operation) are in ascending order. I wonder why, on a "fixit" shell when nothing else is running, the disk drive pauses like that. It could be related.... - Dave Rivers -