On Fri, 14 Jan 2005 21:48:56 -0500
Allen Briggs <briggs@netbsd.org> wrote:

> I've gone ahead and committed the change to MC_RXDMABUFS with the
> note that the driver really needs an introduction to bus_dma(9).
> If we can get the platform independent parts of the driver into
> src/sys/dev/ic, that would be great!  I think that needs some
> thought with dbdma involved...

I've made a lot of progress on this. Currently I have bus_dma working
just fine, and I have resolved a few other problems with the mc* as
well. I now have error reporting on the txdma interrupt (IRQ 2) working
reliably, and it turns out this is where DMDMA channel errors get
reported. I've been able to extract an error condition (0x20) from the
general purpose status bits in the tx DBDMA channel status field that
preceeds one of two hangups on receives. However, I have been unable to
locate any accurate documentation on these bits, so I can't say exactly
what the error is, nor how to handle it. I suspect that it is indicating
that I need to do some flow control, though, as the next error (0xa0) on
the general purpose status bits for the transmit channel is one that
accompanies the channel status being set to DBDMA_CNTRL_DEAD.

The mace chip is am79c940, as I've extracted the chip id to confirm
this. It does not implement full duplex ("duplex" isn't even in the chip
documentation), and because it is somehow woven into the Curio SCC
serial chip, the correct setting for the chip is GPSI, as opposed to the
more logical 10BaseT (this is in answer to a post from Paul Fromeyer
from a couple years ago). It's possible that (non-receive) DBDMA channel
interrupts only occur on the tx dma IRQ and it handles issues with both
tx and rx channels. I've seen some documents on the web that indicate
am79c940 was not designed for DBDMA, just DMA, and this causes some
problems, such as needing to not mask transmit dma interrupts in
order to get transmit dma interrupts.

In addition to needing to add a true tx dma interrupt handler and
registering it, I found one other thing needed to be done and one other
thing helped. Reversing the mc_putpacket DBDMA commands to be
DBDMA_INT_ALWAYS and DBDMA_INT_NEVER for 
DBDMA_CMD_OUT_LAST and DBDMA_CMD_STOP respectively (consistent with
other DBDMA transmit initial steps) enabled receiving interrupts on
IRQ 2. Dropping the IPL to IPL_BIO for the receive interrupt (IRQ 3) has
helped with responsiveness, but may need further examination. I want to
make sure no tx DBDMA channel interrupts get blocked by lots of
receiving activity, and that if the rx channel gets mucked it doesn't
block its only hope of recovering (plus without transmitting there's no
sending requests for more data, so this could be argued as needing to be
at a higher IPL).

I've also modified the mcwatchdog to do a better job of investigating
the problem, instead of just resetting the chip. It isn't always
necessary to do so, as it could be a case of not having read the XMTRC
register for two consecutive ethernet frames (the chip will refuse to
transmit any more until this is done). The lack of flow control could
also be the problem, so I try to hold off on resetting the chip until I
have determined that the DBDMA channel is dead. Even that could be made
more granular.

Overall speed looks promising, as I routinely see better than 1MB/sec
sustained (one direction).

The point to this email is that I'm looking for both testers, as some
solutions may be near (or not, as it has taken almost two weeks to
get to this point), and I will have an intermediate test kernel
available tomorrow, and for someone with DBDMA experience to
answer(offline) a couple of questions I have. I think I'm still missing
an error condition, and I need to make sure I implement flow control
within the DBDMA structure properly (one note I've read indicates that
stopping rx midstream can corrupt data immensely).

If you meet either qualification, please contact me offline.

thanks in advance,
tim