.. and it's all now in -HEAD.
Please update to -HEAD before you test out the AR9380 support.
Joshua - I've also put in a work around to stop things crashing on an
empty tx queue. It'll just log a warning.
I'm going to add some further debugging code to ensure that frames
going into a TXQ actually _have_ the right queue ID set in the
descriptor. It's quite possible that I've screwed this up somewhere.
On 25 March 2013 23:01, Adrian Chadd <adr...@freebsd.org> wrote:
> Here's an update against the most recent -HEAD:
> I've done some more basic interoperability with the station devices I
> have hiding around here. There's been no real issues thus far.
> I've committed some of the shared work (mostly to do with
> cabq/multicast queue) code to -HEAD already. It may affect both the
> pre-AR9380 and AR9380 series NICs. I'd appreciate it if people updated
> to -HEAD anyway and tested it out.
> On 25 March 2013 16:13, Adrian Chadd <adr...@freebsd.org> wrote:
>> I've been working on AR9380 HAL hostap support in my spare time.
>> Here's where I'm at so far:
>> Now, this is not likely what I'm going to push into -HEAD. But it's
>> being stable for me for now, save some odd crashes that have been
>> reported with TX completion on the AR9380 chips.
>> Now, what's going on and what I have to stage into -HEAD:
>> * The whole descriptor linking thing is just plain wrong for the
>> AR9380 chips. I have to nuke axq_link from orbit and use
>> ath_hal_settxdesclink(). This requires some manual fiddling of things
>> in a variety of places in both the pre-AR9380 chips and the AR9380
>> chips - it's used for CABQ assembly, for beacon programming, for
>> general unicast traffic programming ... eek.
>> * The CABQ assembly code needed to be tweaked for EDMA. Now I have to
>> populate the whole list of CABQ frames (with the correct link pointers
>> as listed above) before I can push that list into the hardware FIFO.
>> * I need to separate out the FIFO contents from the pending TX queue
>> in each hardware TXQ. Right now my EDMA TX code just pushes individual
>> MPDU or AMPDU frames into the FIFO and then waits until the FIFO
>> empties before pushing more frames in. I'm now changing it so there's
>> a separate "what's in the FIFO" queue, so..
>> * .. I can properly support the whole CABQ method of "these frames are
>> in the FIFO", because the CABQ support requires pushing multiple
>> frames (linked with the link pointer) into a single FIFO entry, .. and
>> * .. if I want to support restarting that queue during a stuck beacon
>> or other recoverable reset, I need to know where my FIFO frame
>> boundaries are.
>> Now, ath9k does it a bit differently - it has a split queue setup, but
>> the FIFO queue is a list of queues. I don't yet want to refactor
>> everything that way, so I'm just marking the start/end of each frame
>> list with ath_buf flags (ATH_BUF_FIFOPTR for the beginning and
>> ATH_BUF_FIFOEND for the last buffer in a list) and then making sure I
>> handle those right.
>> Now, this seems to work - in both encrypted (CCMP/TKIP) and open mode.
>> I'm not getting the high throughput I expect though - it looks like
>> I'm transmitting far too many single frames at the moment, rather than
>> being (more) aggressive at aggregation. I'll worry about that later.
>> This includes testing with stations in sleep mode (ie, traffic going
>> into the CABQ.)
>> Now, what's left?
>> * I have to finish converting over the axq_link references to
>> ath_hal_settxdesclink(), and kill axq_link as a concept.
>> * I need to figure out why we're seeing that panic with the AR9380 TX
>> completion FIFO saying that something is free on Q1 when the Q1 FIFO
>> is empty.
>> * I need to mark intermediary buffers in a buffer list with
>> ATH_BUF_BUSY, so they go onto the holdingbf queue. Otherwise the DMA
>> engine may hang (and this is a problem in ath9k too! Go go gadget code
>> * Lots, lots more testing.
>> I'd really like to figure out why the aggregation isn't as aggressive
>> as it could be. I'll dig into that later. I should be seeing ~
>> 250-280mbit TCP throughput on 3x3 HT40; but now I'm seeing ~150mbit
>> (ie, what I see with 2x2 HT/40.) That's obviously wrong. I'm seeing
>> very reliable MCS23 transmission and reception so it isn't that. It
>> seems to be something odd with how aggregates are being formed and
>> said aggregation logic seeming to transmit more single frames than
>> aggregate frames. Sigh.
>> Anyway. If you want to test it out, the patch above applies cleanly to
>> -HEAD and you _do_ need to update to the latest git HAL or encryption
>> just plain won't work.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"