Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jul 1998 09:08:21 -0500
From:      Karl Denninger  <karl@mcs.net>
To:        The Hermit Hacker <scrappy@hub.org>
Cc:        scsi@FreeBSD.ORG
Subject:   Re: New problem - Adaptec cards with REV E on the sequencer chipset
Message-ID:  <19980728090821.09162@mcs.net>
In-Reply-To: <Pine.BSF.3.96.980728093345.15349H-200000@hub.org>; from The Hermit Hacker on Tue, Jul 28, 1998 at 09:36:03AM -0400
References:  <19980728071337.07188@mcs.net> <Pine.BSF.3.96.980728093345.15349H-200000@hub.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 28, 1998 at 09:36:03AM -0400, The Hermit Hacker wrote:
> 
> When I reported this problem on Friday, I was sent out the attached file
> which appears to have fixed the problem for me.  This will supposedly be
> in the next SNAPSHOT, but it should fix your problems too...
> 
> Disclaimer: I'm not one of hte SCSI developers, nor do I even presume to
> understand the code.  I just use 3.0-CURRENT+CAM on my own production
> server and know that this worked for me.
> 
> On Tue, 28 Jul 1998, Karl Denninger wrote:

The differences between the attached file (which I deleted) and the original
are:

diff aic7xxx.seq aic7xxx.seq.new
1343c1343
<               mvi     CCHCNT, 32;
---
>               mvi     CCHCNT, 28;
1351c1351
<                       bmov    CCSCBRAM, SCB_CONTROL, 32;
---
>                       bmov    CCSCBRAM, SCB_CONTROL, 28;
1365c1365
<               mvi     HCNT[0], 32;
---
>               mvi     HCNT[0], 28;
1373c1373
<               add     A, 32, SINDEX;
---
>               add     A, 28, SINDEX;
1382d1381
<               mov     DFDAT,SINDIR;
1455a1455,1456

That's it.  It looks like there was a change in the count of the number
of bytes moved to or from the SCB buffer from 32 to 28.

I don't know a thing about the sequencer hardware or why this is significant,
but this is what I see as a difference in the two versions.

FYI, it appears that the NON-CAM source is working with 28 bytes as well, 
but that code is *radically* different than the CAM version and I haven't
studied the differences in depth.

Does anyone know what, specifically, this fixes and whether or not this
problem could cause any other symptoms in a non-fixed CAM kernel 
(other than failures with REV E cards)?

The last change in the NON-CAM branch which was checked in is dated on 6/28;
was this the particular issue involved in that change?

--
-- 
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly / All Lines K56Flex/DOV
			     | NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980728090821.09162>