Hrm, this may be a side effect of the nextdma.c fix, but I can't be
sure.  I haven't seen this yet, although I've switched my main machine
to working on 1.4.2.  I should boot up another one to keep -current
working.

I wouldn't be too surprised to see this problem if the DMA stopped and
wasn't restarted correctly.  Since we no longer check for premature
DMA shutdowns, there still may be a race condition if the DMA shuts
down and we don't notice it.  (The nextdma.c patch fixed the race
condition if the dma shutdown between when we check and when we act on
it) There is probably a way around this.

 FYI: The "NDMAP: blah blah blah" is a dump of the complete nextdma
software and hardware state, which would explain what it was expecting
and what it actually found.  I don't recommend you type it in by hand,
but if you get it on a loggable serial console, save it around.

Darrin

Todd Whitesel <toddpw@best.com> writes:

> My 20000113 system managed to build a 20000116 kernel and userland, then
> while it was sitting idle, sendmail got hit by a dma panic.
> 
> NDMAP: blah blah blah...
> panic: DMA: Unexpected registers in finish_xfer
> 
> Stopped in sendmail at _cpu_Debugger+0x6:	unlk	a6
> db> trace
> _cpu_Debugger
> _panic
> _next_dma_finish_xfer
> _nextdma_intr
> _isrdispatch_autovec
> _intrhand_autovec
> _trap
> faultstkadj
> 
> (args omitted, I'm typing this while looking over my shoulder at the slab)
> 
> Todd Whitesel
> toddpw @ best.com