Date: Mon, 7 Apr 1997 16:55:31 -0400 (EDT) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Re: Some insight on "dup alloc" problems..... Message-ID: <199704072055.QAA03948@lakes.water.net>
next in thread | raw e-mail | index | archive | help
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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704072055.QAA03948>