Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Feb 1997 10:23:37 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        ponds!rivers@dg-rtp.dg.com (Thomas David Rivers)
Cc:        hackers@freebsd.org
Subject:   Re: Another installment of the "dup alloc"/"bad dir" panic problems.
Message-ID:  <199702281723.KAA02159@phaeton.artisoft.com>
In-Reply-To: <199702280334.WAA03821@lakes.water.net> from "Thomas David Rivers" at Feb 27, 97 10:34:33 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702281723.KAA02159>