From owner-freebsd-wireless@FreeBSD.ORG Sun Sep 30 14:21:15 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F316106564A for ; Sun, 30 Sep 2012 14:21:15 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD6328FC0A for ; Sun, 30 Sep 2012 14:21:14 +0000 (UTC) Received: by yhfs35 with SMTP id s35so264335yhf.13 for ; Sun, 30 Sep 2012 07:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=6ysHQlobSQRY9HTB4ZL98QItSp3CN5DgW0yYEKfYcEA=; b=Fre0BlzWp7NO41KUvj6xIKRR7gWy/uCNT7H1MlviEODxOJqPjYwih7gfXfYGsY4L/Y VkDMt0gjX9JFI6lpoU3RMSY291PSXbR5ogzE6dQtCwmzv+naKTvB0ll31GPgAWMLdU4x VfYr2y3YNjM/u+q2boNvjirEyAssyYUYtjOFhBEjRrZ42EM/4dxLJXxlT1X4FsZLjUxP jpVyHmEOnLrEPvXVhPEkw81zkjxnxy4KPfJLuSgvnV7BAkpNufseAH746m2RmVHXCu1r DwALQVh6FNLfHVgn9LXdfvnbbFcQxgruaw3fsR59UMJvGsBDXGGsTkWM8ZY3ukDzfMpr iaEg== Received: by 10.236.151.103 with SMTP id a67mr12697715yhk.122.1349014868566; Sun, 30 Sep 2012 07:21:08 -0700 (PDT) Received: from [192.168.0.2] (173-17-34-224.client.mchsi.com. [173.17.34.224]) by mx.google.com with ESMTPS id j70sm21795814yhm.11.2012.09.30.07.21.07 (version=SSLv3 cipher=OTHER); Sun, 30 Sep 2012 07:21:08 -0700 (PDT) Message-ID: <50685552.7090905@gmail.com> Date: Sun, 30 Sep 2012 09:21:06 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Dual-band 802.11n support, in AP mode? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 30 Sep 2012 14:21:15 -0000 Subject pretty much says it all. I am in the market for a supported dual-band 802.11n wifi adapter, that can be used with FreeBSD to run as an access point. I have an old athlonxp 2000 that I intend to make into a custom router, but need to find a PCI (not PCI-e) or USB2.x adapter that I can use to provide wireless service to my home. I have 2 gigabit cards in the box already, as well as an external 5port gigabit switch.. I also have a single-band 2.4ghz .11n router currently, that I am using as an AP-only, but I would like to support the 5ghz band. I am open to the idea of simply replacing the router with a dual-band AP.. but I would prefer a PCI adapter. Any ideas on supported chipsets/adapters that meet these requirements? Thanks, Chuck Burns From owner-freebsd-wireless@FreeBSD.ORG Sun Sep 30 15:53:08 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 0BC3B106564A for ; Sun, 30 Sep 2012 15:53:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id D220F8FC16 for ; Sun, 30 Sep 2012 15:53:07 +0000 (UTC) Received: by dadz9 with SMTP id z9so1342872dad.13 for ; Sun, 30 Sep 2012 08:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=S4JRulxFhQmuIFfNVXIEVQ0LlkvezH0Z5XKfG7vA31Y=; b=Gh6t+sMnf/+ifSZmHQ20LeFbbQUGt8EktTReORd9XkoopksyHliMraP85/Bz0D6Ufl B+Pf9fwLi0oZzc7xc/q5u8X5iTOhWnJPR76M/bypAqx30b1l73G2PDjy7Xpo4hFHCV9L PvrtKWw+obXpbCZ5xd1IiSjFcjn/x23USwdIitncZsm5KZrEoIOdXftenCNO7ge0Z3PI KGYmWc5RNyA42gIIeNr8e0nNc5Uc0cBJELHBWLNkNvMw7/UAT6ydsbTE8H5jWqlVaCOJ vX+3glhZgwblm4PJZ+rZkw0CH7c/OHXvTgzcypWRvD1ReQgxThLpC9nIk/uO8qkJzg6d MsWA== MIME-Version: 1.0 Received: by 10.68.197.167 with SMTP id iv7mr34579864pbc.113.1349020380899; Sun, 30 Sep 2012 08:53:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.16.40 with HTTP; Sun, 30 Sep 2012 08:53:00 -0700 (PDT) In-Reply-To: <50685552.7090905@gmail.com> References: <50685552.7090905@gmail.com> Date: Sun, 30 Sep 2012 08:53:00 -0700 X-Google-Sender-Auth: hmaNi8sLYqPKr5rjAn1uVnnnEZE Message-ID: From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Dual-band 802.11n support, in AP mode? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 30 Sep 2012 15:53:08 -0000 Hi, Your best bet is to buy one of the supported Atheros 802.11n NICs - AR5416, AR9160, AR9220. AR9285 didn't come in a PCI flavour. The AR9227 is a PCI version of the AR9287, but it's 2GHz only. You can find PCI D-Link adaptors that have either AR9220 or AR5416 NICs in them. Be sure it's "dual band". Otherwise you could hunt down a PCI->MiniPCI cradle and use that. There are a lot more mini-PCI NICs out thre. Adrian On 30 September 2012 07:21, Chuck Burns wrote: > Subject pretty much says it all. > > I am in the market for a supported dual-band 802.11n wifi adapter, that can > be used with FreeBSD to run as an access point. > > I have an old athlonxp 2000 that I intend to make into a custom router, but > need to find a PCI (not PCI-e) or USB2.x adapter that I can use to provide > wireless service to my home. > > I have 2 gigabit cards in the box already, as well as an external 5port > gigabit switch.. > > I also have a single-band 2.4ghz .11n router currently, that I am using as > an AP-only, but I would like to support the 5ghz band. > > I am open to the idea of simply replacing the router with a dual-band AP.. > but I would prefer a PCI adapter. > > Any ideas on supported chipsets/adapters that meet these requirements? > > Thanks, > Chuck Burns > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Sun Sep 30 19:21:16 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 50C5A106566B for ; Sun, 30 Sep 2012 19:21:16 +0000 (UTC) (envelope-from sven@hazejager.nl) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 018B48FC15 for ; Sun, 30 Sep 2012 19:21:15 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so6418524vcb.13 for ; Sun, 30 Sep 2012 12:21:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ZNxaba0xBPkA0L7mZcDwOG1Iict+GXXujUDvpALIxaQ=; b=e9tDjfX4Zf0NzY1Hv1AD1e8EPiuL7xGPZScgAWHyLg78rxM7IulxoK4MSFI+kxGfqM KEAdXjQUFVqWHqNpBP11FTjaD29XYGJ331Tv1oEce9bHAtbu5mx3UKJIXgcrTukL9flV heaXXxAHiBmpHdFWM2wfm0dHzirlJ+aiEAO8VmGjsh+1IszaBeHiNb/elHjhnpElsf/N tKmwoU+3WBSRGac84B53e9sgFr4f1Kod2FO7LHYTFhtb7KjImN2JKhgytOPP5TL1k+9R XUfGbhVMIJgIQFpijDapjvF2tr9EOOFLrXzIHLjGNkzfsT8/JnfmUqft3FvDhCf63x1v AGsg== MIME-Version: 1.0 Received: by 10.52.19.198 with SMTP id h6mr5839349vde.78.1349032874928; Sun, 30 Sep 2012 12:21:14 -0700 (PDT) Received: by 10.220.141.82 with HTTP; Sun, 30 Sep 2012 12:21:14 -0700 (PDT) X-Originating-IP: [212.123.177.47] Date: Sun, 30 Sep 2012 21:21:14 +0200 Message-ID: From: Sven Hazejager To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmtPnGOSfoak4cP36PWcXtiQE96Yi9Lkf9TIg2u0SWZYq/wVTXDPmMjwx5oes7aR3P4bUwK Subject: Ath 40MHz on 2.4GHz? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 30 Sep 2012 19:21:16 -0000 Does ath on CURRENT support 40Mhz channels on 2.4GHz for 802.11n? If yes, how do I enable it? I now have in rc.conf: wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap" ifconfig_wlan0="inet 192.168.2.1 netmask 255.255.255.0 country NL mode 11ng channel 6:ht/40-" ifconfig -v wlan0 shows (amongst other things): status: running ssid KL5 channel 6 (2437 MHz 11g ht/40+) bssid 00:0b:6b:b1:3a:e7 I would like to use channel 1 as the secondary channel... Thanks Sven From owner-freebsd-wireless@FreeBSD.ORG Sun Sep 30 20:32:54 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 D210D106564A for ; Sun, 30 Sep 2012 20:32:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6F88FC0C for ; Sun, 30 Sep 2012 20:32:54 +0000 (UTC) Received: by dadz9 with SMTP id z9so1399523dad.13 for ; Sun, 30 Sep 2012 13:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0EzfouXHWz81YPV9mWpKGjOcBz4yDqUgEUAObxvHryM=; b=MCVg6LDs9VKZTObmsJt3fDKJ2w/jSBYhmngBMZtBQRFnbRdnQiy/RBf9To9spZ6EOl 8c9Cph9czpEmpuiJmPdNdYjNzdbaUH3xNulCCIyG8jOjiISQanqAyxPA+J2lFGxaS688 tKk9UF4ApqcX00aLrFizM63j8y9k6isF14UALKOxg7aN9eCmM7eOBU9Ie8tGvWQ3Y0CK 4Eb308QqIAThBOvf/tuaGRBFZOEN8kQSgLzZiWmTvU3vUldutqVyfe1JOCvcFakZaOMJ zxUujijZg+uJzOUdqrJmAg+YJVC48ZvI2LXMnmiF8Q7QJbEvWkGRHGme17dUFBgS4eJt aZvA== MIME-Version: 1.0 Received: by 10.68.197.167 with SMTP id iv7mr35917179pbc.113.1349037173999; Sun, 30 Sep 2012 13:32:53 -0700 (PDT) Received: by 10.68.16.40 with HTTP; Sun, 30 Sep 2012 13:32:53 -0700 (PDT) Received: by 10.68.16.40 with HTTP; Sun, 30 Sep 2012 13:32:53 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 Sep 2012 13:32:53 -0700 Message-ID: From: Adrian Chadd To: Sven Hazejager Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-wireless@freebsd.org Subject: Re: Ath 40MHz on 2.4GHz? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 30 Sep 2012 20:32:54 -0000 Theres supposed to be a limit on which ht40 are available. Ill double check later. The ht40 channels are supposed to be non overlapping, whch is difficult in 2ghz. Adrian On Sep 30, 2012 3:21 PM, "Sven Hazejager" wrote: > Does ath on CURRENT support 40Mhz channels on 2.4GHz for 802.11n? If > yes, how do I enable it? > > I now have in rc.conf: > > wlans_ath0="wlan0" > create_args_wlan0="wlanmode hostap" > ifconfig_wlan0="inet 192.168.2.1 netmask 255.255.255.0 country NL mode > 11ng channel 6:ht/40-" > > ifconfig -v wlan0 shows (amongst other things): > > status: running > ssid KL5 channel 6 (2437 MHz 11g ht/40+) bssid 00:0b:6b:b1:3a:e7 > > I would like to use channel 1 as the secondary channel... > > Thanks > Sven > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org > " > From owner-freebsd-wireless@FreeBSD.ORG Mon Oct 1 05:39:37 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 01EDD10661FF for ; Mon, 1 Oct 2012 05:39:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B1F628FC1B for ; Mon, 1 Oct 2012 05:39:36 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so4740269obb.13 for ; Sun, 30 Sep 2012 22:39:36 -0700 (PDT) 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=i0g7qziDATGRU9Mjob0wCuS91wTAgirjXntxkBDBPnk=; b=UmsNJhKY567FZzddwSn5Kuvu+Y/s8AoDY3SAYRrUj24rthpkLr2d/4o73imR0XnFaz MPN8xfbyRGPtxiXAtWhY7GgOpE+/EpKzSRhjdkzMoB16M8gp3QkyE+3E4ii1xNOCkx4U 4Rpq1YcaT+UJnIh32+W8z3/PtfMleYeXy8/WqpDTrzre5995oW+aDIYfiC82S/jpTDwc gOivivPsQV+4HRcPdaZgLXwGPLZS9aA1oK0blBEEbFDYEgYGQgHYBcHThu1lZsd3cOMt SX3lhsl3VQXLcmpIWxOI8NUsaEQlCEw3tJpLvVD4pSq4ozKkI8IkOZ/KjxKbJ9dW2be8 q46g== MIME-Version: 1.0 Received: by 10.182.177.99 with SMTP id cp3mr10656190obc.92.1349069976025; Sun, 30 Sep 2012 22:39:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.8.98 with HTTP; Sun, 30 Sep 2012 22:39:35 -0700 (PDT) Date: Sun, 30 Sep 2012 22:39:35 -0700 X-Google-Sender-Auth: -l1e-DMPJKV_C8MICWYKHVgGniI Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: multipart/mixed; boundary=e89a8f838d9db2bb2a04caf8d49e Subject: [RFC] Methodize the net8021 power save hooks X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 01 Oct 2012 05:39:37 -0000 --e89a8f838d9db2bb2a04caf8d49e Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm about to start tinkering with ath(4) power save support and I'd like to introduce some net80211 changes to support this. * Methodize the STA and node power save functions, so the driver can stop/start the software queues as needed; * Push PS-POLL frame leaking into a method, so the driver can override this if something is in a local queue. Since the driver may have some software queued frames for it, the driver needs to be able to leak these frames out correctly before the power-save queue frames are transmitted. My initial change to ath(4) will be to pause and unpause the node when the net80211 stack calls iv_node_ps() so the driver doesn't bother transmitting to a node that's asleep. There's a bunch of other needed changes that I'll then do in some follow-up work: * The TIM/ATIM doesn't know about what's in the software queue, so I'm going to have to introduce some further methods to allow the driver to update the TIM/ATIM as needed; * There's a M_PWR_SAV mbuf flag that means "this came from the power save queue". I need to see what/how drivers should treat this; * When a frame is sent via the PS-POLL method whilst a STA is asleep, the TIDs may be paused and as such the node won't transmit. In this case, frames pushed from the power save queue to the driver should immediately be transmitted, rather than punted to the software queue. * I also need to verify that the CABQ traffic is being set correctly- ie, the CABQ traffic all has the MORE bit appropriately set or cleared. * For nodes that are being sent PS-POLL (and later, uAPSD) delivered frames, they should be put "next" on the TX queue, ahead of any other TIDs that are being scheduled. That way their frame goes out next (or has a good chance to), versus being behind all the other currently transmitting (but not in power save) nodes. This should allow the device to quickly receive the frame and go back to sleep. I'm going to leave the next set of changes until I've done the first bit of work and verified it's working. I'll likely make that behaviour configurable because I'm worried that the incomplete PS-POLL upgrades will break mobile devices that try to stay in PS-POLL and "leak" frames (versus things like my MBP that just go in/out of power save and don't use PS-POLL at all.) adrian --e89a8f838d9db2bb2a04caf8d49e Content-Type: application/octet-stream; name="2012-09-30-powersave.diff" Content-Disposition: attachment; filename="2012-09-30-powersave.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7r5fkn20 SW5kZXg6IFVQREFUSU5HCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFVQREFUSU5HCShyZXZpc2lvbiAyNDEwODEp CisrKyBVUERBVElORwkod29ya2luZyBjb3B5KQpAQCAtMjQsNiArMjQsMTEgQEAKIAlkaXNhYmxl IHRoZSBtb3N0IGV4cGVuc2l2ZSBkZWJ1Z2dpbmcgZnVuY3Rpb25hbGl0eSBydW4KIAkibG4gLXMg J2Fib3J0OmZhbHNlLGp1bms6ZmFsc2UnIC9ldGMvbWFsbG9jLmNvbmYiLikKIAorMjAxMjEwMDE6 CisJVGhlIG5ldDgwMjExKDQpIEFCSSBoYXMgYmVlbiBjaGFuZ2VkIHRvIGFsbG93IGZvciBpbXBy b3ZlZCBkcml2ZXIKKwlQUy1QT0xMIGFuZCBwb3dlci1zYXZlIHN1cHBvcnQuICBBbGwgd2lyZWxl c3MgZHJpdmVycyBuZWVkIHRvIGJlCisJcmVjb21waWxlZCB0byB3b3JrIHdpdGggdGhlIG5ldyBr ZXJuZWwuCisKIDIwMTIwOTA4OgogCVRoZSBwZig0KSBwYWNrZXQgZmlsdGVyIEFCSSBoYXMgYmVl biBjaGFuZ2VkLiBwZmN0bCg4KSBhbmQKIAlzbm1wX3BmIG1vZHVsZSBuZWVkIHRvIGJlIHJlY29t cGlsZWQgdG8gd29yayB3aXRoIG5ldyBrZXJuZWwuCkluZGV4OiBzeXMvbmV0ODAyMTEvaWVlZTgw MjExX3N0YS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfc3RhLmMJKHJl dmlzaW9uIDI0MDk2OCkKKysrIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfc3RhLmMJKHdvcmtpbmcg Y29weSkKQEAgLTQwMiw3ICs0MDIsNyBAQAogCQkJICAgIGFyZyA9PSBJRUVFODAyMTFfRkMwX1NV QlRZUEVfQVNTT0NfUkVTUCk7CiAJCQlicmVhazsKIAkJY2FzZSBJRUVFODAyMTFfU19TTEVFUDoK LQkJCWllZWU4MDIxMV9zdGFfcHdyc2F2ZSh2YXAsIDApOworCQkJdmFwLT5pdl9zdGFfcHModmFw LCAwKTsKIAkJCWJyZWFrOwogCQlkZWZhdWx0OgogCQkJZ290byBpbnZhbGlkOwpAQCAtNDM4LDcg KzQzOCw3IEBACiAJCQlnb3RvIGludmFsaWQ7CiAJCWJyZWFrOwogCWNhc2UgSUVFRTgwMjExX1Nf U0xFRVA6Ci0JCWllZWU4MDIxMV9zdGFfcHdyc2F2ZSh2YXAsIDEpOworCQl2YXAtPml2X3N0YV9w cyh2YXAsIDEpOwogCQlicmVhazsKIAlkZWZhdWx0OgogCWludmFsaWQ6CkBAIC0xMzk2LDcgKzEz OTYsNyBAQAogCQkJCQkgKiB3ZSBhcmUgZXhwZWN0aW5nIGRhdGEuCiAJCQkJCSAqLwogCQkJCQlp Yy0+aWNfbGFzdGRhdGEgPSB0aWNrczsKLQkJCQkJaWVlZTgwMjExX3N0YV9wd3JzYXZlKHZhcCwg MCk7CisJCQkJCXZhcC0+aXZfc3RhX3BzKHZhcCwgMCk7CiAJCQkJfQogI2VuZGlmCiAJCQkJbmkt Pm5pX2R0aW1fY291bnQgPSB0aW0tPnRpbV9jb3VudDsKSW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVl ODAyMTFfcG93ZXIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3Bvd2Vy LmMJKHJldmlzaW9uIDI0MDk2OCkKKysrIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfcG93ZXIuYwko d29ya2luZyBjb3B5KQpAQCAtNjksNiArNjksOCBAQAogCQl2YXAtPml2X3VwZGF0ZV9wcyA9IGll ZWU4MDIxMV91cGRhdGVfcHM7CiAJCXZhcC0+aXZfc2V0X3RpbSA9IGllZWU4MDIxMV9zZXRfdGlt OwogCX0KKwl2YXAtPml2X25vZGVfcHMgPSBpZWVlODAyMTFfbm9kZV9wd3JzYXZlOworCXZhcC0+ aXZfc3RhX3BzID0gaWVlZTgwMjExX3N0YV9wd3JzYXZlOwogfQogCiB2b2lkCkluZGV4OiBzeXMv bmV0ODAyMTEvaWVlZTgwMjExX3Zhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXQ4MDIxMS9pZWVl ODAyMTFfdmFyLmgJKHJldmlzaW9uIDI0MDk2OCkKKysrIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFf dmFyLmgJKHdvcmtpbmcgY29weSkKQEAgLTQ4Niw2ICs0ODYsMTEgQEAKIAkvKiBwb3dlciBzYXZl IGhhbmRsaW5nICovCiAJdm9pZAkJCSgqaXZfdXBkYXRlX3BzKShzdHJ1Y3QgaWVlZTgwMjExdmFw ICosIGludCk7CiAJaW50CQkJKCppdl9zZXRfdGltKShzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKiwg aW50KTsKKwl2b2lkCQkJKCppdl9ub2RlX3BzKShzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKiwgaW50 KTsKKwl2b2lkCQkJKCppdl9zdGFfcHMpKHN0cnVjdCBpZWVlODAyMTF2YXAgKiwgaW50KTsKKwl2 b2lkCQkJKCppdl9yZWN2X3BzcG9sbCkoc3RydWN0IGllZWU4MDIxMV9ub2RlICosCisJCQkJICAg IHN0cnVjdCBtYnVmICopOworCiAJLyogc3RhdGUgbWFjaGluZSBwcm9jZXNzaW5nICovCiAJaW50 CQkJKCppdl9uZXdzdGF0ZSkoc3RydWN0IGllZWU4MDIxMXZhcCAqLAogCQkJCSAgICBlbnVtIGll ZWU4MDIxMV9zdGF0ZSwgaW50KTsKSW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfaG9zdGFw LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gc3lzL25ldDgwMjExL2llZWU4MDIxMV9ob3N0YXAuYwkocmV2aXNp b24gMjQwOTY4KQorKysgc3lzL25ldDgwMjExL2llZWU4MDIxMV9ob3N0YXAuYwkod29ya2luZyBj b3B5KQpAQCAtNzMsNyArNzMsNiBAQAogc3RhdGljIHZvaWQgaG9zdGFwX3JlY3ZfbWdtdChzdHJ1 Y3QgaWVlZTgwMjExX25vZGUgKiwgc3RydWN0IG1idWYgKiwKIAkgICAgaW50IHN1YnR5cGUsIGlu dCByc3NpLCBpbnQgbmYpOwogc3RhdGljIHZvaWQgaG9zdGFwX3JlY3ZfY3RsKHN0cnVjdCBpZWVl ODAyMTFfbm9kZSAqLCBzdHJ1Y3QgbWJ1ZiAqLCBpbnQpOwotc3RhdGljIHZvaWQgaG9zdGFwX3Jl Y3ZfcHNwb2xsKHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKIAogdm9p ZAogaWVlZTgwMjExX2hvc3RhcF9hdHRhY2goc3RydWN0IGllZWU4MDIxMWNvbSAqaWMpCkBAIC0x MDAsNiArOTksNyBAQAogCXZhcC0+aXZfcmVjdl9jdGwgPSBob3N0YXBfcmVjdl9jdGw7CiAJdmFw LT5pdl9vcGRldGFjaCA9IGhvc3RhcF92ZGV0YWNoOwogCXZhcC0+aXZfZGVsaXZlcl9kYXRhID0g aG9zdGFwX2RlbGl2ZXJfZGF0YTsKKwl2YXAtPml2X3JlY3ZfcHNwb2xsID0gaWVlZTgwMjExX3Jl Y3ZfcHNwb2xsOwogfQogCiBzdGF0aWMgdm9pZApAQCAtNjQ1LDcgKzY0NSw3IEBACiAJCSAqLwog CQlpZiAoKCh3aC0+aV9mY1sxXSAmIElFRUU4MDIxMV9GQzFfUFdSX01HVCkgXgogCQkgICAgKG5p LT5uaV9mbGFncyAmIElFRUU4MDIxMV9OT0RFX1BXUl9NR1QpKSkKLQkJCWllZWU4MDIxMV9ub2Rl X3B3cnNhdmUobmksCisJCQl2YXAtPml2X25vZGVfcHMobmksCiAJCQkJd2gtPmlfZmNbMV0gJiBJ RUVFODAyMTFfRkMxX1BXUl9NR1QpOwogCQkvKgogCQkgKiBGb3IgNC1hZGRyZXNzIHBhY2tldHMg aGFuZGxlIFdEUyBkaXNjb3ZlcnkKQEAgLTIyNDAsNyArMjI0MCw3IEBACiB7CiAJc3dpdGNoIChz dWJ0eXBlKSB7CiAJY2FzZSBJRUVFODAyMTFfRkMwX1NVQlRZUEVfUFNfUE9MTDoKLQkJaG9zdGFw X3JlY3ZfcHNwb2xsKG5pLCBtKTsKKwkJbmktPm5pX3ZhcC0+aXZfcmVjdl9wc3BvbGwobmksIG0p OwogCQlicmVhazsKIAljYXNlIElFRUU4MDIxMV9GQzBfU1VCVFlQRV9CQVI6CiAJCWllZWU4MDIx MV9yZWN2X2JhcihuaSwgbSk7CkBAIC0yMjUxLDggKzIyNTEsOCBAQAogLyoKICAqIFByb2Nlc3Mg YSByZWNlaXZlZCBwcy1wb2xsIGZyYW1lLgogICovCi1zdGF0aWMgdm9pZAotaG9zdGFwX3JlY3Zf cHNwb2xsKHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVjdCBtYnVmICptMCkKK3ZvaWQK K2llZWU4MDIxMV9yZWN2X3BzcG9sbChzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3Qg bWJ1ZiAqbTApCiB7CiAJc3RydWN0IGllZWU4MDIxMXZhcCAqdmFwID0gbmktPm5pX3ZhcDsKIAlz dHJ1Y3QgaWVlZTgwMjExX2ZyYW1lX21pbiAqd2g7CkluZGV4OiBzeXMvbmV0ODAyMTEvaWVlZTgw MjExX3Bvd2VyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldDgwMjExL2llZWU4MDIxMV9wb3dlci5o CShyZXZpc2lvbiAyNDA5NjgpCisrKyBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3Bvd2VyLmgJKHdv cmtpbmcgY29weSkKQEAgLTcxLDYgKzcxLDExIEBACiBzdHJ1Y3QgbWJ1ZiAqaWVlZTgwMjExX25v ZGVfcHNxX2RlcXVldWUoc3RydWN0IGllZWU4MDIxMV9ub2RlICpuaSwgaW50ICpxbGVuKTsKIGlu dAlpZWVlODAyMTFfbm9kZV9wc3FfZHJhaW4oc3RydWN0IGllZWU4MDIxMV9ub2RlICopOwogaW50 CWllZWU4MDIxMV9ub2RlX3BzcV9hZ2Uoc3RydWN0IGllZWU4MDIxMV9ub2RlICopOworCisvKgor ICogRG9uJ3QgY2FsbCB0aGVzZSBkaXJlY3RseSBmcm9tIHRoZSBzdGFjazsgdGhleSBhcmUgdmFw IG1ldGhvZHMKKyAqIHRoYXQgc2hvdWxkIGJlIG92ZXJyaWRkZW4uCisgKi8KIGludAlpZWVlODAy MTFfcHdyc2F2ZShzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKiwgc3RydWN0IG1idWYgKik7CiB2b2lk CWllZWU4MDIxMV9ub2RlX3B3cnNhdmUoc3RydWN0IGllZWU4MDIxMV9ub2RlICosIGludCBlbmFi bGUpOwogdm9pZAlpZWVlODAyMTFfc3RhX3B3cnNhdmUoc3RydWN0IGllZWU4MDIxMXZhcCAqLCBp bnQgZW5hYmxlKTsKSW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfaG9zdGFwLmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL25ldDgwMjExL2llZWU4MDIxMV9ob3N0YXAuaAkocmV2aXNpb24gMjQwOTY4 KQorKysgc3lzL25ldDgwMjExL2llZWU4MDIxMV9ob3N0YXAuaAkod29ya2luZyBjb3B5KQpAQCAt MzIsNCArMzIsMTAgQEAKICAqLwogdm9pZAlpZWVlODAyMTFfaG9zdGFwX2F0dGFjaChzdHJ1Y3Qg aWVlZTgwMjExY29tICopOwogdm9pZAlpZWVlODAyMTFfaG9zdGFwX2RldGFjaChzdHJ1Y3QgaWVl ZTgwMjExY29tICopOworCisvKgorICogVGhpcyBtZXRob2QgY2FuIGJlIG92ZXJyaWRkZW4KKyAq Lwordm9pZCBpZWVlODAyMTFfcmVjdl9wc3BvbGwoc3RydWN0IGllZWU4MDIxMV9ub2RlICosIHN0 cnVjdCBtYnVmICopOworCiAjZW5kaWYgLyogIV9ORVQ4MDIxMV9JRUVFODAyMTFfSE9TVEFQX0hf ICovCkluZGV4OiBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3NjYW4uYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvbmV0ODAyMTEvaWVlZTgwMjExX3NjYW4uYwkocmV2aXNpb24gMjQwOTY4KQorKysgc3lzL25l dDgwMjExL2llZWU4MDIxMV9zY2FuLmMJKHdvcmtpbmcgY29weSkKQEAgLTg2Niw3ICs4NjYsNyBA QAogCSAgICB2YXAtPml2X3N0YXRlID09IElFRUU4MDIxMV9TX1JVTikgewogCQlpZiAoKHZhcC0+ aXZfYnNzLT5uaV9mbGFncyAmIElFRUU4MDIxMV9OT0RFX1BXUl9NR1QpID09IDApIHsKIAkJCS8q IEVuYWJsZSBzdGF0aW9uIHBvd2VyIHNhdmUgbW9kZSAqLwotCQkJaWVlZTgwMjExX3N0YV9wd3Jz YXZlKHZhcCwgMSk7CisJCQl2YXAtPml2X3N0YV9wcyh2YXAsIDEpOwogCQkJLyoKIAkJCSAqIFVz ZSBhbiAxbXMgZGVsYXkgc28gdGhlIG51bGwgZGF0YSBmcmFtZSBoYXMgYSBjaGFuY2UKIAkJCSAq IHRvIGdvIG91dC4KQEAgLTEwNDcsNyArMTA0Nyw3IEBACiAJICogd2FpdGluZyBmb3IgdXMuCiAJ ICovCiAJaWYgKHNjYW5kb25lKSB7Ci0JCWllZWU4MDIxMV9zdGFfcHdyc2F2ZSh2YXAsIDApOwor CQl2YXAtPml2X3N0YV9wcyh2YXAsIDApOwogCQlpZiAoc3MtPnNzX25leHQgPj0gc3MtPnNzX2xh c3QpIHsKIAkJCWllZWU4MDIxMV9ub3RpZnlfc2Nhbl9kb25lKHZhcCk7CiAJCQlpYy0+aWNfZmxh Z3NfZXh0ICY9IH5JRUVFODAyMTFfRkVYVF9CR1NDQU47CkluZGV4OiBzeXMvbmV0ODAyMTEvaWVl ZTgwMjExX2FkaG9jLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldDgwMjExL2llZWU4MDIxMV9hZGhv Yy5jCShyZXZpc2lvbiAyNDA5NjgpCisrKyBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX2FkaG9jLmMJ KHdvcmtpbmcgY29weSkKQEAgLTI0Miw3ICsyNDIsNyBAQAogCQkJaWMtPmljX25ld2Fzc29jKG5p LCBvc3RhdGUgIT0gSUVFRTgwMjExX1NfUlVOKTsKIAkJYnJlYWs7CiAJY2FzZSBJRUVFODAyMTFf U19TTEVFUDoKLQkJaWVlZTgwMjExX3N0YV9wd3JzYXZlKHZhcCwgMCk7CisJCXZhcC0+aXZfc3Rh X3BzKHZhcCwgMCk7CiAJCWJyZWFrOwogCWRlZmF1bHQ6CiAJaW52YWxpZDoK --e89a8f838d9db2bb2a04caf8d49e-- From owner-freebsd-wireless@FreeBSD.ORG Mon Oct 1 05:43:13 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D541065702 for ; Mon, 1 Oct 2012 05:43:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E64DF8FC16 for ; Mon, 1 Oct 2012 05:43:12 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so4742505obb.13 for ; Sun, 30 Sep 2012 22:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ZQrDuJAIxxsy1ZAYMdFLiuvavEmj5CZ3uYqyk6R2hYo=; b=iWvR3LzcTkkZfMxowPjG1Mq4Lb++5c7AP9/qpcMk/o/gEbi2hGwOzUtylZ9lrMbxCv eLKdVy+w8SAgpI6y8MAN31pgcgW5kvHvPbBPLgQObQsO5HFOw01L3cuSJi9yg9H+TnCV 6ELOSm+sKkv6I0NsZbims9/UrvIoJTqVT6+NT5aLVEstHIDlLmpXXR5Z6e1jABGvUKji GdcENvO77Eq0X6Zn5OHCJtSiooFgB5wzzLbg1Zl9nbdG6BUqMbhw6BVlARwuMKIISY1R FlKYpOXTo0Qd1XOvYyLMLyN0+ZjSFDhXXbWi7d4Grkh1w4QnVd7BaIny8drGWDmZBzZz uNpA== MIME-Version: 1.0 Received: by 10.60.20.8 with SMTP id j8mr10742426oee.127.1349070192278; Sun, 30 Sep 2012 22:43:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.8.98 with HTTP; Sun, 30 Sep 2012 22:43:12 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 Sep 2012 22:43:12 -0700 X-Google-Sender-Auth: xTKaDtg29N8RTpKv8qKYC1h5v4E Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [RFC] Methodize the net8021 power save hooks X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 01 Oct 2012 05:43:13 -0000 .. oh and I should add: * Review all the MORE bit uses with traffic in the PSQ and the software queue when leaking frames out via PS-POLL. That's complicated as it has to check all TIDs for the existance of frames to TX, rather than a specific TID/AC. Adrian On 30 September 2012 22:39, Adrian Chadd wrote: > Hi, > > I'm about to start tinkering with ath(4) power save support and I'd > like to introduce some net80211 changes to support this. > > * Methodize the STA and node power save functions, so the driver can > stop/start the software queues as needed; > * Push PS-POLL frame leaking into a method, so the driver can override > this if something is in a local queue. > > Since the driver may have some software queued frames for it, the > driver needs to be able to leak these frames out correctly before the > power-save queue frames are transmitted. > > My initial change to ath(4) will be to pause and unpause the node when > the net80211 stack calls iv_node_ps() so the driver doesn't bother > transmitting to a node that's asleep. > > There's a bunch of other needed changes that I'll then do in some > follow-up work: > > * The TIM/ATIM doesn't know about what's in the software queue, so I'm > going to have to introduce some further methods to allow the driver to > update the TIM/ATIM as needed; > * There's a M_PWR_SAV mbuf flag that means "this came from the power > save queue". I need to see what/how drivers should treat this; > * When a frame is sent via the PS-POLL method whilst a STA is asleep, > the TIDs may be paused and as such the node won't transmit. In this > case, frames pushed from the power save queue to the driver should > immediately be transmitted, rather than punted to the software queue. > * I also need to verify that the CABQ traffic is being set correctly- > ie, the CABQ traffic all has the MORE bit appropriately set or > cleared. > * For nodes that are being sent PS-POLL (and later, uAPSD) delivered > frames, they should be put "next" on the TX queue, ahead of any other > TIDs that are being scheduled. That way their frame goes out next (or > has a good chance to), versus being behind all the other currently > transmitting (but not in power save) nodes. This should allow the > device to quickly receive the frame and go back to sleep. > I'm going to leave the next set of changes until I've done the first > bit of work and verified it's working. I'll likely make that behaviour > configurable because I'm worried that the incomplete PS-POLL upgrades > will break mobile devices that try to stay in PS-POLL and "leak" > frames (versus things like my MBP that just go in/out of power save > and don't use PS-POLL at all.) > > > > adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Oct 1 11:07:32 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 4EAB01065679 for ; Mon, 1 Oct 2012 11:07:32 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 285758FC19 for ; Mon, 1 Oct 2012 11:07:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q91B7Wsl025154 for ; Mon, 1 Oct 2012 11:07:32 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q91B7VlO025152 for freebsd-wireless@FreeBSD.org; Mon, 1 Oct 2012 11:07:31 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Oct 2012 11:07:31 GMT Message-Id: <201210011107.q91B7VlO025152@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-wireless@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 01 Oct 2012 11:07:32 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171394 wireless [ath] ath0: ath_tx_aggr_comp_aggr: num frames seen=1; o kern/171235 wireless [ath] ath loses connection, system freezes on netif re o kern/170904 wireless [ath] ath driver: configure related parameters when ra o kern/170889 wireless [ath] ath driver uses some uninitilized memory o kern/170620 wireless [ath] LOR and deadlock when multiple vaps are used o kern/170573 wireless [iwi] Intel 2200BG iwi NIC hangs with need multicast c o kern/170513 wireless [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: o kern/170433 wireless [ath] TX hang after a stuck beacon message with active o kern/170397 wireless [ath] [patch] Uninitialized variables in ah_eeprom_928 o kern/170302 wireless [ath] 802.11n frames are not being transmitted with mu o kern/170281 wireless [ath] 802.11n locks up on aggregation setup (ampdutx) o kern/170098 wireless [ath] [net80211] VAPs (Virtual access points) with Ath o kern/170066 wireless [ral] ral(4) rt61pci Linksys freezes the machine as so o kern/169432 wireless [ath] BAR TX hang when aggregation session is reset du p kern/169362 wireless [ath] AR5416: radar pulse PHY errors sometimes include o kern/169336 wireless [ath] ANI isn't triggering in a busy/noisy environment o kern/169199 wireless [ath] Cannot set up static ip addresses for wireless w o kern/169084 wireless [ath] suspend/resume doesn't cause a rescan; the assoc o kern/168530 wireless [ath] Broken WEP probably o kern/168393 wireless AR9285: suspend/resume sometimes fails o kern/168170 wireless [net80211] ieee80211_send_bar() doesn't complete corre o kern/167870 wireless [ath] adhoc wifi client does not join an existing IBSS o kern/167834 wireless [ath] kickpcu; 'handled 0 packets' o kern/167828 wireless [iwn] iwn(4) doesn't recover automatically after firmw o kern/167798 wireless ifconfig(8): problem with "ifconfig list scan" command o kern/167491 wireless [ath] TID != hardware queue TID in ath_tx_aggr_comp_ag o kern/167113 wireless [ath] AR5210: "stuck" TX seems to be occuring, without o kern/167080 wireless [ath] channel switch on another VAP break channel setu o kern/166684 wireless [ath] [net80211] mgmtrate/mcastrate isn't updated base p kern/166642 wireless [ieee80211] [patch] in 802.11n mode for FreeBSD AP, ha o kern/166641 wireless [ieee80211] [patch] mbuf/cluster leak in AP mode in 80 p kern/166357 wireless [ath] 802.11n TX stall when the first frame in the BAW o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing p kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in a sysct o kern/165969 wireless [ath] Slower performance in adhoc mode vs Client/AP mo o kern/165966 wireless [ath] ath0: device timeout on SMP machines due to race o kern/165895 wireless [ath] overly busy cabq can tie up all tx buffers o kern/165870 wireless [bwn] bwn driver does not attach on HP Pavilion dv9420 o kern/165866 wireless [ath] TX hangs, requiring a "scan" to properly reset t o kern/165849 wireless [ath] [hang] network ath driver freeze o kern/165595 wireless [ipw] ipw(4): Can't load firmare for ipw2200bg o kern/165543 wireless [ath] ath0 endless scanning of channels without connec o kern/165517 wireless [net80211] bgscan isn't triggered when invalid beacons o kern/165475 wireless [ath] operational mode change doesn't poke the underly o kern/165382 wireless [kernel] taskqueue_unblock doesn't unblock currently q o kern/165306 wireless [ath] race conditions between scanning and beacon time o kern/165220 wireless [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" m o kern/165214 wireless [ieee80211] Kernel panic in ieee80211_output.c:2505 o kern/165212 wireless [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB6 o kern/165149 wireless [ath] [net80211] Ping with data length more than iv_fr o kern/165146 wireless [net80211] Net802.11 Fragment number is assigned 1 (sh o kern/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/165021 wireless [ath] ath device timeout during scan/attach, if wlan_c o kern/164721 wireless [ath] ath device timeouts o kern/164499 wireless [wi] [patch] if_wi needs fix for big endian architectu o kern/164382 wireless [ath] crash when down/deleting a vap - inside ieee8021 o kern/164365 wireless [iwi] iwi0: UP/DOWN in o bin/164102 wireless hostapd not configured for 802.11n o kern/163759 wireless [ath] ath(4) "stops working" in hostap mode o kern/163724 wireless [mwl] [patch] NULL check before dereference o kern/163719 wireless [ath] ath interface do not receive multicast o kern/163689 wireless [ath] TX timeouts when sending probe/mgmt frames durin o kern/163574 wireless [net80211] overly-frequent HT occupancy changes o kern/163573 wireless [ath] hostap mode TX buffer hang o kern/163559 wireless [ath] kernel panic AH_DEBUG o kern/163318 wireless [ath] ath(4) stops working p kern/163312 wireless [panic] [ath driver] kernel panic: page fault with ath o kern/163237 wireless [ath] AR5416 as HostAP. Delays among clients when a cl o kern/163082 wireless [ath] ar9285 diversity fixes o kern/162648 wireless [ath] AR9227 ADC DC calibration failure o kern/162647 wireless [ath] 11n TX aggregation session / TX hang o kern/161293 wireless [iwn] hang at startup when starting network o kern/161035 wireless [ieee80211] Incorrect number describing 11ng MCS rate o kern/160391 wireless [ieee80211] [patch] Panic in mesh mode o kern/160296 wireless [zyd] [panic] 802.11 usb device reboots system on 'ifc o misc/160176 wireless [mips] [panic] Kernel panic on AR7161 platform with AR o kern/157449 wireless [ath] MAC address conflict causes system to freeze o kern/157243 wireless [ath] investigate beacon TX (AP) / RX (STA) when under o kern/156904 wireless [ath] AR9285 antenna diversity algorithm is buggy and o kern/156884 wireless [ath] ath instablity o kern/156327 wireless [bwn] bwn driver causes 20%-50% packet loss o kern/156322 wireless [wpi] no ahdemo support for if_wpi o kern/156321 wireless [ath] ahdemo doesn't work with if_ath o kern/155498 wireless [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155100 wireless [ath] ath driver on busy channel: "stuck beacon" p kern/154598 wireless [ath] Atheros 5424/2424 can't connect to WPA network o kern/154567 wireless [ath] ath(4) lot of bad series(0) o kern/154327 wireless [ath] AR5416 in station mode hangs when transmitting f o kern/154284 wireless [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154153 wireless [ath] AR5213 + MIPS + WPA group key packet corruption o kern/153594 wireless [wlan] netif/devd race o kern/153448 wireless [ath] ath networking device loses association after a o kern/152750 wireless [ath] ath0 lot of bad series hwrate o kern/151198 wireless [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: o kern/149786 wireless [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149516 wireless [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 wireless [realtek/atheros]: None of my network card working o kern/148322 wireless [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 wireless [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 wireless [ath] wireless networking stops functioning o kern/146426 wireless [mwl] 802.11n rates not possible on mwl o kern/146425 wireless [mwl] mwl dropping all packets during and after high u o kern/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using o kern/144755 wireless [wlan] netif/devd race o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o conf/143079 wireless hostapd(8) startup missing multi wlan functionality p kern/140567 wireless [ath] [patch] ath is not worked on my notebook PC o kern/140245 wireless [ath] [panic] Kernel panic during network activity on o kern/137592 wireless [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne p bin/137484 wireless [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/136943 wireless [wpi] [lor] wpi0_com_lock / wpi0 o kern/136836 wireless [ath] atheros card stops functioning after about 12 ho o kern/132722 wireless [ath] Wifi ath0 associates fine with AP, but DHCP or I o bin/131549 wireless ifconfig(8) can't clear 'monitor' mode on the wireless o kern/126475 wireless [ath] [panic] ath pcmcia card inevitably panics under o kern/125721 wireless [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 wireless [ath] [panic] ath(4) related panic o kern/125501 wireless [ath] atheros cardbus driver hangs o kern/125332 wireless [ath] [panic] crash under any non-tiny networking unde o kern/124767 wireless [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 wireless [ieee80211] net80211 discards power-save queue packets o docs/120456 wireless ath(4) needs to specify requirement on wlan_scan_sta o kern/119513 wireless [ath] [irq] inserting dlink dwl-g630 wireless card res o kern/116747 wireless [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile f kern/105348 wireless [ath] ath device stopps TX 128 problems total. From owner-freebsd-wireless@FreeBSD.ORG Wed Oct 3 15:05:24 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3EE6106566B for ; Wed, 3 Oct 2012 15:05:24 +0000 (UTC) (envelope-from lists@tomster.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC018FC0A for ; Wed, 3 Oct 2012 15:05:23 +0000 (UTC) Received: (qmail 35251 invoked from network); 3 Oct 2012 15:05:16 -0000 Received: from elektropost.org (HELO elektropost.org) (tom@tomster.org) by elektropost.org with AES128-SHA encrypted SMTP; 3 Oct 2012 15:05:16 -0000 From: Tom Lazar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 3 Oct 2012 17:05:15 +0200 To: freebsd-wireless@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: ath 802.11n support on FreeBSD 9.1? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 03 Oct 2012 15:05:24 -0000 hi, i'm running a homeserver with 9.1-PRERELEASE and would like it to = replace an existing Apple Airport Extreme access point. to this end i've added a mini-PCIe card with AR9280 chipset, which is = capable of 300Mbps. can i enable 802.11n support without switching to FreeBSD-HEAD? i'm a = bit reluctant to follow a branch that could break at any given moment, = or am i too paranoid here? on the one hand, the handbook[1] clearly = states that it's not meant for production but OTOH judging by the posts = on this list, it's not uncommon for folks to run it. any advice on how i should proceed? thanks! tom [1] http://www.freebsd.org/doc/en/books/handbook/current-stable.html= From owner-freebsd-wireless@FreeBSD.ORG Wed Oct 3 23:29:55 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 0BCA51065673 for ; Wed, 3 Oct 2012 23:29:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D42878FC16 for ; Wed, 3 Oct 2012 23:29:54 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so11991221pbb.13 for ; Wed, 03 Oct 2012 16:29:54 -0700 (PDT) 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=LFbuoWHSb2G4Tn8M4QIh82uceMQINtWcTHQrmsJAupc=; b=oGUmAT1x7NoHOrpL387E8zJ+bZk8niAmi+KGERzj0zu+GO/6c3C704CqVXui2/nPd+ JmC+2ghUKVLuEUGu4PcsXq9VNHeRdNS0meDAF1qL/wrAXp+YRlQ8d8zFGxYekVvky3AR 0lVun0/OAK4RrzALJffzIVejD9WNyFVik2X+f4lLv9S+p6EyWzNszpytURv/A88/i3k5 +OAzyeMfB6zu1Bk9VxmQA15c+Pp9VmyHQhg9klVYNfPz74SrCuaVeyAUEjpzPQEce/h+ 9H8Ltn+uwIsbT9pRAjqRJ3p9mNH3uHc/wQbRrYl7VHpbIxFfmAn4x8ZKStyILLHD1SrB Nc6g== MIME-Version: 1.0 Received: by 10.68.222.37 with SMTP id qj5mr16500064pbc.132.1349306994075; Wed, 03 Oct 2012 16:29:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Wed, 3 Oct 2012 16:29:54 -0700 (PDT) Date: Wed, 3 Oct 2012 16:29:54 -0700 X-Google-Sender-Auth: QCTTF4LKK_ELWq6SYOB6-xvCrSU Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [RFT] power-save TX suspend and resume (was Fwd: svn commit: r241170 - head/sys/dev/ath) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 03 Oct 2012 23:29:55 -0000 Hi, For those who are testing out 802.11n development - please update and test this for me. This work ties the software TX mechanism into the net80211 node power state, so whenever a wireless node sends a "going to sleep!" frame, the ath driver pauses TX. Same with wakeup/resume. Devices which are doing ps-poll will still be badly broken, unfortunately. And I have to fix TIM handling so the TIM bitmap takes the power save queue _and_ the driver software queue into account when deciding if to set or clear the TIM bitmap. That, and CABQ + MORE data bit stuff being set. Please report any issues you may have. The first thing to do is to turn on power save (wlandebug +power) and see if it's going in/out of powersave, along with whether it mentions ps-poll or not. I'm going to address ps-poll but first everything else has to work (TIM handling, software queue notification and CABQ/MORE data.) Thanks, Adrian ---------- Forwarded message ---------- From: Adrian Chadd Date: 3 October 2012 16:23 Subject: svn commit: r241170 - head/sys/dev/ath To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: adrian Date: Wed Oct 3 23:23:45 2012 New Revision: 241170 URL: http://svn.freebsd.org/changeset/base/241170 Log: Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.) Modified: head/sys/dev/ath/if_ath.c head/sys/dev/ath/if_ath_debug.h head/sys/dev/ath/if_ath_tx.c head/sys/dev/ath/if_ath_tx.h head/sys/dev/ath/if_athvar.h Modified: head/sys/dev/ath/if_ath.c ============================================================================== --- head/sys/dev/ath/if_ath.c Wed Oct 3 22:02:16 2012 (r241169) +++ head/sys/dev/ath/if_ath.c Wed Oct 3 23:23:45 2012 (r241170) @@ -199,6 +199,7 @@ static void ath_setcurmode(struct ath_so static void ath_announce(struct ath_softc *); static void ath_dfs_tasklet(void *, int); +static void ath_node_powersave(struct ieee80211_node *, int); #ifdef IEEE80211_SUPPORT_TDMA #include @@ -1138,6 +1139,9 @@ ath_vap_create(struct ieee80211com *ic, avp->av_bmiss = vap->iv_bmiss; vap->iv_bmiss = ath_bmiss_vap; + avp->av_node_ps = vap->iv_node_ps; + vap->iv_node_ps = ath_node_powersave; + /* Set default parameters */ /* @@ -5335,6 +5339,37 @@ ath_dfs_tasklet(void *p, int npending) } } +/* + * Enable/disable power save. This must be called with + * no TX driver locks currently held, so it should only + * be called from the RX path (which doesn't hold any + * TX driver locks.) + */ +static void +ath_node_powersave(struct ieee80211_node *ni, int enable) +{ + struct ath_node *an = ATH_NODE(ni); + struct ieee80211com *ic = ni->ni_ic; + struct ath_softc *sc = ic->ic_ifp->if_softc; + struct ath_vap *avp = ATH_VAP(ni->ni_vap); + + ATH_NODE_UNLOCK_ASSERT(an); + /* XXX and no TXQ locks should be held here */ + + DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE, "%s: ni=%p, enable=%d\n", + __func__, ni, enable); + + /* Suspend or resume software queue handling */ + if (enable) + ath_tx_node_sleep(sc, an); + else + ath_tx_node_wakeup(sc, an); + + /* Update net80211 state */ + avp->av_node_ps(ni, enable); +} + + MODULE_VERSION(if_ath, 1); MODULE_DEPEND(if_ath, wlan, 1, 1, 1); /* 802.11 media layer */ #if defined(IEEE80211_ALQ) || defined(AH_DEBUG_ALQ) Modified: head/sys/dev/ath/if_ath_debug.h ============================================================================== --- head/sys/dev/ath/if_ath_debug.h Wed Oct 3 22:02:16 2012 (r241169) +++ head/sys/dev/ath/if_ath_debug.h Wed Oct 3 23:23:45 2012 (r241170) @@ -66,6 +66,7 @@ enum { ATH_DEBUG_SW_TX_BAR = 0x100000000ULL, /* BAR TX */ ATH_DEBUG_EDMA_RX = 0x200000000ULL, /* RX EDMA state */ ATH_DEBUG_SW_TX_FILT = 0x400000000ULL, /* SW TX FF */ + ATH_DEBUG_NODE_PWRSAVE = 0x800000000ULL, /* node powersave */ ATH_DEBUG_ANY = 0xffffffffffffffffULL }; Modified: head/sys/dev/ath/if_ath_tx.c ============================================================================== --- head/sys/dev/ath/if_ath_tx.c Wed Oct 3 22:02:16 2012 (r241169) +++ head/sys/dev/ath/if_ath_tx.c Wed Oct 3 23:23:45 2012 (r241170) @@ -111,6 +111,9 @@ __FBSDID("$FreeBSD$"); */ #define ATH_NONQOS_TID_AC WME_AC_VO +#if 0 +static int ath_tx_node_is_asleep(struct ath_softc *sc, struct ath_node *an); +#endif static int ath_tx_ampdu_pending(struct ath_softc *sc, struct ath_node *an, int tid); static int ath_tx_ampdu_running(struct ath_softc *sc, struct ath_node *an, @@ -2902,9 +2905,17 @@ ath_tx_tid_resume(struct ath_softc *sc, DPRINTF(sc, ATH_DEBUG_SW_TX_CTRL, "%s: unpaused = %d\n", __func__, tid->paused); - if (tid->paused || tid->axq_depth == 0) { + if (tid->paused) + return; + + /* + * Override the clrdmask configuration for the next frame + * from this TID, just to get the ball rolling. + */ + tid->clrdmask = 1; + + if (tid->axq_depth == 0) return; - } /* XXX isfiltered shouldn't ever be 0 at this point */ if (tid->isfiltered == 1) { @@ -2912,12 +2923,6 @@ ath_tx_tid_resume(struct ath_softc *sc, return; } - /* - * Override the clrdmask configuration for the next frame, - * just to get the ball rolling. - */ - tid->clrdmask = 1; - ath_tx_tid_sched(sc, tid); /* Punt some frames to the hardware if needed */ //ath_txq_sched(sc, sc->sc_ac2q[tid->ac]); @@ -3021,6 +3026,7 @@ ath_tx_tid_filt_comp_single(struct ath_s * Don't allow a filtered frame to live forever. */ if (bf->bf_state.bfs_retries > SWMAX_RETRIES) { + sc->sc_stats.ast_tx_swretrymax++; DPRINTF(sc, ATH_DEBUG_SW_TX_FILT, "%s: bf=%p, seqno=%d, exceeded retries\n", __func__, @@ -3073,6 +3079,7 @@ ath_tx_tid_filt_comp_aggr(struct ath_sof * Don't allow a filtered frame to live forever. */ if (bf->bf_state.bfs_retries > SWMAX_RETRIES) { + sc->sc_stats.ast_tx_swretrymax++; DPRINTF(sc, ATH_DEBUG_SW_TX_FILT, "%s: bf=%p, seqno=%d, exceeded retries\n", __func__, @@ -5282,6 +5289,145 @@ ath_addba_response_timeout(struct ieee80 ATH_TXQ_UNLOCK(sc->sc_ac2q[atid->ac]); } +#if 0 +/* + * Check if a node is asleep or not. + */ +static int +ath_tx_node_is_asleep(struct ath_softc *sc, struct ath_node *an) +{ + + ATH_NODE_LOCK_ASSERT(an); + + return (an->an_is_powersave); +} +#endif + +/* + * Mark a node as currently "in powersaving." + * This suspends all traffic on the node. + * + * This must be called with the node/tx locks free. + * + * XXX TODO: the locking silliness below is due to how the node + * locking currently works. Right now, the node lock is grabbed + * to do rate control lookups and these are done with the TX + * queue lock held. This means the node lock can't be grabbed + * first here or a LOR will occur. + * + * Eventually (hopefully!) the TX path code will only grab + * the TXQ lock when transmitting and the ath_node lock when + * doing node/TID operations. There are other complications - + * the sched/unsched operations involve walking the per-txq + * 'active tid' list and this requires both locks to be held. + */ +void +ath_tx_node_sleep(struct ath_softc *sc, struct ath_node *an) +{ + struct ath_tid *atid; + struct ath_txq *txq; + int tid; + + ATH_NODE_UNLOCK_ASSERT(an); + + /* + * It's possible that a parallel call to ath_tx_node_wakeup() + * will unpause these queues. + * + * The node lock can't just be grabbed here, as there's places + * in the driver where the node lock is grabbed _within_ a + * TXQ lock. + * So, we do this delicately and unwind state if needed. + * + * + Pause all the queues + * + Grab the node lock + * + If the queue is already asleep, unpause and quit + * + else just mark as asleep. + * + * A parallel sleep() call will just pause and then + * find they're already paused, so undo it. + * + * A parallel wakeup() call will check if asleep is 1 + * and if it's not (ie, it's 0), it'll treat it as already + * being awake. If it's 1, it'll mark it as 0 and then + * unpause everything. + * + * (Talk about a delicate hack.) + */ + + /* Suspend all traffic on the node */ + for (tid = 0; tid < IEEE80211_TID_SIZE; tid++) { + atid = &an->an_tid[tid]; + txq = sc->sc_ac2q[atid->ac]; + + ATH_TXQ_LOCK(txq); + ath_tx_tid_pause(sc, atid); + ATH_TXQ_UNLOCK(txq); + } + + ATH_NODE_LOCK(an); + + /* In case of concurrency races from net80211.. */ + if (an->an_is_powersave == 1) { + ATH_NODE_UNLOCK(an); + device_printf(sc->sc_dev, + "%s: an=%p: node was already asleep\n", + __func__, an); + for (tid = 0; tid < IEEE80211_TID_SIZE; tid++) { + atid = &an->an_tid[tid]; + txq = sc->sc_ac2q[atid->ac]; + + ATH_TXQ_LOCK(txq); + ath_tx_tid_resume(sc, atid); + ATH_TXQ_UNLOCK(txq); + } + return; + } + + /* Mark node as in powersaving */ + an->an_is_powersave = 1; + + ATH_NODE_UNLOCK(an); +} + +/* + * Mark a node as currently "awake." + * This resumes all traffic to the node. + */ +void +ath_tx_node_wakeup(struct ath_softc *sc, struct ath_node *an) +{ + struct ath_tid *atid; + struct ath_txq *txq; + int tid; + + ATH_NODE_UNLOCK_ASSERT(an); + ATH_NODE_LOCK(an); + + /* In case of concurrency races from net80211.. */ + if (an->an_is_powersave == 0) { + ATH_NODE_UNLOCK(an); + device_printf(sc->sc_dev, + "%s: an=%p: node was already awake\n", + __func__, an); + return; + } + + /* Mark node as awake */ + an->an_is_powersave = 0; + + ATH_NODE_UNLOCK(an); + + for (tid = 0; tid < IEEE80211_TID_SIZE; tid++) { + atid = &an->an_tid[tid]; + txq = sc->sc_ac2q[atid->ac]; + + ATH_TXQ_LOCK(txq); + ath_tx_tid_resume(sc, atid); + ATH_TXQ_UNLOCK(txq); + } +} + static int ath_legacy_dma_txsetup(struct ath_softc *sc) { Modified: head/sys/dev/ath/if_ath_tx.h ============================================================================== --- head/sys/dev/ath/if_ath_tx.h Wed Oct 3 22:02:16 2012 (r241169) +++ head/sys/dev/ath/if_ath_tx.h Wed Oct 3 23:23:45 2012 (r241170) @@ -124,6 +124,12 @@ extern void ath_addba_response_timeout(s struct ieee80211_tx_ampdu *tap); /* + * AP mode power save handling (of stations) + */ +extern void ath_tx_node_sleep(struct ath_softc *sc, struct ath_node *an); +extern void ath_tx_node_wakeup(struct ath_softc *sc, struct ath_node *an); + +/* * Setup path */ #define ath_txdma_setup(_sc) \ Modified: head/sys/dev/ath/if_athvar.h ============================================================================== --- head/sys/dev/ath/if_athvar.h Wed Oct 3 22:02:16 2012 (r241169) +++ head/sys/dev/ath/if_athvar.h Wed Oct 3 23:23:45 2012 (r241170) @@ -170,6 +170,7 @@ struct ath_node { struct ieee80211_node an_node; /* base class */ u_int8_t an_mgmtrix; /* min h/w rate index */ u_int8_t an_mcastrix; /* mcast h/w rate index */ + uint32_t an_is_powersave; /* node is sleeping */ struct ath_buf *an_ff_buf[WME_NUM_AC]; /* ff staging area */ struct ath_tid an_tid[IEEE80211_TID_SIZE]; /* per-TID state */ char an_name[32]; /* eg "wlan0_a1" */ @@ -332,6 +333,8 @@ struct ath_txq { #define ATH_NODE_LOCK(_an) mtx_lock(&(_an)->an_mtx) #define ATH_NODE_UNLOCK(_an) mtx_unlock(&(_an)->an_mtx) #define ATH_NODE_LOCK_ASSERT(_an) mtx_assert(&(_an)->an_mtx, MA_OWNED) +#define ATH_NODE_UNLOCK_ASSERT(_an) mtx_assert(&(_an)->an_mtx, \ + MA_NOTOWNED) #define ATH_TXQ_LOCK_INIT(_sc, _tq) do { \ snprintf((_tq)->axq_name, sizeof((_tq)->axq_name), "%s_txq%u", \ @@ -379,6 +382,7 @@ struct ath_vap { int (*av_newstate)(struct ieee80211vap *, enum ieee80211_state, int); void (*av_bmiss)(struct ieee80211vap *); + void (*av_node_ps)(struct ieee80211_node *, int); }; #define ATH_VAP(vap) ((struct ath_vap *)(vap)) From owner-freebsd-wireless@FreeBSD.ORG Fri Oct 5 00:59:53 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F0641065675; Fri, 5 Oct 2012 00:59:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 612E38FC17; Fri, 5 Oct 2012 00:59:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q950xrte048516; Fri, 5 Oct 2012 00:59:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q950xqVM048512; Fri, 5 Oct 2012 00:59:52 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 00:59:52 GMT Message-Id: <201210050059.q950xqVM048512@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/172338: [ath] [net80211] CCMP IV transmit counters are not correctly protected by a lock X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 05 Oct 2012 00:59:53 -0000 Synopsis: [ath] [net80211] CCMP IV transmit counters are not correctly protected by a lock Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 00:59:41 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=172338 From owner-freebsd-wireless@FreeBSD.ORG Fri Oct 5 03:35:17 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84B29106566C; Fri, 5 Oct 2012 03:35:15 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D626A8FC12; Fri, 5 Oct 2012 03:35:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q953ZE0c069736; Fri, 5 Oct 2012 03:35:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q953ZEjp069731; Fri, 5 Oct 2012 03:35:14 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 03:35:14 GMT Message-Id: <201210050335.q953ZEjp069731@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171906: [ath] ath stop transmitting frames on AR5212 card X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 05 Oct 2012 03:35:17 -0000 Old Synopsis: ath stop transmitting frames on AR5212 card New Synopsis: [ath] ath stop transmitting frames on AR5212 card Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 03:35:00 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171906 From owner-freebsd-wireless@FreeBSD.ORG Fri Oct 5 03:44:38 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 763551065670; Fri, 5 Oct 2012 03:44:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 48A258FC1A; Fri, 5 Oct 2012 03:44:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q953ichI071734; Fri, 5 Oct 2012 03:44:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q953ibJ5071730; Fri, 5 Oct 2012 03:44:37 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 03:44:37 GMT Message-Id: <201210050344.q953ibJ5071730@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171816: [ath] [net80211] BAR TX overlapping with key renegotiation is causing issues? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 05 Oct 2012 03:44:38 -0000 Synopsis: [ath] [net80211] BAR TX overlapping with key renegotiation is causing issues? Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 03:44:26 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171816 From owner-freebsd-wireless@FreeBSD.ORG Fri Oct 5 12:38:57 2012 Return-Path: Delivered-To: wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAACE1065670 for ; Fri, 5 Oct 2012 12:38:57 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 4A94B8FC14 for ; Fri, 5 Oct 2012 12:38:56 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1TK7An-0004Cr-2q for wireless@freebsd.org; Fri, 05 Oct 2012 19:38:33 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q95CcpMu004518 for ; Fri, 5 Oct 2012 19:38:51 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q95CcWM1004390 for wireless@freebsd.org; Fri, 5 Oct 2012 19:38:32 +0700 (NOVT) (envelope-from danfe) Date: Fri, 5 Oct 2012 19:38:32 +0700 From: Alexey Dokuchaev To: wireless@freebsd.org Message-ID: <20121005123832.GA64777@regency.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Intel Pro/Wireless 2200BG iwi(4) card stopped working in 8-stable X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 05 Oct 2012 12:38:57 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, Since yesterday, Intel 2200BG wifi card in my laptop stopped working all of sudden. Reboots and usual dances with driver (iwi(4)) did not help. Attached is relevant parts of dmesg(8) with debug.iwi=5 (also downloadable from http://193.124.210.26/iwi.dmesg). Basically, once I try to configure it, I will see "iwi0: firmware error" on the console. I did not do anything with the kernel or the base. Any ideas on how to fix it? Since this card gave me lots of troubles over the past, any one can recommend a decent mini-pci replacement? It looks like ath(4) chips are currently best supported. I am thinking of something AR9223-based, which should provide me with better experience and give 802.11n support as a nice bonus. Opinions? Thanks, ./danfe --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iwi.dmesg" iwi_newstate: SCAN -> INIT flags 0x1 enter LOADING state exit LOADING state Setting MAC address to 00:16:6f:b2:61:51 sending command idx=0 type=11 len=6 Configuring adapter sending command idx=1 type=6 len=20 Setting .11bg supported rates (12) sending command idx=2 type=22 len=16 Setting .11a supported rates (8) sending command idx=3 type=22 len=16 Setting initialization vector to 4054530237 sending command idx=4 type=34 len=4 Enabling adapter sending command idx=5 type=2 len=0 iwi_newstate: INIT -> SCAN flags 0x1 enter SCANNING state Scan request: index 7 dwell 200/200/200 Scan 1 2.4GHz channels: 1/BCAST sending command idx=6 type=26 len=96 Notification (20) received frame len=139 chan=1 rssi=24 rssi_dbm=62 received frame len=226 chan=1 rssi=21 rssi_dbm=53 received frame len=226 chan=1 rssi=21 rssi_dbm=53 received frame len=349 chan=1 rssi=23 rssi_dbm=47 received frame len=145 chan=1 rssi=26 rssi_dbm=62 received frame len=129 chan=1 rssi=20 rssi_dbm=52 received frame len=349 chan=1 rssi=22 rssi_dbm=45 received frame len=145 chan=1 rssi=26 rssi_dbm=62 Scan of channel 2412 complete (1) Scan completed (1, 1) exit SCANNING state enter SCANNING state Scan request: index 8 dwell 200/200/200 Scan 1 2.4GHz channels: 6/BCAST sending command idx=7 type=26 len=96 iwi0: firmware error sending command idx=8 type=23 len=0 iwi0: firmware error enter LOADING state exit LOADING state Setting MAC address to 00:16:6f:b2:61:51 sending command idx=0 type=11 len=6 Configuring adapter sending command idx=1 type=6 len=20 Setting .11bg supported rates (12) sending command idx=2 type=22 len=16 Setting .11a supported rates (8) sending command idx=3 type=22 len=16 Setting initialization vector to 1453468842 sending command idx=4 type=34 len=4 Enabling adapter sending command idx=5 type=2 len=0 Notification (20) Notification (15) Notification (15) --nFreZHaLTZJo0R7j-- From owner-freebsd-wireless@FreeBSD.ORG Fri Oct 5 14:01:04 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81A961065677; Fri, 5 Oct 2012 14:01:04 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3518FC0C; Fri, 5 Oct 2012 14:01:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q95E14CB060181; Fri, 5 Oct 2012 14:01:04 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q95E14DH060177; Fri, 5 Oct 2012 14:01:04 GMT (envelope-from adrian) Date: Fri, 5 Oct 2012 14:01:04 GMT Message-Id: <201210051401.q95E14DH060177@freefall.freebsd.org> To: adrian@FreeBSD.org, adrian@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/171816: [ath] [net80211] BAR TX overlapping with key renegotiation is causing issues? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 05 Oct 2012 14:01:04 -0000 Synopsis: [ath] [net80211] BAR TX overlapping with key renegotiation is causing issues? State-Changed-From-To: open->closed State-Changed-By: adrian State-Changed-When: Fri Oct 5 13:59:11 UTC 2012 State-Changed-Why: This turned out to be an invalid bug - the actual cause of my disconnects were "EAPOL frames were non-QoS and dumped into TID 16; then they'd be put in the same hardware TXQ as best effort traffic; any non-QoS broadcast/multicast traffic (eg ARP) would end up in TID 16." Then "if any powersave occured, the EAPOL frames may be stuck in a software queue; the ARP frames would be stuffed into the CABQ and the ARP frames would go out first. But if they came in AFTER the EAPOL frame, the EAPOL frame would have a sequence number which is earlier and it'd be dropped.." http://www.freebsd.org/cgi/query-pr.cgi?pr=171816 From owner-freebsd-wireless@FreeBSD.ORG Fri Oct 5 14:01:34 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42EEC106566B; Fri, 5 Oct 2012 14:01:34 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 161AD8FC1C; Fri, 5 Oct 2012 14:01:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q95E1XVP060294; Fri, 5 Oct 2012 14:01:33 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q95E1XU9060290; Fri, 5 Oct 2012 14:01:33 GMT (envelope-from adrian) Date: Fri, 5 Oct 2012 14:01:33 GMT Message-Id: <201210051401.q95E1XU9060290@freefall.freebsd.org> To: bpurgar@gmail.com, adrian@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/171906: [ath] ath stop transmitting frames on AR5212 card X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 05 Oct 2012 14:01:34 -0000 Synopsis: [ath] ath stop transmitting frames on AR5212 card State-Changed-From-To: open->closed State-Changed-By: adrian State-Changed-When: Fri Oct 5 14:01:16 UTC 2012 State-Changed-Why: Fixed in -HEAD. This was due to incorrect CLRDMASK for non-aggregate traffic. http://www.freebsd.org/cgi/query-pr.cgi?pr=171906 From owner-freebsd-wireless@FreeBSD.ORG Sat Oct 6 06:44:11 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 72C341065670 for ; Sat, 6 Oct 2012 06:44:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4737D8FC18 for ; Sat, 6 Oct 2012 06:44:11 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so2947893pbb.13 for ; Fri, 05 Oct 2012 23:44:10 -0700 (PDT) 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=fRlP1+e8wPsy1ziTP3w/hw2zdU0zB3OfNY0fWDQnyD4=; b=d1Yw9R4tR9gY8rfrq78QtYH8ZRTi3gt1qxbxgfx35fKHmtUsS3rl1deSG/nIq3A6Qq gA8RxhFtFBldb5CgRtcxUZpaHdRUtizR+vbbjWm1L6ZvS2dh0TbBlJ5EcWW+aY0PyoT6 w4wvHlW7hWWAMIzCcAjtNrQhGMHBrrGthkZ04oaeIXrNDHT8k68G5hVP2oOtmoieC4A4 VzTPSFGU/uJqSBG3dEik/H9buMZuYnfn0KOP2lGMYH8mp/fBNOjaqVQWSzAlGUA5hAS7 TCVNTJcFJlOSit8r7kOjFSlIWhBCm/HLK4iaskFlzRyaRHhGoPguiJQIA1vqI2cbi3MV Ss2Q== MIME-Version: 1.0 Received: by 10.66.72.132 with SMTP id d4mr27253005pav.61.1349505850576; Fri, 05 Oct 2012 23:44:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Fri, 5 Oct 2012 23:44:10 -0700 (PDT) Date: Fri, 5 Oct 2012 23:44:10 -0700 X-Google-Sender-Auth: f6zctYyF1tD2Gz5eDGsh5mA-Fms Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [RFC] How the TX path works; I'd like to fix this before 10.x X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 06 Oct 2012 06:44:11 -0000 Hi all, It seems the net80211 TX path is a bit .. racey. Specifically: * There's three entry points - the vap netif start at ieee80211_start(), and ic_raw_xmit() method, and ieee80211_output() for raw frames * the vap netif path will do 802.11 encapsulation, including seqno allocation * raw_xmit (iirc) doesn't do seqno allocation, but it's for management frames * ieee80211_output() does the 802.11 encap, seqno allocation and encryption if needed. * Then, the driver does the encryption, including CCMP IV. Now, there's problems: * there's multiple, overlapping entry points into ieee80211_start(), as the if_start() method doesn't _at all_ guarantee only one if_start() method is running at once. Sigh. * ic_raw_xmit() can be called at any time, and bypasses the vap ifp entirely. * ieee80211_output() can either use or bypass the vap ifp queue, depending upon whether it's a raw 802.11 or 802.3 frame. Then, to make matters worse, the whole TX path shift in the 7.x days broke fragment TX handling, as the method of using m_nextpt doesn't work at all with the ifnet macros. That's definitely a problem as it means we can't get any wifi certification _at all_. Before I continue - if_transmit() is not the answer. if_transmit() guarantess _no_ serialisation at all. So we'd stlil have to stuff things into queues. And ensure only one thing is running at once. So the question is - how do we fix this? We could do the dfbsd approach and just giant-lock the whole wifi subsystem and drivers. I don't want to do that. The ic_raw_xmit() interface needs to go away. Wireless frames should just be pushed onto the output queue like any other frames and the queue discipline should ensure management frames don't get dropped. But as long as they're not encrypted (for now, there _is_ management frame encryption as an optional part of 802.11) and don't require sequence/CCMP IVs, we're ok. Still; I think we should attach an optional "tx params" to the mbuf and send that along. Then we teach the driver to check for that particular mbuf parameter set and use it, just like how ic_raw_xmit() works right at the moment. The ic_raw_xmit() stuff is dangerous and scary, mostly because it right now does bypass a full ifnet queue and lets us send those management frames doirectly. I could wrap a big VAP TX lock around ieee80211_output() and ieee80211_start(), ensuring they don't run over each other. But long-held locks need to go away and die. yes, even the ones in the ath(4) driver that I've introduced. They're there because of a lack of synchronisation and queue design. A lot of the gige/10ge drivers use long-held locks.. sigh. I could create a net80211 TX tasklet for each vap (or ic, _maybe_) which serialises the TX path. ieee80211_start() would just schedule the tasklet to run. That would serialise all of the parallel TX entry points and solve a bunch of the subtle sequence number and other TX state races that are occuring. That doesn't solve the ic_raw_xmit() or ieee80211_output() problem, as both of those can also do TX 802.11 encapsulation and kick off parts of the state machine. It doesn't solve the same issues with the drivers .Yes, even if we converted them to use if_transmit(). iwn(4) solves this by just having a big IWN_LOCK() but it releases it when doing anything stack related. I'm not sure if it holds it across the whole TX path through iwn_start(). In any case, it's a big lock. ath(4) can and does have multiple ath_start() instances running in multiple kernel threads, fighting to dequeue frames from the ifnet. This still can cause issues with non-aggregate sequence number and CCMP IV counter allocation. Sigh. God even knows what to do about USB devices in all of this. So, now that I've ranted about the problem and some poking about solutions, I'm opening the floor for comment. I'd like to have this worked on parallel (whilst I'm doing things to the net80211 stack to support better 802.11n legacy power save and fix ps/ps-poll support) and get it implemented/debugged before 10.0. ... your turn. :) Adrian From owner-freebsd-wireless@FreeBSD.ORG Sat Oct 6 19:00:28 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 8F7CD1065690 for ; Sat, 6 Oct 2012 19:00:28 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm18.bullet.mail.gq1.yahoo.com (nm18.bullet.mail.gq1.yahoo.com [98.136.217.1]) by mx1.freebsd.org (Postfix) with SMTP id 46D4F8FC24 for ; Sat, 6 Oct 2012 19:00:28 +0000 (UTC) Received: from [98.137.12.61] by nm18.bullet.mail.gq1.yahoo.com with NNFMP; 06 Oct 2012 19:00:22 -0000 Received: from [208.71.42.213] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 06 Oct 2012 19:00:22 -0000 Received: from [127.0.0.1] by smtp224.mail.gq1.yahoo.com with NNFMP; 06 Oct 2012 19:00:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1349550022; bh=XlFk0FSr66rzoA1sieFuWJD0InrXhAGHHVa9pciSJEw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Content-Type; b=4S8+9rV8s2i7Qdgn4H1IK1Agaz5YDY6+hoozGjRjfoZye4ZzxgRNqSVu1RBPpJNeGyV4Nruzt+RDpxDbOiVsgWm5y5DOpVch2jb2ocRfQNdbRE4+0xL/FK3/yZmRq8bPuZl0LuxgP2SsqZFI/dLg33bAi686a6EusqfxA4uXtss= X-Yahoo-Newman-Id: 485837.9237.bm@smtp224.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aNGPN4AVM1lYcdzepptxosF9Oqi.DRbcV_Fejy5al2Bcyap pxPEMr_e7h2ZK.QNjN__f.6Qp82dcr31DbXFeYTj1yvmclvlZ8oyozS_IgYA XSQaDtetbmUv7xXgZnxx7r7GKHTqhvvQqI9KNPTAA9G9wNggQIb1rIq7hqCR Cu5LVFmxRGBNpg6xrCAIm4gq81qDBKZ0.0g18o3ErhJ9wWu1iaVBEMeuhBIT B856WjKFw6iaVBw9iHuaUfT9GnQMm4UESbeymQOxK8xyG6pthUENZhOdNXr8 KnZtHODjm3tN9pDoeYcTW5WNdAzFOOmouX.OpeRhXZYhOCWekoMdInYHama7 3Lsgj43kEzRGQqO.lscx9_O.yoDeAW05tWU9RT9eYSahM.MsQF.HFkVhuJzn VmqC42u0yMEngJ5IFPh8XHz9QoH8IZziTNB3_3Rb3e0Wc6MLInKFER8Vog6C dFUY9HbFQ5cD5PhiMHVBgUOMyzHcqwbyxGnFmB.bzqOPUxJeqiELKMeVUzZM fuX20YYD7znKpbIJ4PLxidqrcBQTwjcBwWDw.e9B7jGVwxZbUjnALUdNDNk6 O0SZeuA2cjrNZ X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vb0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp224.mail.gq1.yahoo.com with SMTP; 06 Oct 2012 12:00:22 -0700 PDT Received: by mail-vb0-f54.google.com with SMTP id v11so3815479vbm.13 for ; Sat, 06 Oct 2012 12:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.100 with SMTP id l4mr7392201vef.46.1349550021326; Sat, 06 Oct 2012 12:00:21 -0700 (PDT) Received: by 10.58.182.72 with HTTP; Sat, 6 Oct 2012 12:00:21 -0700 (PDT) Date: Sat, 6 Oct 2012 13:00:21 -0600 Message-ID: From: PseudoCylon To: Adrian Chadd , freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: [RFC] How the TX path works; I'd like to fix this before 10.x X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 06 Oct 2012 19:00:28 -0000 > ------------------------------ > > Message: 4 > Date: Fri, 5 Oct 2012 23:44:10 -0700 > From: Adrian Chadd > Subject: [RFC] How the TX path works; I'd like to fix this before 10.x > To: freebsd-wireless@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Before I continue - if_transmit() is not the answer. if_transmit() > guarantess _no_ serialisation at all. So we'd stlil have to stuff > things into queues. And ensure only one thing is running at once. As far as I know, if_transmit/if_start are options for drivers, not for the serialisation. if_transmit to use device specific queue if_start to use if_snd queue i.e. http://fxr.watson.org/fxr/source/dev/e1000/if_em.c#L2941 > > I could wrap a big VAP TX lock around ieee80211_output() and > ieee80211_start(), ensuring they don't run over each other. But > long-held locks need to go away and die. yes, even the ones in the > ath(4) driver that I've introduced. They're there because of a lack of > synchronisation and queue design. A lot of the gige/10ge drivers use > long-held locks.. sigh. > > I could create a net80211 TX tasklet for each vap (or ic, _maybe_) > which serialises the TX path. ieee80211_start() would just schedule > the tasklet to run. That would serialise all of the parallel TX entry > points and solve a bunch of the subtle sequence number and other TX > state races that are occuring. That doesn't solve the ic_raw_xmit() or > ieee80211_output() problem, as both of those can also do TX 802.11 > encapsulation and kick off parts of the state machine. I prefer taskqueue over new lock. I have had enough of LORs already. We just need to decide where/how to funnel all tx entries. Currently, pseudo devices (i.e. if_bridge) \ IP stack --> ieee80211 stack --> driver ic_raw_xmit / so we need to ensure serialization (by lock or taskqueue) at 2 points, 1) between upper layer and ieee80211, 2) driver and ieee80211. If we solve the raw_xmit problem, there will be only 1 point to take care. An idea Guarantee only one thread is running at any moment. So, first queued first dequeued and tx'd without a lock. if_start() { if (sc_task == NOT_RUNNING) wakeup(sc_txtask); } if_txtask() { for (;sc_txtask_exit != DONE;) { IFQ_DRV_DEQUEUE(); if (m == NULL) { sc_txtask = NOT_RUNNING; tsleep(); sc_txtask = RUNNING; } else tx(); } } tx_callback() { ... if (sc_task == NOT_RUNNING) wakeup(sc_txtask); } iv_vap_create() { ... taskqueue_enqueue(sc_taskqueue); } iv_vap_delete() { ... sc_txtask_exit = DONE; if (sc_task == NOT_RUNNING) wakeup(sc_txtask); } > > It doesn't solve the same issues with the drivers .Yes, even if we > converted them to use if_transmit(). iwn(4) solves this by just having > a big IWN_LOCK() but it releases it when doing anything stack related. > I'm not sure if it holds it across the whole TX path through > iwn_start(). In any case, it's a big lock. ath(4) can and does have > multiple ath_start() instances running in multiple kernel threads, > fighting to dequeue frames from the ifnet. This still can cause issues > with non-aggregate sequence number and CCMP IV counter allocation. > Sigh. > > God even knows what to do about USB devices in all of this. > Similar to other drivers, i.e. iwn(4). The difference is USB drivers create per-USB-pipe queue in addition to if_snd queue. So that, tx path look like if_transmit -> queue -> if_start -> dequeue -> driver_tx -> usb_queue -> usb_stack It seems redundant. I'd like to change that to (for run(4)) if_transmit -> driver_tx -> usb_queue -> usb_stack AK From owner-freebsd-wireless@FreeBSD.ORG Sat Oct 6 21:00:23 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 79F42106564A for ; Sat, 6 Oct 2012 21:00:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 262A18FC08 for ; Sat, 6 Oct 2012 21:00:22 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so3311651pbb.13 for ; Sat, 06 Oct 2012 14:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VSIS4nRRsmu6lZJWA1DgIa8CMejOONa7g3gGbjKKA0o=; b=vsLKTa78qDi9f4/gvD9T9hAAtmt5y7OJHajnAK8Z/zu1ZZ1nWcS5zcqpL/yUtO6AZF r/awFlO+NncWBnVg7a08jqpxoRN+pkIYIgGsryghnIONPgQZQMUL6uckZC6UmZg2aO8/ JkYQdNNYqN3SoVnF1o0NRST62c6F3cEJzKqQQ5JOCaxv5MZ9TZHIx3GJnOtGdLoG7eh0 wcTmeGbSxwILDzASrqyfSFGK+I2R6Q1K5qORVSDBnkNbZNXeY6bnTacLCcvTY5dY4R1l Etir+POlFJlc1dSGSH/YYPG4bH6bfzQ1tC7yXzOJOxs6och02SAp9I3slPHHk7rYOwKv 5u4w== MIME-Version: 1.0 Received: by 10.68.222.37 with SMTP id qj5mr40716878pbc.132.1349557215619; Sat, 06 Oct 2012 14:00:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Sat, 6 Oct 2012 14:00:15 -0700 (PDT) Received: by 10.68.223.136 with HTTP; Sat, 6 Oct 2012 14:00:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Oct 2012 14:00:15 -0700 X-Google-Sender-Auth: X2mPUibbvOoPmoDrwneSp_IVKes Message-ID: From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-wireless@freebsd.org Subject: Re: [RFC] How the TX path works; I'd like to fix this before 10.x X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 06 Oct 2012 21:00:23 -0000 Well, i would like to implement if_transmit for net80211 tx, then have the tx routine queue the frame and wakeup the tx taskqueue or tasklet. Im not sure yet whether to put the tx processing in the existing ic taskqueue or not, but since the current tx path runs separate to the ic taskqueue, the hard work is already done for us. In parallel I would like to kill the ieee80211_output and raw xmit code, instead doing the encap and such in the tx tasklet. We could later allow encap before serialisation but delay seqno and encryption. Thats a later thing. In parallel we do need to fix driver tx. It all has to stay in order... Ie the order that the tx tasklet does encap must reflect the driver setup. Or, we push seqno allocation to each driver. Ew. Adrian On Oct 6, 2012 3:01 PM, "PseudoCylon" wrote: > > ------------------------------ > > > > Message: 4 > > Date: Fri, 5 Oct 2012 23:44:10 -0700 > > From: Adrian Chadd > > Subject: [RFC] How the TX path works; I'd like to fix this before 10.x > > To: freebsd-wireless@freebsd.org > > Message-ID: > > 5V4rrWw@mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Before I continue - if_transmit() is not the answer. if_transmit() > > guarantess _no_ serialisation at all. So we'd stlil have to stuff > > things into queues. And ensure only one thing is running at once. > > As far as I know, if_transmit/if_start are options for drivers, not > for the serialisation. > if_transmit to use device specific queue > if_start to use if_snd queue > i.e. > http://fxr.watson.org/fxr/source/dev/e1000/if_em.c#L2941 > > > > > I could wrap a big VAP TX lock around ieee80211_output() and > > ieee80211_start(), ensuring they don't run over each other. But > > long-held locks need to go away and die. yes, even the ones in the > > ath(4) driver that I've introduced. They're there because of a lack of > > synchronisation and queue design. A lot of the gige/10ge drivers use > > long-held locks.. sigh. > > > > I could create a net80211 TX tasklet for each vap (or ic, _maybe_) > > which serialises the TX path. ieee80211_start() would just schedule > > the tasklet to run. That would serialise all of the parallel TX entry > > points and solve a bunch of the subtle sequence number and other TX > > state races that are occuring. That doesn't solve the ic_raw_xmit() or > > ieee80211_output() problem, as both of those can also do TX 802.11 > > encapsulation and kick off parts of the state machine. > > I prefer taskqueue over new lock. I have had enough of LORs already. > > We just need to decide where/how to funnel all tx entries. > Currently, > pseudo devices (i.e. if_bridge) \ > IP stack --> ieee80211 stack --> > driver > ic_raw_xmit > / > so we need to ensure serialization (by lock or taskqueue) at 2 points, > 1) between upper layer and ieee80211, > 2) driver and ieee80211. > If we solve the raw_xmit problem, there will be only 1 point to take care. > > > An idea > Guarantee only one thread is running at any moment. So, first queued > first dequeued and tx'd without a lock. > > if_start() { > if (sc_task == NOT_RUNNING) > wakeup(sc_txtask); > } > > if_txtask() { > for (;sc_txtask_exit != DONE;) { > IFQ_DRV_DEQUEUE(); > if (m == NULL) { > sc_txtask = NOT_RUNNING; > tsleep(); > sc_txtask = RUNNING; > } else > tx(); > } > } > > tx_callback() { > ... > if (sc_task == NOT_RUNNING) > wakeup(sc_txtask); > } > > iv_vap_create() { > ... > taskqueue_enqueue(sc_taskqueue); > } > > iv_vap_delete() { > ... > sc_txtask_exit = DONE; > if (sc_task == NOT_RUNNING) > wakeup(sc_txtask); > } > > > > > It doesn't solve the same issues with the drivers .Yes, even if we > > converted them to use if_transmit(). iwn(4) solves this by just having > > a big IWN_LOCK() but it releases it when doing anything stack related. > > I'm not sure if it holds it across the whole TX path through > > iwn_start(). In any case, it's a big lock. ath(4) can and does have > > multiple ath_start() instances running in multiple kernel threads, > > fighting to dequeue frames from the ifnet. This still can cause issues > > with non-aggregate sequence number and CCMP IV counter allocation. > > Sigh. > > > > God even knows what to do about USB devices in all of this. > > > > Similar to other drivers, i.e. iwn(4). The difference is USB drivers > create per-USB-pipe queue in addition to if_snd queue. So that, tx > path look like > if_transmit -> queue -> if_start -> dequeue -> driver_tx -> usb_queue > -> usb_stack > It seems redundant. I'd like to change that to (for run(4)) > if_transmit -> driver_tx -> usb_queue -> usb_stack > > > AK > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org > " >