Date: Sun, 2 Mar 1997 08:17:26 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!root.com!dg, ponds!lakes.water.net!rivers, ponds!lambert.org!terry Cc: ponds!freebsd.org!freebsd-hackers Subject: Re: Another installment of the "dup alloc"/"bad dir" panic problems. Message-ID: <199703021317.IAA13157@lakes.water.net>
next in thread | raw e-mail | index | archive | help
> > > 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?" > > 1542B? > > How much RAM do you have? > > If you have more than 16M ... it's bouncing. Try backing down to > 16M and not bouncing and see if that's where it is... > > > Terry Lambert Another good idea - but I only have 12 meg in this particular machine. Also, you should recall that I am experiencing this problem on an 8-meg 386dx (intel 387) with an IDE drive... that kinda points to something "higher-level" then the physical device drivers... Right now, I'm mulling over race conditions in disksort(). Something along the lines of: start to add buf to beginning of queue take an interrupt indicating previous I/O was complete remove partially added buf wow - lost buffer... disksort() appears to be run at splbio() [it's not obvious from the SCSI code that's what's going on, but the wd.c code definitely dones that.] If the interrupt comes in at just the right time, it seems there is a potential to loose a buffer... which I think is what I'm seeing. [That would also explain why adding a printf() to disksort masked the problem.] I'm going to play with this idea a while and see if I can verify it... - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703021317.IAA13157>