Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!telmail!neabbs!ajbrouw
From: ajbrouw@neabbs.UUCP (ALBERT-JAN BROUWER)
Newsgroups: comp.sys.amiga.hardware
Subject: 32bit DMA lockups (Was: More info on A2091 woes)
Message-ID: <555376@neabbs.UUCP>
Date: 1 Feb 91 21:13:29 GMT
Organization: NEABBS multi-line BBS +31-20-5733533 (20x), Amsterdam, Holland.
Lines: 63


Hey CBM, this message is worth a CAT-Scan or two :-). If you know about
the problem I'm about to describe please comment. I would like know
whether the problem is actually being addressed.

Gregory Travis wrote:
> Here is some more information for Commodore/Randell.  As I posted before
> and as Randell suggested, turning off reselection on the A2091 with
> 5.92 ROMS and the WD "A" chip is NOT sufficient to avoid the lockup
> problem.  First of all, my configuration:
>
>	1 A2500/30 with 4 Meg of 32-Bit RAM
>	1 A2091 with ROM V5.92 and the WD "A" chip.  2 Meg of 16-bit RAM
>	  on the board.
> etc. etc.

I think you might be suffering from two separate problems here Gregory.
The 2091 WD reselection thing has been highlighted sufficiently I think.

However, there is a problem with _SOME_ 2630 cards while doing DMA to/from
32bit memory. I've determined this through experimentation, and by hearing
from other people having exactly the same problem (probably including you).

The problem tends to occur when the harddrive is in full swing DMA transfer,
unfortunately mostly during writes. A good way to evoke it is by running
DiskSpeed or some other write intensive program. When it occurs, the system
simply locks up, or barely makes it to the guru alert.

I've been able to reproduce it with both a HardFrame and a 2090a. A friend
of mine has the same trouble with a 2090a and a 4.x motherboard. I've
had my motherboard upgraded from 6.0 to 6.2 but the problem persisted.
Perhaps redundantly; we both have 2630 cards.

In a recent query to this group John Veldthuis reported exactly the same
problem, but amazingly this was with a 2620 and a HardFrame.

Note that the failure frequency varies a lot when swapping controllers
or slot positions; under one configuration it only occured once every
four avarage usage day equivalents. Still unacceptable ofcourse.


A fix? There is none. For the time being you may want to restrict DMA
access to non 32bit ram. The rudest way is to pull the plug (jumper)
on your 2630's 32 bit ram. An alternative is to set your DMA mask.
The mask isn't sufficiently specific; your 16bit fast is probably from
$600-$800, your 32 bit is at $200-$600 and the chip is below $100(000)
so you can only set the mask to limit DMA to chip memory (mask = ffffe)
This will cause harddrive access to slow down a _LOT_ though.
Also set the cache buffers to be allocated in chip memory, or else
you'll still lockup.

Another point is to avoid using disk optimizers and such, these will
cause DMA to 32bits mem because they bypass the filing system.
(The filing system is responsible for applying the DMA mask).

Medium term solution; modify addbuffers to allocate lots of 16 bit
mem buffers. Perhaps hack up your harddisk.device.

Sigh,

-Albert  (hp4nl!neabbs!ajbrouw)

"After 5 days of debugging efforts, I decided to
 let it win a core-wars competition instead."