From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 15 06:36:03 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A57F9F9E for ; Thu, 15 Nov 2012 06:36:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 655EF8FC0C for ; Thu, 15 Nov 2012 06:36:03 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1683143oag.13 for ; Wed, 14 Nov 2012 22:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=KyeacMcONs3LwiVC3+cByhjbeuW6SWqYeewRdQhEGk4=; b=MNLym9gF1wQRIzOYiA22lRONlZR6RjJVF5uRZ64BppMuNqy0C9pj8ReffGIA2nBNYX GaVJSt+DGwISQHO68Z+YhmpclLKi/LEPMsSLJrioYPx55azBODuuKfZg8HHhI4596jhr DqKuUgsHFCPA7rnTPMdU0IFDN20bj9ARBJ5QP+raJHJ6f9ks+xapBLHFRDLVwBgmc0EG 0Oksrl/f04EsEhh8UUD5hnfMfOyvtwfZACrWUrP37c5UwYXJUh1zO+o0KDaVuc0TsKv3 IxMH5fiaEoq5C8ItN6eNE+0U4eXHJdYfX356+3ay3TvjfF/4bUhmCVsm3jmZpUuBz4W6 iVxQ== MIME-Version: 1.0 Received: by 10.60.7.106 with SMTP id i10mr145680oea.5.1352961362809; Wed, 14 Nov 2012 22:36:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.76.27.65 with HTTP; Wed, 14 Nov 2012 22:36:02 -0800 (PST) Date: Wed, 14 Nov 2012 22:36:02 -0800 X-Google-Sender-Auth: i_04kKxApxX1HVjpb28BzI8gtfI Message-ID: Subject: Today's wireless update - TL;DR - please test -HEAD From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 06:36:03 -0000 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