Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Sep 2012 20:39:02 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Berislav Purgar <bpurgar@gmail.com>
Cc:        freebsd-wireless@freebsd.org
Subject:   TXEOL semantics (was Re: broken TX in HEAD (AR5212))
Message-ID:  <CAJ-VmomXD3qHfgdCSvXL_3um9X-EQDJh0UGVAfWudMC1A1Ny-w@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Grr.

On 23 September 2012 15:32, Adrian Chadd <adrian@freebsd.org> wrote:
> That's not too scary; just slightly wasteful.
>
> But the annoying one:
>
> * I'm getting TXEOL interrupts appearing (which is by design, so
> that's OK) - but then when the descriptor is checked, the first
> descriptor in the list shows up as HAL_EINPROGRESS - and sure enough,
> the contents of that descriptor are not yet initialised. Now on my
> MIPS boards the descriptors are in KSEG1 - which is supposed to be
> unmapped, uncached memory. A subsequent TXEOL (from another descriptor
> being pushed into the queue) or TXOK (from that descriptor completing
> TX successfully) will kick the queue along.

... aaand yes, I've just discovered that TXEOL indeed can occur before
the descriptor(s) in the queue have been TXed and the TX status has
been written back. It just signals the MAC has hit the end of the TX
list for that hardware queue.

Grr. That software driven TX interrupt coalescing hack.. subtly wrong. :(



Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomXD3qHfgdCSvXL_3um9X-EQDJh0UGVAfWudMC1A1Ny-w>