Re: SCSI DMA problem on Falcon (Re: gcc4 problem on netbsd-4)

["T. Makinen" <tjamaloo%gmail.com@localhost>]

On Sat, Jan 3, 2009 at 6:57 AM, Izumi Tsutsui 
<tsutsui%ceres.dti.ne.jp@localhost> wrote:
> Ah, I see.
>
> Current ncr5380 driver allocates/frees pool memory for
> a DMA bounce buffer on per each transfer, but it could cause
> a fragmentation problem in the memory pool and it may
> prevent allocating contiguous up to 64kbyte buffers
> then causes the "pool exhausted" problem.
> (BTW in that case DMA seems disabled so the message may be harmless)

With ST_POOL_SIZE set to 24 "pool exhausted" problem was cured with
Falcon (with SCSI DMA):
http://mail-index.netbsd.org/port-atari/2008/11/13/msg000116.html

> I guess this can be solved by allocating a static buffer once at boot.
> (though I'm not sure if more than one DMA xfers could happen at once)
>
> The "wrong drive infomation" problem might be caused by
> DMA-cache coherency issue. We have to put some cache flush code
> around DMA xfer if the hardware doesn't support DMA bus snoop etc.
>
> There is a PCIA() call in ncr5380.c:dma_ready() to invalidate cache
> after DMA xfer, but I think it should be done even in !BOUNCING case.
> Maybe we also have to writeback cache on 040/060 (since we use PG_CCB)
> before DMA is started on write xfers.
>
> But I'm not sure if DMA xfers with cache flush ops is fater enough
> than PIO and it's worth to enable it...
>
> Necessary cache ops can be found in sys/arch/m68k/m68k/bus_dma.c and
> sys/arch/m68k/include/cacheops*.h, but it could be a bit huge changes.
> It's a bit pain to flush whole cache even on very small xfers,
> but cache flush ops against small and unaligned buffers often
> cause problems or large overheads.
> (see comments in bus_dum.c:_bus_dmamap_sync() in PREREAD case)

Thanks for the information :) About the performance; I have not performed any
tests with 68030 with DMA turned on/off, but at least with 68060 I'm pretty
satisfied with current SCSI performance.

-Tuomo