From owner-freebsd-hackers  Fri Feb 28 17:20:51 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA02053
          for hackers-outgoing; Fri, 28 Feb 1997 17:20:51 -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 RAA02042
          for <hackers@freebsd.org>; Fri, 28 Feb 1997 17:20:42 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA02248; Fri, 28 Feb 1997 20:20:05 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 28 Feb 1997 20: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 TAA11907; Fri, 28 Feb 1997 19:55:42 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id UAA05470; Fri, 28 Feb 1997 20:01:01 -0500 (EST)
Date: Fri, 28 Feb 1997 20:01:01 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199703010101.UAA05470@lakes.water.net>
To: ponds!lakes.water.net!rivers, ponds!lambert.org!terry
Subject: Re: Another installment of the "dup alloc"/"bad dir" panic problems.
Cc: ponds!freebsd.org!hackers
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


Terry Lambert writes:
> 
> > If you recall; I could trash a particular inode; run newfs and discover
> > the inode was not properly zero'd out (sometimes)  although I had
> > verified that the write() for that particular block, with a buffer
> > full of zeros, had been issued.
> > 
> > It now appears that having the printf()s in disksort() affects the problem
> > in a positive manner (that is, I'm not able to demonstrate the previous
> > "non-writing" behaviour I had seen; the inode in question is reliably
> > filled with zeros.)
> > 
> > I'm not sure what this means; does it point to some critical timing
> > situation required for causing the problem?  Does it point to missing
> > splXXX() call... would anyone care to comment?
> 
> Are you running IDE?
> 
> If so, is your IDE controller an RZ1000 or a CMB640b?
> 
> Both of these are known to fail undectably if they get an interrupt
> during a transfer operation.  Your printf's would "fix" this by
> allowing the transfer to complete by delaying the operation (probably
> significantly delaying it, in fact).  I have always been suspicious
> that the FreeBSD IDE driver "never exhibited the bug", even though
> no special steps were taken in coding it.
> 

 Yes, I wish it was that, I'd love to be done with this :-)

 However, this particular reproduction of the dup-alloc problem
is with an AHA 1542B and Micropolis ~500meg drive...

 So, now the question I'm considering is "what could be some
timing dependent that it affects both IDE and SCSI drivers?"

	- Dave Rivers -