Date: Wed, 14 Nov 2012 22:36:02 -0800 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Today's wireless update - TL;DR - please test -HEAD Message-ID: <CAJ-VmomapiffpfDe94i0BbH6x1vdE51G3dkMpbzA8k=3Uj1Qcg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi all, Here's another hacking update. The TL;DR version - please update to -HEAD if you're testing 802.11n on ath(4). * I've finished re-engineering the TX aggregation path in preparation for the AR9380 support. Rui reported a rather subtle bug and after a few days of narrowing it down, we nailed it this evening. I've been using an AR9380, AR9390 and AR9485 in 11n (STA) mode and verified that things are behaving quite nicely. * I've disabled the software queue pause/resume stuff for now, at least until I finish implementing a ps-poll implementation. Garrett Cooper donated a HP Touchpad to me (thanks Garrett!) that includes a dual-band atheros 600x wifi module. This does some pretty aggressive ps-poll behaviour for power saving, so it quickly showed the bugs that I had introduced. * I've added a (somewhat temporary) ALQ logging method to if_ath so I can start logging driver events. Until KTR lets me store arbitrary binary data and index it per driver, I plan on using this to debug TX and RX descriptors as well as some general events such as channel change/scan, reset, calibration and such. I'll also likely make the KTR debugging in ath(4) also log to the ath ALQ code. Why? Because I have a need to verify the device behaviour against both the rest of the scheduler framework (hence KTR) as well as against packet TX/RX (hence ALQ.) Right now the ALQ code logs the EDMA descriptors to ALQ (which I've been using to debug the TX aggregation support for AR9380) and I'll add this soon to the legacy descriptors. What I'm going to do next: * I'd like to extend the net80211 alq code I wrote to be per-device and per-vap. Right now it's global (but with a per-wlan marker.) Then I can remove if_ath_alq.[ch] and have the device log to the net80211 ALQ. That way I can combine driver events, descriptor events _and_ net80211 stack events in one ordered queue. That'll make debugging easier - imagine debugging powersave behvaiour or background scan by having this kind of light weight logging. Woo! No more printf debugging! * I'm going to finish off the ps-poll implementation for ath(4), so it first serves out frames from the driver software TX queue, before it goes to the net80211 power save queue. That requires a little more thought and planning. Once the ps-poll support is in the tree, I'll flip that back on and request people test things out. That should conclude the very basic support needed for saying "our 802.11n AP mode is ready!" * I'll teach ath(4) about the LDPC support in AR9380; * I'll teach the ath(4) rate control code to use LDPC and STBC on single-stream rates, but only where appropriate (ie, if the device supports it, if the device is TXing on two streams and whether the remote end has negotiated it.) It's a little more complicated - the HAL may have decided to only select one TX chain rather than the 2 or 3 that the device knows about. I'll have to fix that up, but STBC/LDPC are nice things to have. I'll also verify that the net80211 and ath driver code support 3 stream TX and RX, at least in STA mode Yes, yes I know, the AR9380 HAL code isn't yet public. I'm still working (slowly!) on that. These things take time! Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomapiffpfDe94i0BbH6x1vdE51G3dkMpbzA8k=3Uj1Qcg>