Re: CVS commit: src/sys/dev/ic

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

dyoung%pobox.com@localhost wrote:

> > > use a nop with I bit set at the end of the tx chain.  This avoids a race
> > > between status update and clearing the suspend bit on machines which can't
> > > write data smaller than 32bits at a time.
> > This should fix PR port-alpha/30560.
> 
> It looks to me like this problem can be solved more simply by
> reading/writing the cb_status and cb_command fields simultaneously as
> one 32-bit word.

The problem is that fxp(4) driver has to update cb_command
bits during the cb_status possibly being updated by fxp chip.
They are both 16 bits and in the same 32 bit word,
so 16bit atomic op is required to solve it but it
isn't available on all alpha (it's the BWX extention
though all PCI generation alphas might have it,
which FreeBSD's fxp(4) does).

> BTW, it looks to me like there are some DMA barriers missing
> from fxp.  After fxp examines a transmit descriptor and finds
> that the completion bit, FXP_CB_STATUS_C, is clear, it should
> bus_dmamap_sync(BUS_DMASYNC_PREREAD) the descriptor.

I think fxp(4) may rely on BUS_DMAMEM_COHERENT at least on TX.
On RX, all RFA descriptors are allocated in mbufs so we have to
call DMA sync ops more strictly (on some cpus) though.
(see i82557.c rev 1.36)

> BTW, what is the cacheline size on the Alpha?

Not sure, but I think alpha is DMA-cache coherent
(no cache flush ops in bus_dmamap_sync(9)).

> Are the transmit
> descriptors cacheline-aligned?

Well, some descriptor members are not even 32bit aligned.
I guess "it's designed for Intel" anyway ;-p
(see also description about RFA_ALIGNMENT_FUDGE in i82557.c)
---
Izumi Tsutsui