Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!caen!hellgate.utah.edu!csn!ub!dsinc!bagate!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: 32bit DMA lockups (Was: More info on A2091 woes)
Message-ID: <19141@cbmvax.commodore.com>
Date: 20 Feb 91 06:01:15 GMT
References: <555376@neabbs.UUCP> <00077@meph.UUCP>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 29

In article <00077@meph.UUCP> gsarff@meph.UUCP writes:
>I have been seeing messages about this and am curious.  Am I correct in
>assuming that the WD "A" chip is the WD3393A?  The reason I am asking is

	Yes.

>because I have been in the process of modifying our scsi driver, that
>previously worked with NCR boards, Adaptec boards, and our own controller
>based on the WD3393 chip.  I did have to do some modifications to our
>driver, though they were fairly minor as such things go.  I am wondering if
>it is the consensus here, among users, developers, or CATS people, or any
>combination thereof, that the "reselection" problem is the fault of the
>WD3393A chip or is some problem with the 2091 controller board itself
>and/or its interaction with the WD3393A chip.

	The problem is based on the fact that WD changed what the chip did
when it's reselected while you're trying to select a differect drive.  It
now requires us to "sniff" the interrupt queue or some such to figure out what
happened.  (I'm not the person writing the scsi stuff.)

	We used the low-level portions of the chip due to bugs in the high-
level portions in the pre-A versions (perhaps with reselect, I don't know).

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)