From owner-freebsd-hackers Mon Apr 7 14:20:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA13871 for hackers-outgoing; Mon, 7 Apr 1997 14:20:51 -0700 (PDT) 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 OAA13864 for ; Mon, 7 Apr 1997 14:20:41 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA08255; Mon, 7 Apr 1997 17:20:09 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 7 Apr 1997 17:20 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id QAA27792 for ; Mon, 7 Apr 1997 16:49:24 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id QAA03948 for freebsd-hackers@freefall.cdrom.com; Mon, 7 Apr 1997 16:55:31 -0400 (EDT) Date: Mon, 7 Apr 1997 16:55:31 -0400 (EDT) From: Thomas David Rivers Message-Id: <199704072055.QAA03948@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Re: Some insight on "dup alloc" problems..... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tor Egge writes: > > I've narrowed the problem down to 8 lines (well, 5 if you don't > > count comments) in aha1542.c (recall - this is 2.1.7 source); around > > line 1670 or so, in the function aha_scsi_cmd(): > > > > if (!(flags & SCSI_NOMASK)) { > > if(debug) break_tdr4(); > > s = splbio(); /* stop instant timeouts */ > > timeout(aha_timeout, (caddr_t)ccb, (xs->timeout * hz) / 1000); > > aha_startmbx(ccb->mbx); > > /* > > * Usually return SUCCESSFULLY QUEUED > > */ > > splx(s); > > SC_DEBUG(xs->sc_link, SDEV_DB3, ("sent\n")); > > if(debug) break_tdr3(); > > debug = 0; > > return (SUCCESSFULLY_QUEUED); > > } > > > > > > notice the calls to "break_tdr4() and "break_tdr3()" - these are two > > empty functions just to be place-holders for ddb break points. > > Also, the variable "debug" is an auto that is set at the top of the > > function when the block is the one I'm interested in: > > > ... > > > > > If I break at the call to break_tdr4() - the problem is masked - it > > does *not* occur. > > > > If I break at the call to break_tdr3() - the problem is *not* masked - > > it does occur. > > > > So - it would seem that some interrupt is coming in that causes this > > timeout not to function properly... > > Is this on a 486 or higher with writeback cache enabled ? If that is > the case, some flushing to ensure the mbx having the correct values > might be needed before the command is activated. If not, you might > end up with the adapter reusing the 'old' scsi command. > > That would be consistent with breaking at break_tdr4 masking the > problem, while breaking at break_trd3 does not help. > > Just a theory ... If this is the case, then a wbinvd() call before the > mbx activation (but after the command being copied) might help. > > - Tor Egge > Unfortunately, this is a 386dx-33... it's also the second one of these I've installed an aha1542 into to replicate the problem. (That is, I've noticed this problem on two different 386dx-33 motherboards...) So, I wouldn't think cache problems are an issue here. [Although, reusing the 'old' command is certainly consistent with what I've been seeing...] In that environment; do you think that call would still be helpful? What exactly does wbinvd() do? I haven't stumbled across it in my 2.1.7.1 readings... - Thanks - - Dave Rivers -