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>