NetBSD/sys/arch/next68k
dbj b2236223c9 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.)
2000-01-12 19:18:00 +00:00
..
compile
conf resync with with hp300 port 2000-01-08 12:41:14 +00:00
dev applied patch from "Christian Limpach" <chris@Nice.CH>: 2000-01-12 19:18:00 +00:00
include C99: Define a NAN macro in <math.h> which evaulates to a constant expression of 1999-12-23 10:15:05 +00:00
next68k add % to register names 2000-01-08 12:38:27 +00:00
stand
Makefile fixed TAGS target for emacs style tags 1999-07-20 08:55:30 +00:00