Date: Fri, 28 Feb 1997 20:01:01 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!lakes.water.net!rivers, ponds!lambert.org!terry Cc: ponds!freebsd.org!hackers Subject: Re: Another installment of the "dup alloc"/"bad dir" panic problems. Message-ID: <199703010101.UAA05470@lakes.water.net>
next in thread | raw e-mail | index | archive | help
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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703010101.UAA05470>