Date: Tue, 26 Mar 2013 13:10:08 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Re: [wip] ar9300 hostap support Message-ID: <CAJ-Vmon7-g6DOdCsF05i4twfL_UXjBYUneGYts6dZbiFgH3zww@mail.gmail.com> In-Reply-To: <CAJ-VmomtQFjiGZRR0ME3HvGaJjHfXq%2BRT6a699UUDqGnJM1zjw@mail.gmail.com> References: <CAJ-Vmo=4QRuYeG8LmEfntTB2W5OyfsnVDCz5cJ__zWYbXkme3w@mail.gmail.com> <CAJ-VmomtQFjiGZRR0ME3HvGaJjHfXq%2BRT6a699UUDqGnJM1zjw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
.. 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. Thanks, Adrian On 25 March 2013 23:01, Adrian Chadd <adrian@freebsd.org> wrote: > Hi, > > Here's an update against the most recent -HEAD: > > http://people.freebsd.org/~adrian/ath/20130326-cabq-edma-tx-rework-5.diff > > 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. > > Thanks! > > > Adrian > > On 25 March 2013 16:13, Adrian Chadd <adrian@freebsd.org> wrote: >> Hi, >> >> I've been working on AR9380 HAL hostap support in my spare time. >> >> Here's where I'm at so far: >> >> http://people.freebsd.org/~adrian/ath/20130325-cabq-edma-txq-rework-3.diff >> >> 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 >> review!) >> * 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon7-g6DOdCsF05i4twfL_UXjBYUneGYts6dZbiFgH3zww>