Subject: CVS commit: syssrc
To: None <source-changes@netbsd.org>
From: Darrin B. Jewell <dbj@netbsd.org>
List: source-changes
Date: 01/12/2000 11:18:02
Module Name: syssrc
Committed By: dbj
Date: Wed Jan 12 19:18:01 UTC 2000
Modified Files:
syssrc/sys/arch/next68k/dev: nextdma.c
Log Message:
applied patch from "Christian Limpach" <chris@Nice.CH>:
I've fixed the problem that's been keeping me from using anything newer than
1.4.1 now. I tracked down the problem checkin, it's the big reorg of
nextdma.c between 1.19 and 1.20. It didn't introduce a new bug but it
activated a check which wasn't activated before. It's the
is-the-limit-in-the-right-window-check which was ifdeffed before because
some DMA-regs would sometimes have strange values. I think I've fixed the
DMA-reg stuff for now: at the end of nextdma_intr, when the csr is poked
to make DMA do something, I think the check for the ENABLE bit introduces a
race condition. I fixed this by unconditionally setting DMACSR_SETENABLE,
this seems to work and also makes the code more readable. I've also tried
setting DMACSR_SETSUPDATE unconditionally and this also works well, but I
don't know what it implies. Unless you have reasons to not set SUPDATE all
the time, I'd suggest making this change as well, it makes the code cleaner
and faster...
I've tested this patch and it does stop the panics, although I don't think setting
SUPDATE all the tima as he suggests is a good idea. The "SUPDATE" bit implies
a single update (i.e. the end of a dma chain.)
To generate a diff of this commit:
cvs rdiff -r1.20 -r1.21 syssrc/sys/arch/next68k/dev/nextdma.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.