Ok, here's a quick and dirty hack which I believe allows only one xmit
DMA packet per BMac xmit FrameSent interrupt.

I *_really_* don't understand the exact meanings of the dbdma command
bit fields here. Lacking documentation on this thing other than what's
here in the linux source tree (which aint much in the way of comments),
I'm merely guessing at the meanings.

But, if my understanding is correct, the BMac driver has never truly
been running in chained/streaming DMA mode. It's been DMAing one packet
per TxDma interrupt and then advancing the queue and restarting the
DMA engine!? Each entry in the queue gets both the OUTPUT_LAST and
INTR_ALWAYS fields set. I assume this means: "when you're done
with this DMA, stop and send an interrupt for service"?

Anyway, this may still allow for the noted Xmit multi-packet FIFO
collision/corruption problem you noted before. Although the window
of opportunnity is smaller - the DMA engine needs to be restarted
via the bmac_txdma_intr handler service before the Xmit FIFO emties
the data from the previous DMA?

Anyway, I've merely changed this to "INTR_NEVER" and replaced servicing
of the DMA xmit queue with a direct call to bmac_txdma_intr from the
bmac_misc_intr handler when FrameSent or TxUnderrun are true.

Incidentally, it appears that the FrameSent interrupt has been enabled
all along although nothing was being done for FrameSent interrupts in
bmac_misc_intr?

Oh, I just noticed that I've left TxUnderrun interrupts masked! I was
considering that this condition should result in restart of the Xmit
DMA engine. But I'm not sure if there are other recovery fixups needed
in this case. Oh well, it was disabled before and it's still disabled!

This may be the cause of future hangs? If we get an TxUnderrun, we
may not service it to restart the DMA engine. Any Rcv packet interrupt
conditions would unwedge it I guess. But it would still be hung 'til
we receive a packet?

-- 
Regards,
George