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.)
now uses the DMACSR_READ bit and no longer keeps _nd_dmadir in softc
unified transfer cleanup code, now in routine next_dma_finish_xfer()
fixed bounds checking on registers after transfer.
removed checking for bus errors since the bit is always set on some nexts
(specifically, on mourning, a 25mhz 68040 mono slab)
fixed a couple of dma bugs involving chaining dma buffers.
DMACSR_READ is now a CSR status bit which can be used to know if current transfer is
from cpu to device.
the old DMACSR_READ bit is renamed DMACSR_SETREAD. This is a control bit that tells
the dma transfer to be from cpu to device.
write operations appear to lose scsi interrupts and causes timeouts.
changes in this checkin include:
a nextdma bugfix causing a diagnostic check to erroneously trigger
Changed tail strategy to only use tail buffer for the minimal end slop
changed expected write dma overrun to 32 bytes.
turned on nextdma diagnostic check for dma end address since it
no longer gets triggerred by ethernet dma and helps debug scsi dma.
Added esp debugging printout and support.
a filesystem, but is not stable enough yet for general use.
increased priority of ethernet interrupts, mostly useful to aid debugging
of scsi interrupts while using an nfs disk.
added additional debugging output in the next dma driver.
perform extranneous cache flushes/purges before dma reads/ after dma writes
to aid debugging of scsi dma.
This fix removes putting 0xfeedbeef in the unused restart registers.
When that was done, the machine would panic after a short while
with 0xfeedbeef in the normal dma buffer registers. A restart
cycle is probably hapenning without an interrupt or something.
of DD_NEXT for regular dma transfers, and not just ethernet transmit.
Keep track of dma read/write direction and set it each time we start or
restart dma. This allows scsi to work, and doesn't appear to hinder ethernet.
