From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 24 06:36:41 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 449B0920 for ; Sun, 24 Feb 2013 06:36:41 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by mx1.freebsd.org (Postfix) with SMTP id D693C16EA for ; Sun, 24 Feb 2013 06:36:40 +0000 (UTC) Received: from [98.139.215.142] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 24 Feb 2013 06:30:07 -0000 Received: from [98.139.211.205] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 24 Feb 2013 06:30:07 -0000 Received: from [127.0.0.1] by smtp214.mail.bf1.yahoo.com with NNFMP; 24 Feb 2013 06:30:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1361687407; bh=m6tpVWdjJ+DEdKTB9H0k/LPJ5DtE8K0oVbxSV1AF3zY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:X-Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=QKXg9Xquh50lWHr5y/Yn0EDH6Dh+lzG5/cgJEQ6yBEZ+eNV8dYgYlCouJjktqn+D1amTBxlSnAxVgamHSHq9RZtVSqIrQtw7f40sYw8RphQYMIY/2j/WXxON4oY01xcgmudy87EWyo8kLHH+dKF/FOZ8DVjhUE2KF+/qq1CVWUM= X-Yahoo-Newman-Id: 37121.80220.bm@smtp214.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cSlnQPYVM1mhhWwDYZFPCny5Ha_macXfnmVCA_E3d4EBOde p52gLuBgk5QQHmJ9p5ETaGy2tap6ieJ5CgnPAdRUXvkjAxVc8At7074dI_Wy L6HsmIn_OHcscQ0RkEFUDHFkRoKifxLU5RSKTFT.ES0nfuUptSCX9AqUN3Z0 YKRM5Pdf7QbsQCZxNPJqY5X2m1diKUwlqeRgwqQn0xebAK8THPrmbGlWJGBt PGUisNoVZ5YTNK.8bKPJl1nTE0xlrtFhd9oAFikUF2hZBx51S6h3BEU_knm_ 6eE8eSqOKM64EyumDMoRjqfvwORe6DMJLb.OAuQkk3FxpIW.N6e7AwWGnr6g cHd1.PMrTkRGJE1x3d0YDn8q2xjDDBNKCTn4wy2kp_BCdG5TsfZE5IVC8iTj w5S5jIZDszRMpcNY3f0zqdosvJOV1tCbqCWdgBdZyMn8DGvVi.Dk0lqIQJ7Z BP_Cw9DzrOofI29VtSCw- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-da0-f42.google.com (moonlightakkiy@209.85.210.42 with plain) by smtp214.mail.bf1.yahoo.com with SMTP; 23 Feb 2013 22:30:06 -0800 PST Received: by mail-da0-f42.google.com with SMTP id z17so997318dal.29 for ; Sat, 23 Feb 2013 22:30:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.9.2 with SMTP id v2mr12725834paa.18.1361687405930; Sat, 23 Feb 2013 22:30:05 -0800 (PST) Received: by 10.68.52.170 with HTTP; Sat, 23 Feb 2013 22:30:05 -0800 (PST) Date: Sat, 23 Feb 2013 23:30:05 -0700 Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: PseudoCylon To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Sun, 24 Feb 2013 06:36:41 -0000 > ------------------------------ > > Message: 12 > Date: Fri, 22 Feb 2013 17:18:44 -0800 > From: Adrian Chadd > To: freebsd-wireless@freebsd.org > Subject: Re: [RFT] net80211 TX serialisation, take #4 > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 22 February 2013 15:25, Adrian Chadd wrote: > > So, this is all pretty terrible. The only sane solution for now is to > make my VAP TX lock an IC TX lock,and grab said IC TX lock for all > VAPs. That way the driver can grab the IC TX lock when it's doing > deferred sends and it'll be sure the lock is held when it decides to > grab/increment sequence numbers from ni->ni_txseqs[]. I don't think lock(); ni->ni_txseqs[]++; unlock(); can fix the problem because no one can guarantee which process/thread grabs the lock next. i.e. concurrently, without lock, - Thread A is processing packet seq#1 - Thread B is processing packet seq#2 When the time to do ni_txseqs[]++, how can we guarantee thread A grabs the lock before thread B? In other word, if thread A always grabs the lock first, we don't need to serialize the Tx, do we? > * .. and do this without tearing my hair out. The sequence will be messed up during moving packets from one queue to another, i.e from driver queue to hardware queue. As long as packets are in a queue (in a linked list) sequence won't change unless we explicitly write such code. So... Saving your hair option 1 tx() { for() { lock(); dequeue(m); /* assuming queue is in order */ ni_txseqs[]++ enqueue_working_queue(m); unlock(); ... process m ... lock(); /* * m may change here. * Whichever the thread does dequeues, m0 will be * the head of the queue, so sequence will be kept intact. * But, need to test if processing of m0 has been completed. */ dequeue_working_queue(m0); enqueue_driver_queue(m0); /* or hardware_queue() */ unlock(); } } This will keep sequence intact. Saving your hair option 2 Shave your head until you fix the problem. Hair will grow again, you know. No bad hair day is a bonus. AK From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 24 07:45:58 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82B36E47 for ; Sun, 24 Feb 2013 07:45:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mx1.freebsd.org (Postfix) with ESMTP id 2116E1822 for ; Sun, 24 Feb 2013 07:45:57 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id 16so1551989wgi.15 for ; Sat, 23 Feb 2013 23:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XXO2cPP8wjKMqQEK6wTyBPQ8SxYEWzErg39B24VVlOk=; b=kEWYkk+20hKA3f4KksDx173Njh4vtLvHYnHdWJyLszaeDdQnHGxQYBKPOsYCgwW9qJ YE3wassyQlpNkwuzPPq23bAGh5Jg82b2+OqoYjuv37ndBgYZHAc7IZ0sT2m2qxRI+6yR mBCrBX+Ew/06TL63beWdMxeY7OQfsOh4/9dhB5jw7rxV0rF6S/KKjg7bW8mHH0pGygC5 HLd1Qp6ZfoH3HSN39CFV64CeHaZra67jQnHQkDDj9tRiSQrteyOk5zmqSzQGppTUT3zj WI/Z0vMvywTLzOStOsgdK+I5tm+jV9453reH9/92rYHcEv30bwCOoqzKYOAPV10EO1kf d3XQ== MIME-Version: 1.0 X-Received: by 10.181.11.198 with SMTP id ek6mr6256052wid.1.1361691956800; Sat, 23 Feb 2013 23:45:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Sat, 23 Feb 2013 23:45:56 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Feb 2013 23:45:56 -0800 X-Google-Sender-Auth: 8J9hDTSCI8oiVzgI5zsiivQ4LZA Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Sun, 24 Feb 2013 07:45:58 -0000 On 23 February 2013 22:30, PseudoCylon wrote: >> So, this is all pretty terrible. The only sane solution for now is to >> make my VAP TX lock an IC TX lock,and grab said IC TX lock for all >> VAPs. That way the driver can grab the IC TX lock when it's doing >> deferred sends and it'll be sure the lock is held when it decides to >> grab/increment sequence numbers from ni->ni_txseqs[]. > > I don't think > lock(); > ni->ni_txseqs[]++; > unlock(); > can fix the problem because no one can guarantee which process/thread > grabs the lock next. Yup, that's definitely a problem. The problem here is that packets coming into net80211 - either via vap->input() (bpf injection) or vap->transmit() (802.3) , have to do this: * processed in order; * the same order as they're then pushed into the power save / age queue; * the same order that these frames get assigned sequence numbers and enforce state (eg considering things for ampdu, power save, etc); * the same order that they're queued to the driver; * the same order that they're dequeued from the driver; * the same order that they're processed (eg crypto encaps); * the same order that it's then passed down into the driver - either via direct dispatch or deferred queue. >> * .. and do this without tearing my hair out. > > The sequence will be messed up during moving packets from one queue to > another, i.e from driver queue to hardware queue. As long as packets > are in a queue (in a linked list) sequence won't change unless we > explicitly write such code. So... > > Saving your hair option 1 > tx() > { > for() { > lock(); > dequeue(m); /* assuming queue is in order */ > ni_txseqs[]++ > enqueue_working_queue(m); > unlock(); > ... > process m > ... > lock(); > /* > * m may change here. > * Whichever the thread does dequeues, m0 will be > * the head of the queue, so sequence will be kept intact. > * But, need to test if processing of m0 has been completed. > */ > dequeue_working_queue(m0); > enqueue_driver_queue(m0); /* or hardware_queue() */ > unlock(); > } > } > This will keep sequence intact. Right. This is similar to my idea (or two.) There's a few other issues though! ic_raw_xmit() is called by a bunch of places to generate both raw frames and management frames. This bypasses the vap queue and calls the driver direct. As an example, injected EAPOL frames have CCMP IV numbers (as they're encrypted!) but not necessarily sequence numbers. Because the CCMP IV gets calculated int he driver at some point after it's been queued, ANY slight race here causes some other frame to get queued with a CCMP IV -after- the EAPOL frame, and it will get dropped. Then you get your session dropped. :-) ic_raw_xmit() is also an ic method, not a vap method. Yes, it bypasses the vap queue. There's deferred transmission going on (eg ath_start() getting called from TX completion, as an example.) Should that be called under the above lock() in your example? And the TX sequence number stuff in iwn and ath, because the aggregation code reuses the ni_txseqs[] array. So yes, the locking wouldn't clash with the rest of net80211 (as only either the non-agg TX path in net80211 or the TX path in ath/iwn would be using that variable) but it's still a pain in the ass. Grr. The ridiculously complicated, broken-down-into-bits version: * add a new mbuf tag to mbufs (optional) which lets us tag an mbuf with a bpf TX params struct (ie, what gets optionally passed into the raw xmit call); * calls to ic_raw_xmit() become a VAP raw xmit; * the VAP raw xmit pushes mbufs into the same ifnet queue that the VAP frames have (ie right now the VAP ifnet queue) - ie, serialise the raw and non-raw VAP frames before it gets processed for 802.11 state; * .. then move the VAP transmit to your model - which is + vap transmit and raw transmit just push frames into the vap ifnet queue; + vap transmit then schedules a deferred task or a direct dispatch + deferred task if we cant grab the VAP TX lock; + the vap transmit task/dispatch routine handles the frames one at a time - either inside a task queue or inside the VAP TX lock - thus all of the 802.3 -> 802.11 encapsulation and state handling is correctly serialised _and_ the order of sequence numbers and frame handling is maintained; + then those frames have to be queued to the driver in _exactly_ the same order - so either the VAP TX task/process queues them into a driver staging queue and kicks the driver side ,or it goes into a separate task to do driver dispatch; + .. and then it's up to the driver to dequeue each frame, handle it and push them into the hardware in the same order. Now, that's totally, ridiculously complicated but it does avoid a bunch of reentrant and long-held-lock problems. The ridiculously uncomplicated version: * put a big IC TX lock around ieee80211_start(), ieee80211_output() and any routine that is calling ieee80211_encap() -> if_transmit() or ieee80211_encap() -> ic_raw_xmit(); * do the same with the ageq and powersave queue that dispatches to the driver - grab that big IC TX lock, dequeue all the frames to the driver, release the IC lock; * the driver TX code must grab the net80211 IC TX lock before it does a deferred transmit - so the driver TX (not TX completion - TX!) always has a consistent set of locking; * do a bunch of net80211 TX path refactoring to unify the TX path a bit; * just give in to the long-held locks and worry about tidying this crap up later; * hope to dear god there aren't any lock-order issues between the comlock and this new lock; same as the other crap that's going on; Opinions? :) Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 24 23:15:44 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C49E15B8; Sun, 24 Feb 2013 23:15:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9BFCCD06; Sun, 24 Feb 2013 23:15:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1ONFiLQ011112; Sun, 24 Feb 2013 23:15:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1ONFhah011108; Sun, 24 Feb 2013 23:15:43 GMT (envelope-from linimon) Date: Sun, 24 Feb 2013 23:15:43 GMT Message-Id: <201302242315.r1ONFhah011108@freefall.freebsd.org> To: brett.wright@cooperindustries.com, linimon@FreeBSD.org, freebsd-wireless@FreeBSD.org, adrian@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/170904: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled 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: Sun, 24 Feb 2013 23:15:44 -0000 Synopsis: [ath] ath driver: configure related parameters when radar detection (DFS) is enabled State-Changed-From-To: open->patched State-Changed-By: linimon State-Changed-When: Sun Feb 24 23:15:02 UTC 2013 State-Changed-Why: Over to committer for possible MFC. Responsible-Changed-From-To: freebsd-wireless->adrian Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 24 23:15:02 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=170904 From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 25 07:25:54 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0403951B for ; Mon, 25 Feb 2013 07:25:54 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm25-vm3.bullet.mail.ne1.yahoo.com (nm25-vm3.bullet.mail.ne1.yahoo.com [98.138.91.155]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8271E7 for ; Mon, 25 Feb 2013 07:25:53 +0000 (UTC) Received: from [98.138.226.180] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 07:25:47 -0000 Received: from [98.138.226.124] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 07:25:47 -0000 Received: from [127.0.0.1] by smtp203.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 07:25:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1361777147; bh=Qs+PZZeyLAGbT8gAuDkAnWrxoKTET8FEmU5LUQI4yHg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:X-Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=i8AXNP+Iz5ootsWusRkWlRXEYrwXY1zhU3Icq0AxZmRNgMWnu827w8ticJWn5/qgUIVMt7dd7m5KvnN+jhWTzqvZWiCcx3v5qIu0oFKnnE5buHlWwXhSGUSZ7V9POC7bQ8wrQvc0HxAgZsOEIgdzS0anKnZMIJ0DuK/HF0YZTm0= X-Yahoo-Newman-Id: 576324.56143.bm@smtp203.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nq1zjAAVM1npbFMyektanrdeiiEw7n6PTLDmlSKO0DBo4FG 91VWddkENq10EtVWJb67TzTuXLKF4dXI5e8uwsoAtojOmV1KCMq6i6nAx1of qkHCF97NYk6JsjZ1pr1ceXJawGol1jHZzxgt6AAwhydc3r7LLLy4VF8WMq0c 6i44lDp_jeRVkSW3QT3tsrIBmvTAL8aZVlX4Nzg6R1WS119Tur96gOP0vC0v AQdzce7FIveN6ENqWalEnFf3eh.ACO.1BHmXUmOWJNRA1UZ.SBRzYTw1iWC6 BdCoaBHTcAriDeydf8C4LEPe.pxnWtR_z5hqXUcfUHTdwTrAqwgGe_9Yb6pj cTx1iZrllScJe3BKQc5HxNOlOXFMV_lEyURyzyvPz_WPkXdzDOnxTj.zx9Lf 6UJheR0Zi0f0b1IJdWdB0NQ0z6p2eek51hayRB2XkqbXwDwlGsXKr.LGvKjN qNzkumk4biHBm59UJKgwv X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-pb0-f43.google.com (moonlightakkiy@209.85.160.43 with plain) by smtp203.mail.ne1.yahoo.com with SMTP; 24 Feb 2013 23:25:47 -0800 PST Received: by mail-pb0-f43.google.com with SMTP id md12so1519043pbc.2 for ; Sun, 24 Feb 2013 23:25:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.139.227 with SMTP id rb3mr17355245pab.107.1361777146635; Sun, 24 Feb 2013 23:25:46 -0800 (PST) Received: by 10.68.52.170 with HTTP; Sun, 24 Feb 2013 23:25:46 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 00:25:46 -0700 Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: PseudoCylon To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Mon, 25 Feb 2013 07:25:54 -0000 On Sun, Feb 24, 2013 at 12:45 AM, Adrian Chadd wrote: > On 23 February 2013 22:30, PseudoCylon wrote: >>> So, this is all pretty terrible. The only sane solution for now is to >>> make my VAP TX lock an IC TX lock,and grab said IC TX lock for all >>> VAPs. That way the driver can grab the IC TX lock when it's doing >>> deferred sends and it'll be sure the lock is held when it decides to >>> grab/increment sequence numbers from ni->ni_txseqs[]. >> >> I don't think >> lock(); >> ni->ni_txseqs[]++; >> unlock(); >> can fix the problem because no one can guarantee which process/thread >> grabs the lock next. > > Yup, that's definitely a problem. > > The problem here is that packets coming into net80211 - either via > vap->input() (bpf injection) or vap->transmit() (802.3) , have to do > this: There isn't any sequence relations between bpf injection and packets from vap->transmit(). First come first enqueue should work. 80211 stack generated packets --\ bpf_injection -> ieee80211_output()--\ vap_transmit() -> vap_queue -> 80211stack --> driver_queue > > * processed in order; > * the same order as they're then pushed into the power save / age queue; > * the same order that these frames get assigned sequence numbers and > enforce state (eg considering things for ampdu, power save, etc); > * the same order that they're queued to the driver; > * the same order that they're dequeued from the driver; > * the same order that they're processed (eg crypto encaps); > * the same order that it's then passed down into the driver - either > via direct dispatch or deferred queue. > > >>> * .. and do this without tearing my hair out. >> >> The sequence will be messed up during moving packets from one queue to >> another, i.e from driver queue to hardware queue. As long as packets >> are in a queue (in a linked list) sequence won't change unless we >> explicitly write such code. So... >> >> Saving your hair option 1 >> tx() >> { >> for() { >> lock(); >> dequeue(m); /* assuming queue is in order */ >> ni_txseqs[]++ >> enqueue_working_queue(m); >> unlock(); >> ... >> process m >> ... >> lock(); >> /* >> * m may change here. >> * Whichever the thread does dequeues, m0 will be >> * the head of the queue, so sequence will be kept intact. >> * But, need to test if processing of m0 has been completed. >> */ >> dequeue_working_queue(m0); >> enqueue_driver_queue(m0); /* or hardware_queue() */ >> unlock(); >> } >> } >> This will keep sequence intact. > > Right. This is similar to my idea (or two.) > > There's a few other issues though! > > ic_raw_xmit() is called by a bunch of places to generate both raw > frames and management frames. This bypasses the vap queue and calls > the driver direct. As an example, injected EAPOL frames have CCMP IV > numbers (as they're encrypted!) but not necessarily sequence numbers. > Because the CCMP IV gets calculated int he driver at some point after > it's been queued, ANY slight race here causes some other frame to get > queued with a CCMP IV -after- the EAPOL frame, and it will get > dropped. Then you get your session dropped. :-) That's a tricky one. (I didn't think about encryption.) Queue only maintains the order of packets. It doesn't mean packets are processed in order. If packets need to be processed in order, should be done while the lock is held. I think this should do the trick. lock(); dequeue_working_queue(); /* or driver_queue */ if (IEEE80211_FC1_WEP) ieee80211_crypto_encap(); pass_to_hardware(); unlock(); > > ic_raw_xmit() is also an ic method, not a vap method. Yes, it bypasses > the vap queue. the same as bpf injection part > > There's deferred transmission going on (eg ath_start() getting called > from TX completion, as an example.) Should that be called under the > above lock() in your example? Yes. With encryption stuff, if_start or if_transmission will look like this. if_start/_transmit() { for () { lock(); dequeue_driver_queue(); enqueue_working_queue(); unlock(); ... process ... lock(); dequeue_working_queue(); if (IEEE80211_FC1_WEP) ieee80211_crypto_encap(); pass_to_hardware(); unlock(); } } > > And the TX sequence number stuff in iwn and ath, because the > aggregation code reuses the ni_txseqs[] array. So yes, the locking > wouldn't clash with the rest of net80211 (as only either the non-agg > TX path in net80211 or the TX path in ath/iwn would be using that > variable) but it's still a pain in the ass. If we do a good job on serialization -- matching actual order of packets sent out and tx_seqs in 80211 stack -- driver shouldn't need to touch ni_txseqs. It is still a big if. > > Grr. > > The ridiculously complicated, broken-down-into-bits version: > > * add a new mbuf tag to mbufs (optional) which lets us tag an mbuf > with a bpf TX params struct (ie, what gets optionally passed into the > raw xmit call); > * calls to ic_raw_xmit() become a VAP raw xmit; > * the VAP raw xmit pushes mbufs into the same ifnet queue that the VAP > frames have (ie right now the VAP ifnet queue) - ie, serialise the raw > and non-raw VAP frames before it gets processed for 802.11 state; > * .. then move the VAP transmit to your model - which is > + vap transmit and raw transmit just push frames into the vap ifnet queue; > + vap transmit then schedules a deferred task or a direct dispatch + > deferred task if we cant grab the VAP TX lock; > + the vap transmit task/dispatch routine handles the frames one at a > time - either inside a task queue or inside the VAP TX lock - thus all > of the 802.3 -> 802.11 encapsulation and state handling is correctly > serialised _and_ the order of sequence numbers and frame handling is > maintained; > + then those frames have to be queued to the driver in _exactly_ the > same order - so either the VAP TX task/process queues them into a > driver staging queue and kicks the driver side ,or it goes into a > separate task to do driver dispatch; > + .. and then it's up to the driver to dequeue each frame, handle it > and push them into the hardware in the same order. > > Now, that's totally, ridiculously complicated but it does avoid a > bunch of reentrant and long-held-lock problems. > > The ridiculously uncomplicated version: > > * put a big IC TX lock around ieee80211_start(), ieee80211_output() > and any routine that is calling ieee80211_encap() -> if_transmit() or > ieee80211_encap() -> ic_raw_xmit(); > * do the same with the ageq and powersave queue that dispatches to the > driver - grab that big IC TX lock, dequeue all the frames to the > driver, release the IC lock; > * the driver TX code must grab the net80211 IC TX lock before it does > a deferred transmit - so the driver TX (not TX completion - TX!) > always has a consistent set of locking; > * do a bunch of net80211 TX path refactoring to unify the TX path a bit; > * just give in to the long-held locks and worry about tidying this > crap up later; > * hope to dear god there aren't any lock-order issues between the > comlock and this new lock; same as the other crap that's going on; This is the most scary part (LOR). > > Opinions? :) Here is a list of ideas presented so far. - lock whole tx path - use taskqueue - use queue (or linked lists) I'd like to avoid holding a lock for long time. taskqueue may have performance issue. Using queue is the one still standing. I think it should fix the problem. AK From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 25 07:27:50 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E1B38542 for ; Mon, 25 Feb 2013 07:27:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (we-in-x0231.1e100.net [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 815BE1F4 for ; Mon, 25 Feb 2013 07:27:50 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id d7so2159025wer.36 for ; Sun, 24 Feb 2013 23:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OoyUm/XpeElhlSa+W2FyoiuEtB4s9w+6B2XbDWi8h0g=; b=ULB4NY4IZptvEnoeUG20mSfPtcxKdotYZawE101tl5tmKWtlnI57qyud+b/v9Oyrhf 1FEL+tY2bl5i1IiVNHJwQP7UPqAUguAnELMyomrOjrEOAj38P3ClTOXBAXggmx6TJ3W7 vkXnbLW+c7RPoe4EVoAulVs9ODE5IX2mz0s+nHdwFZWE0n5U8BMyQhJIhgg4Wrjtgmyt IO9aYqtCZacwO+7UrIqnRWNgn3ynlP4DG3vz7Th3P9g4AMvYZAL62sCA+Rooia0jSvfN O9nQSuDkr1DmX5vE5f1dHBnupls9PUjAB2xU9p40BouEuiZu21htDZOwai5zcBlKqCtU waXA== MIME-Version: 1.0 X-Received: by 10.180.81.2 with SMTP id v2mr10103433wix.17.1361777268006; Sun, 24 Feb 2013 23:27:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Sun, 24 Feb 2013 23:27:47 -0800 (PST) In-Reply-To: References: Date: Sun, 24 Feb 2013 23:27:47 -0800 X-Google-Sender-Auth: B_6GC4RnNeiDM0Yunb7ZbT7mFdQ Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Mon, 25 Feb 2013 07:27:50 -0000 The trouble with using a queue is that things will dequeue frames out of order, bceause multiple dequeue contexts (ie, each call to driver_start / driver_transmit) will execute in-parallel. Yay. adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 25 10:54:44 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F394DC02 for ; Mon, 25 Feb 2013 10:54:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1D9D4E for ; Mon, 25 Feb 2013 10:54:43 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id l13so4413033wie.0 for ; Mon, 25 Feb 2013 02:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MBhDkYa46ovLCNNbULWa8Ib+wQB8qxhCnLoVfGaaM/E=; b=xlUXNIpQbcKX9CQD9jhL6SixzzOCAMdFKXgJulL/zjhxgId0kuj17Yd+LpX1cPpYh/ ko4vhcg6gYqf5vylzUKgV2wH2sgcUKvy1QncCGOUePXgzMaSqdTW2EyxsvTbNr2tK9TR 2tyrmwe1E9N5I2u2ssGr1OwHU1zLoIQqUJMEyLatPRLFeVRKbAPWROC3ZFwgpOKJIY2L pyYe/Hbrk3a5ivBm9iRo+OnnHhpikFM9Ec1JIraUSCreNp1LdzHwvTorDgZqkMcmQrnq esFXLhCr//4ICsebr+lVyJfT5Oabb0/8mpT6mOAVwjBPeUWexGcZt3fp8HAZUBVM9Suz mVyw== MIME-Version: 1.0 X-Received: by 10.194.238.226 with SMTP id vn2mr17854780wjc.23.1361789678164; Mon, 25 Feb 2013 02:54:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Mon, 25 Feb 2013 02:54:37 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 02:54:37 -0800 X-Google-Sender-Auth: oA3qcReZNlAru72lACNa0co7QVA Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Mon, 25 Feb 2013 10:54:44 -0000 Here we go: http://people.freebsd.org/~adrian/ath/20130225-net80211-txlock.diff See what you think. Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 25 11:06:58 2013 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFF91191 for ; Mon, 25 Feb 2013 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C26A4E93 for ; Mon, 25 Feb 2013 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1PB6w56066808 for ; Mon, 25 Feb 2013 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1PB6wU3066806 for freebsd-wireless@FreeBSD.org; Mon, 25 Feb 2013 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Feb 2013 11:06:58 GMT Message-Id: <201302251106.r1PB6wU3066806@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 Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org 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: Mon, 25 Feb 2013 11:06:58 -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/176238 wireless [ath] [patch] Correct buffer size calculation and simp o kern/176201 wireless [net80211] [patch] 11n station includes unrelated ht p o kern/176104 wireless [iwn] iwn0: iwn_intr: fatal firmware error o kern/175870 wireless [iwn] /etc/rc.d/netif restart cause system crash o kern/175722 wireless [ath]lot of bad seriesx hwrate in kernel messages o kern/175446 wireless [ath] high volumes of PHY errors lead to BB/MAC hangs o kern/175227 wireless [ath] beacon timers aren't necessarily reprogrammed af o kern/175183 wireless [iwn] iwn(4) becomes unresponsive during initial confi o kern/175053 wireless [iwn] iwn firmware error on 9-stable with Ultimate-N 6 o kern/174891 wireless [ieee80211] struct ieee80211_node is freed during acti o kern/174722 wireless [wlan] can't use channel 12 and 13 (14) with my wifi i o kern/174661 wireless [wlan] lost alias on wlan interface o kern/174283 wireless [net80211] panics in ieee80211_ff_age() and ieee80211_ o kern/174276 wireless [ath] if_ath memory modified after free o kern/174273 wireless [net80211] taking down a net80211 node with active fas o kern/173917 wireless [iwn] wpa-supplicant issues on iwn o kern/173898 wireless [iwn] [patch] iwn(4) DOES support 6235 chip. o kern/173883 wireless [ath] ath0: unable to attach - pci issue? o kern/173711 wireless [ath] powerd kills ath on the Asus EeePC 1005HA o kern/173342 wireless PS-Poll isn't working o kern/173336 wireless [ath] Atheros card improper device poweroff handling o o kern/172955 wireless [ath] 11n does not work in adhoc mode o kern/172706 wireless [wpi] wpi0 fails to load firmware when using country o kern/172672 wireless [ubt] Bluetooth device recognised but not working o kern/172661 wireless hostapd(8) securing wireless adapter in HostAP mode is o kern/172338 wireless [ath] [net80211] CCMP IV transmit counters are not cor o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171235 wireless [ath] ath loses connection, system freezes on netif re 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 kern/121061 wireless [ath] [panic] panic while ejecting ath(4)-adapter duri 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 153 problems total. From owner-freebsd-wireless@FreeBSD.ORG Tue Feb 26 05:48:39 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6EDFB1F7 for ; Tue, 26 Feb 2013 05:48:39 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm23-vm3.bullet.mail.ne1.yahoo.com (nm23-vm3.bullet.mail.ne1.yahoo.com [98.138.91.153]) by mx1.freebsd.org (Postfix) with ESMTP id 37AECE71 for ; Tue, 26 Feb 2013 05:48:38 +0000 (UTC) Received: from [98.138.90.53] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 26 Feb 2013 05:41:54 -0000 Received: from [98.138.226.59] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 26 Feb 2013 05:41:54 -0000 Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP; 26 Feb 2013 05:41:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1361857314; bh=9w6fPm/SxBottOBi3zzM6sp+/4qFfkEQ15ohLQfysKk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:X-Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=ngH8ddiAH35kdpmHsc4mAY0mu1RK+XplvhNKQq9ErtykItvJGGgsXfbZoLhVEGEq2/UDcIEHc6X5icYZ64EJYdSbBTnqKaVSd4Nr2CVTBoOYDzs7Jb7Aedxvgm37f/5DX0AHDVkjkCiClv3Vg9hkyX6fGcx2uykBHoVf7+s8G9M= X-Yahoo-Newman-Id: 847683.36236.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: TFJjbREVM1lZKCzCv33z9HmdlGtYqUfFkT7ljcSHfrpymfO TSR2ISL9PkK1_CyV53a6EaoCIB45FdWA2a0ZQYw.xeLgb.LtvAGT64YPUq25 G5kqOPzCHdHZ9nbR2dmomZ5OXuBsVcJIUdvp9OIpLWu4agDaohmC2V9zmkFC 0pcQEG6HZE2BbB6VL8bHeqZCRT1ipGuDrNzlUclavEXOG3.YrVKbpnlrCwIU Lb5Xacvv2l1BG8bTwsaDcuxVhw9wKytZtKjxW5HNsyNk9MQXGTJeQFUoHLJ9 agxDwv4q13ULMrYWa1CQ17QM4DTN6.3.ctxrfEog6gOWHl3MqqLToC.fTk70 2IwJ.Oygdvq.jkhROtjrHYsOujidm0lKboZigMDfZ_IZaAv_eVt7izhJPQB7 pr7HHfN1IKgBJ6FklKdOwI8e9OT4gDmpamhM.xEX5gWIEuE2fQBRzgy.1p_Q .8X46w9P8Cisj3t06zRHL X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-da0-f52.google.com (moonlightakkiy@209.85.210.52 with plain) by smtp210.mail.ne1.yahoo.com with SMTP; 25 Feb 2013 21:41:54 -0800 PST Received: by mail-da0-f52.google.com with SMTP id x33so817295dad.39 for ; Mon, 25 Feb 2013 21:41:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.68.227.129 with SMTP id sa1mr21738196pbc.107.1361857314137; Mon, 25 Feb 2013 21:41:54 -0800 (PST) Received: by 10.68.52.170 with HTTP; Mon, 25 Feb 2013 21:41:54 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 22:41:54 -0700 Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: PseudoCylon To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Tue, 26 Feb 2013 05:48:39 -0000 On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd wrote: > The trouble with using a queue is that things will dequeue frames out > of order, bceause multiple dequeue contexts (ie, each call to > driver_start / driver_transmit) will execute in-parallel. Actually, to prevent that, there is an extra queue. To begin driver_queue:packet1--packet2--3--4--... working_queue:empty hadware_queue:empty After multiple thread dequeue lock dequeue enqueue unlock lock dequeue enqueue unlock They look like, driver_queue:2--3--4--... working_queue:1--2 (the lock preserves the order) hardware_queue: empty If a thread has packet #1 finished first, there is no problem. If a thread has packet #2 finished first, it will try to dequeue the packet #1 (head of the queue) from the working_queue. But the packet isn't marked as "completed", so it will just return. Queue still look like driver_queue:2--3--4--... (of course, other threads are processing remaining packets, but to simplify, no change in driver_queue.) working_queue: 1--2 hardware: empty Later, once the thread with #1 finished processing, it will lock while (completed) {dequeue enqueue} unlock At the end, queue look like, driver_queue:2--3--4--... working_queue: empty hardware_queue: 1--2 (the lock preserves the order) Just wanted to clarify. I will soon test the latest txlock patch. AK From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 27 00:59:57 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E3515515 for ; Wed, 27 Feb 2013 00:59:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 77CB2E6F for ; Wed, 27 Feb 2013 00:59:57 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so4865345wgb.0 for ; Tue, 26 Feb 2013 16:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=gglyReKgXax2k9U9maKGgbYbVyiNkUuZ55JJUqINWbc=; b=e2986fDNxw5TeKNRl7uZRlWEWlL9XPk5qarDdvOtmzDBkOf5Tt5uEk5EjsRFEbih1P wWaaaBw9j4SK9xNnTrmoF8j72407rJiEVIEcypJcSgyACunEJmJJOYdtacKA9Rf6iVHb tusFJhjLRB//63I1LRp8JNzKmMIRXTDkAazTCzWgOQnuqgrmft12wr/PM5YLtc8C+pIw vJKoQkFv0p+2L+x4+ZkMnPReJlFxOTAspPZph8htow7C05afiiU+AcZzcgAURL/Xa4CB fyuxPq/KyoV84IwR1UHdc5wiE2G0X0SeZsBiw9Zfz0yJFTV0+z9T1ehcFpj8frxC8D3v XikA== MIME-Version: 1.0 X-Received: by 10.194.20.40 with SMTP id k8mr506582wje.16.1361926796541; Tue, 26 Feb 2013 16:59:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Tue, 26 Feb 2013 16:59:56 -0800 (PST) Date: Tue, 26 Feb 2013 16:59:56 -0800 X-Google-Sender-Auth: onm2PrV5ZVyG9_Y2rmS_UGFuBHg Message-ID: Subject: [CFT] STBC is enabled for AR9280 and later 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: Wed, 27 Feb 2013 00:59:57 -0000 Hiya, I've just enabled STBC TX and RX on the AR9280 and later. * STBC TX requires two chains to work right. So enabling a single chain only or the single chain NICs (AR9285) won't work; * STBC RX works with one chain but you really need two chains to get the benefit; * STBC is only supported for single-stream rates (MCS 0 -> 7.) So, for AR9280 and AR9287 users, STBC should work for you now out of the box. AR9285 users - you can receive STBC but it won't give you any benefits. The AR5416, AR9130 and AR9160 NICs don't support STBC. When the AR9300 HAL is released, STBC will work for all of those NICs. What does it mean? It should give increased sensitivity/performance at the lower MCS rates which should translate to a generally better wifi experience. THanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 27 08:52:01 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 222DFA9B for ; Wed, 27 Feb 2013 08:52:01 +0000 (UTC) (envelope-from mukunda@pointred.co) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by mx1.freebsd.org (Postfix) with SMTP id AC7401C8 for ; Wed, 27 Feb 2013 08:52:00 +0000 (UTC) Received: from mail-pb0-f72.google.com ([209.85.160.72]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUS3JKRfMf55QOikU+/s1E92bnZMOcx5+@postini.com; Wed, 27 Feb 2013 00:52:00 PST Received: by mail-pb0-f72.google.com with SMTP id wz12so466267pbc.7 for ; Wed, 27 Feb 2013 00:51:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qD4NliIEH5UBC4NAykYtG1r5lsPnSWGiqFU1iE4fsfw=; b=J+lp9IYUi39AwT+lPRt42GcNSD/ZsWZJuLnUx4HcycbO0hnsopQufI59lW2rzVFn3S /MLP9D7qvGqpB8ip7rWpJKDb6ZUWaU8zcC7vv6+rrLRGYzcjhmfaeoKIbzy/ZvVScp+g ujy1ZjfphV4KfZ1HVUXIpaucoLrA70maj54DrnSmSM7o/mJ9QbJPJZD5rN5bv4vB04sa nbkCRNAXPtKDvOH1+bjmvMyvHM9dI0aW395dR5DPbyXDLg5mWSWKAbol9JbdT6HfyowF tUn/sf1viq4ru5J2mwbf10celh7swGJ3NNGl+EzAIPGQFmvnP4uKlWpQLr9xxxE4a8WV MNoQ== X-Received: by 10.66.175.143 with SMTP id ca15mr6293316pac.155.1361955113530; Wed, 27 Feb 2013 00:51:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.175.143 with SMTP id ca15mr6293308pac.155.1361955113463; Wed, 27 Feb 2013 00:51:53 -0800 (PST) Received: by 10.68.43.228 with HTTP; Wed, 27 Feb 2013 00:51:53 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Feb 2013 14:21:53 +0530 Message-ID: Subject: Re: WiFi TDMA AR7161, results and moving forward From: Mukunda Haveri To: Adrian Chadd X-Gm-Message-State: ALoCoQlvoJjmEvUXcXerUidvk87qy/I2D5u2k7PYqZ/3aXZZvSi6kaOLAnRm8Z1dfnd7pRACkipslmAg5fBzHm+aAS98WSz/HFe9kQgNSFWD+pDaaysR/66xm2mzQEFo8/s4CIgkmhalJmnOMUQwDgoR/l0dBF27Y341aputZIqOYBJBi6Tm5Dw= Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org, freebsd-mips@freebsd.org 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: Wed, 27 Feb 2013 08:52:01 -0000 Hi, I have been trying in vain to get 2 freebsd based systems working with a wlan-lan bridge. | Host A | <---> | Lan-side arge0 | <--> | AP Wlan | <--- Air ------- > | STA Wlan | <---> | Lan-side arge0 | <--> | Host B | Is this functionality broken on the head? OR Am I missing something? Appreciate if somebody can help me with scripts to setup the traffic in the mode mentioned above. We are using AR9280 based wireless card along with AR7161 boards from Compex... Thanks, Mukunda On Tue, Feb 19, 2013 at 2:58 AM, Adrian Chadd wrote: > On 18 February 2013 03:31, Mukunda Haveri wrote: > > > > Thanks to Adrian's WiFi scripts, we were able to get the TDMA working on > the > > Compex-AR7161 board. The results were surprising; we are able to do, > close > > to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in > non-TDMA > > mode. We were able to achieve this, only after disabling all the debug > > options in the kernel. Porting the U-Boot to the Compex-boards did take > lot > > of effort, but not the "FreeBsd". Many thanks to all the "scientists" who > > made this possible. > > Nice! Which wireless cards are you using? > > [ AR9280 ] > > Moving forward, it is observed that the TDMA throughput peaks at 9 mbps > and > > refuses to move beyond. After reducing the slot duration to 1 ms, the > > throughput increased to around 12 mbps. I was expecting the TDMA to > yield a > > better throughput because of collision-less scheme. I would like to > > understand if our observation is expected or if there's some inherent > > limitation within the TDMA controller. > > > > It will be good to have some feedback from TDMers with similar > experience or > > better. > > Right now the TDMA code doesn't implement MCS rates or TX aggregation. > Thus you're not going to get 11n like throughput. > > The first thing to implement is allowing for MCS rates > (non-aggregation) and make sure all the packet duration calculations > are being done "right". > > After that, we need to implement delayed blockack support in net80211 > and the ath driver. That requires the stack to support handling BA > requests/responses and ath(4) to mark all frame descriptors in a > delayed-BA TID to be no-ack. > > Once that's done, we can tie it all together to make it work over TDMA. :-) > > Thanks, > > > Adrian > DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 27 08:55:33 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BE06C1E; Wed, 27 Feb 2013 08:55:32 +0000 (UTC) (envelope-from sniperpr@gmail.com) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by mx1.freebsd.org (Postfix) with ESMTP id BCD7B1E7; Wed, 27 Feb 2013 08:55:32 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id un1so240166pbc.40 for ; Wed, 27 Feb 2013 00:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:date:from:to:cc:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type; bh=inY3aCNtBZ+RbOuVnriynfVHuiF2iU/YL1dYz8o1j24=; b=Ag3+EtqyRa2D+8aTaUcnuVRWJ1ek4zpT8j87uKISbFwLwRHK3zF8rQqlxU0RVbF1od POc0LK5QOcSCKb02qUj/7eI2VfEQWFeTFqZrcC7LRPGNHQJSmaL0cL4x5umJjxoeqQOi OIereXjZfZ3v19D0EdAvntNtN5PHulCUlfyrTGlzkhzHAwHQ5Vsg5kfQgINMnOJ/FVYY ukjgAPb5pGYIz7dpPEUFx1M2iPCh3tFXyCEDzxmjtJ9WHvKxpRUlRo6LJ8d43bVuEHhp lECaUVJy4UwJID9oOm4rFoadDlyxd6zRrnb8m26BKlFbJzW4/ok6WcFyyjFIENM1W4mI Ib0Q== X-Received: by 10.68.25.201 with SMTP id e9mr2142143pbg.145.1361955326185; Wed, 27 Feb 2013 00:55:26 -0800 (PST) Received: from [192.168.10.229] ([159.226.43.54]) by mx.google.com with ESMTPS id tm1sm3986134pbc.11.2013.02.27.00.55.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 27 Feb 2013 00:55:24 -0800 (PST) Date: Wed, 27 Feb 2013 16:55:16 +0800 From: "adam.huang" To: Mukunda Haveri Message-ID: <1BB5E063EDB64336B8482336F34B0555@gmail.com> In-Reply-To: References: Subject: =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=WiFi TDMA AR7161, results and moving forward X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org, freebsd-mips@freebsd.org 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: Wed, 27 Feb 2013 08:55:33 -0000 hi, can you share your complex =46W=3F thanks. =20 =E5=9C=A8 2013=E5=B9=B42=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=884:51=EF=BC=8CMukunda Haveri =E5=86=99=E9=81=93=EF= =BC=9A > Hi, > =20 > I have been trying in vain to get 2 freebsd based systems working with = a > wlan-lan bridge. > =20 > =7C Host A =7C <---> =7C Lan-side arge0 =7C <--> =7C AP Wlan =7C <--- A= ir ------- > > =7C STA Wlan =7C <---> =7C Lan-side arge0 =7C <--> =7C Host B =7C > =20 > Is this functionality broken on the head=3F OR Am I missing something=3F= > Appreciate if somebody can help me with scripts to setup the traffic in= the > mode mentioned above. > We are using AR9280 based wireless card along with AR7161 boards from > Compex... > =20 > Thanks, > Mukunda > =20 > =20 > On Tue, =46eb 19, 2013 at 2:58 AM, Adrian Chadd wrote: > =20 > > On 18 =46ebruary 2013 03:31, Mukunda Haveri wrote: > > > =20 > > > Thanks to Adrian's Wi=46i scripts, we were able to get the TDMA wor= king on > > the > > > Compex-AR7161 board. The results were surprising; we are able to do= , > > =20 > > close > > > to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in > > =20 > > non-TDMA > > > mode. We were able to achieve this, only after disabling all the de= bug > > > options in the kernel. Porting the U-Boot to the Compex-boards did = take > > > =20 > > =20 > > lot > > > of effort, but not the =22=46reeBsd=22. Many thanks to all the =22s= cientists=22 who > > > made this possible. > > > =20 > > =20 > > =20 > > Nice=21 Which wireless cards are you using=3F > > =20 > > =5B AR9280 =5D > =20 > =20 > > > Moving forward, it is observed that the TDMA throughput peaks at 9 = mbps > > and > > > refuses to move beyond. After reducing the slot duration to 1 ms, t= he > > > throughput increased to around 12 mbps. I was expecting the TDMA to= > > > =20 > > =20 > > yield a > > > better throughput because of collision-less scheme. I would like to= > > > understand if our observation is expected or if there's some inhere= nt > > > limitation within the TDMA controller. > > > =20 > > > It will be good to have some feedback from TDMers with similar > > experience or > > > better. > > =20 > > =20 > > Right now the TDMA code doesn't implement MCS rates or TX aggregation= . > > Thus you're not going to get 11n like throughput. > > =20 > > The first thing to implement is allowing for MCS rates > > (non-aggregation) and make sure all the packet duration calculations > > are being done =22right=22. > > =20 > > After that, we need to implement delayed blockack support in net80211= > > and the ath driver. That requires the stack to support handling BA > > requests/responses and ath(4) to mark all frame descriptors in a > > delayed-BA TID to be no-ack. > > =20 > > Once that's done, we can tie it all together to make it work over TDM= A. :-) > > =20 > > Thanks, > > =20 > > =20 > > Adrian > =20 > DISCLAIMER: > The information contained in this message (including any attachments) i= s confidential and may be privileged. If you have received it by mistake = please notify the sender by return e-mail and permanently delete this mes= sage and any attachments from your system. Any dissemination, use, review= , distribution, printing or copying of this message in whole or in part i= s strictly prohibited. Please note that e-mails are susceptible to change= . PointRed Telecom Ltd (including its group companies) shall not be liabl= e for the improper or incomplete transmission of the information containe= d in this communication nor for any delay in its receipt or damage to you= r system and does not guarantee that the integrity of this communication = has been maintained or that this communication is free of viruses, interc= eptions or interferences. =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > freebsd-mips=40freebsd.org (mailto:freebsd-mips=40freebsd.org) mailing = list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to =22freebsd-mips-unsubscribe=40freebsd.= org (mailto:freebsd-mips-unsubscribe=40freebsd.org)=22 > =20 > =20 From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 27 09:09:13 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD073DE for ; Wed, 27 Feb 2013 09:09:13 +0000 (UTC) (envelope-from mukunda@pointred.co) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by mx1.freebsd.org (Postfix) with SMTP id 35B91273 for ; Wed, 27 Feb 2013 09:09:13 +0000 (UTC) Received: from mail-pa0-f70.google.com ([209.85.220.70]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUS3NM36mB4zFTtzplOmk5SgU445wAez9@postini.com; Wed, 27 Feb 2013 01:09:13 PST Received: by mail-pa0-f70.google.com with SMTP id kp1so613356pab.1 for ; Wed, 27 Feb 2013 01:09:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=dIU2lllvWlgGAoUQx8O7qrLuFvzA6M2W+OF6jaOi7G8=; b=L9nrr7EQIXf7ykvezT+q2o8byQb67nfjzEE8tzg1PZ54IsIrIy/cy7i6ZmU1Lc2DhI PxKkl2g65aLWZA0waicOqut+MYlg/TbutrtjYC7CiLKPGsvsTgTYF7OZ8s9/ZLX2ZulU 19f7N3A6blcKSq1yIsvJQVGHZyoN+u/C4ddy4lZG2XFCvVClHhpRwErhnbdP91Apo4EU YW/egf6P5+Q4wEsJIdqrzClMRV92SK1bGLuMqcNP3FEW133EhSfDdqB4icEwIM0iTdIc 32ABOIXVDHP/j05WdO+iqnMLSn4E3B2+IUsaD2yoN8u++TFB9NR0D8hXNFcnPKl40H2f q/ug== X-Received: by 10.68.137.7 with SMTP id qe7mr2233382pbb.141.1361956146920; Wed, 27 Feb 2013 01:09:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.68.137.7 with SMTP id qe7mr2233373pbb.141.1361956146817; Wed, 27 Feb 2013 01:09:06 -0800 (PST) Received: by 10.68.43.228 with HTTP; Wed, 27 Feb 2013 01:09:06 -0800 (PST) In-Reply-To: <1BB5E063EDB64336B8482336F34B0555@gmail.com> References: <1BB5E063EDB64336B8482336F34B0555@gmail.com> Date: Wed, 27 Feb 2013 14:39:06 +0530 Message-ID: Subject: =?UTF-8?B?UmU6IOWbnuWkje+8miBXaUZpIFRETUEgQVI3MTYxLCByZXN1bHRzIGFuZCBtb3ZpbmcgZg==?= =?UTF-8?B?b3J3YXJk?= From: Mukunda Haveri To: "adam.huang" X-Gm-Message-State: ALoCoQlL15FBqrIOD9epdpv4gbTwMZNN6IE/IFLs+q3e4KKWSgsyp/pQ8s846nSWoMKcjI6riYC2h5E3iVGVR36ST4JXDwTswvxkNmlYvY1sjexNAoRX7azYeLXWHfUji+3cNWRgzbMghp8Kd7VgqjtvZjnBu60WUZxz6aCWqbAaJkuXMiyJ/ck= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org, freebsd-mips@freebsd.org 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: Wed, 27 Feb 2013 09:09:13 -0000 I can. Do you want to check it out yourself? That will be great. On the other hand, if you are looking to check out some thing different quickly, As I said earlier, I have not done any great deal of changes. Just checkout the head and alter a few parameters in the /sys/mips/conf file according to your hardware and compile. It just works !!! On Wed, Feb 27, 2013 at 2:25 PM, adam.huang wrote: > hi, can you share your complex FW? > > thanks. > > =E5=9C=A8 2013=E5=B9=B42=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89= =EF=BC=8C=E4=B8=8B=E5=8D=884:51=EF=BC=8CMukunda Haveri =E5=86=99=E9=81=93= =EF=BC=9A > > Hi, > > I have been trying in vain to get 2 freebsd based systems working with a > wlan-lan bridge. > > | Host A | <---> | Lan-side arge0 | <--> | AP Wlan | <--- Air ------- > > | STA Wlan | <---> | Lan-side arge0 | <--> | Host B | > > Is this functionality broken on the head? OR Am I missing something? > Appreciate if somebody can help me with scripts to setup the traffic in t= he > mode mentioned above. > We are using AR9280 based wireless card along with AR7161 boards from > Compex... > > Thanks, > Mukunda > > > On Tue, Feb 19, 2013 at 2:58 AM, Adrian Chadd wrote: > > On 18 February 2013 03:31, Mukunda Haveri wrote: > > > Thanks to Adrian's WiFi scripts, we were able to get the TDMA working on > > the > > Compex-AR7161 board. The results were surprising; we are able to do, > > close > > to 100 mbps one way iperf tests and 40 mbps bidirectional Iperf in > > non-TDMA > > mode. We were able to achieve this, only after disabling all the debug > options in the kernel. Porting the U-Boot to the Compex-boards did take > > lot > > of effort, but not the "FreeBsd". Many thanks to all the "scientists" who > made this possible. > > > Nice! Which wireless cards are you using? > > [ AR9280 ] > > > > Moving forward, it is observed that the TDMA throughput peaks at 9 mbps > > and > > refuses to move beyond. After reducing the slot duration to 1 ms, the > throughput increased to around 12 mbps. I was expecting the TDMA to > > yield a > > better throughput because of collision-less scheme. I would like to > understand if our observation is expected or if there's some inherent > limitation within the TDMA controller. > > It will be good to have some feedback from TDMers with similar > > experience or > > better. > > > Right now the TDMA code doesn't implement MCS rates or TX aggregation. > Thus you're not going to get 11n like throughput. > > The first thing to implement is allowing for MCS rates > (non-aggregation) and make sure all the packet duration calculations > are being done "right". > > After that, we need to implement delayed blockack support in net80211 > and the ath driver. That requires the stack to support handling BA > requests/responses and ath(4) to mark all frame descriptors in a > delayed-BA TID to be no-ack. > > Once that's done, we can tie it all together to make it work over TDMA. := -) > > Thanks, > > > Adrian > > > DISCLAIMER: > The information contained in this message (including any attachments) is > confidential and may be privileged. If you have received it by mistake > please notify the sender by return e-mail and permanently delete this > message and any attachments from your system. Any dissemination, use, > review, distribution, printing or copying of this message in whole or in > part is strictly prohibited. Please note that e-mails are susceptible to > change. PointRed Telecom Ltd (including its group companies) shall not be > liable for the improper or incomplete transmission of the information > contained in this communication nor for any delay in its receipt or damag= e > to your system and does not guarantee that the integrity of this > communication has been maintained or that this communication is free of > viruses, interceptions or interferences. > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > > > --=20 Mukunda H S V.P, Engineering mukunda@pointred.co 18/11B, Roopena Agrahara, Begur Hobli, Hosur Main Road, Bangalore - 560068. [image: Phone] Phone: +91 80 25724854 [image: Fax] Fax: + 91 80 25724856 DISCLAIMER: The information contained in this message (including any attachments) is = confidential and may be privileged. If you have received it by mistake pl= ease notify the sender by return e-mail and permanently delete this messa= ge and any attachments from your system. Any dissemination, use, review, = distribution, printing or copying of this message in whole or in part is = strictly prohibited. Please note that e-mails are susceptible to change. = PointRed Telecom Ltd (including its group companies) shall not be liable = for the improper or incomplete transmission of the information contained = in this communication nor for any delay in its receipt or damage to your = system and does not guarantee that the integrity of this communication ha= s been maintained or that this communication is free of viruses, intercep= tions or interferences. = =0D From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 00:30:41 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC409CF4 for ; Thu, 28 Feb 2013 00:30:41 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-ye0-f176.google.com (mail-ye0-f176.google.com [209.85.213.176]) by mx1.freebsd.org (Postfix) with ESMTP id 75CE8D15 for ; Thu, 28 Feb 2013 00:30:41 +0000 (UTC) Received: by mail-ye0-f176.google.com with SMTP id m9so137285yen.35 for ; Wed, 27 Feb 2013 16:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=+8cCR0BtFYyVcihPfpdVsG4yv9aKjTq3rF8rY4CXbQQ=; b=Vc7gC9X+fHpTwgX91oViMrJoZ5QtYsLcnj3an9gPKH/r+vYjpTWz+JrtSxdKU6XJbM of6xwFt6uNu1c05Wzmzx+C8gi85JyBwx9krN1jUyOAPTNSOurO9LQ3TmDtA/WuvatZ78 N+WJL1uqOk2mwwQuS1khGx/74coidfVDU7MdaxReon+csm9ir07jSDQAEbs6iNtNS0XM NaQsCCGNnO1v9xp0udCrI9qB1+QbviTSuGKLWDiQgSKSol10vUsnO3xlCwgFMFRDBH4b v8+NSe1exaXTO8anmOczNQnLDLICKfW/JuP/ji7xpGtY+ReS+uxpwfChrO28sHzyqI9Z 3xCg== X-Received: by 10.236.145.226 with SMTP id p62mr3207953yhj.165.1362011434501; Wed, 27 Feb 2013 16:30:34 -0800 (PST) Received: from zeus.localnet (c-71-226-137-213.hsd1.ga.comcast.net. [71.226.137.213]) by mx.google.com with ESMTPS id d80sm10630628yhg.4.2013.02.27.16.30.33 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 16:30:34 -0800 (PST) From: Derrick Dantavious Edwards To: freebsd-wireless@freebsd.org Subject: ath0 Device Timeout Issues Date: Wed, 27 Feb 2013 19:30:32 -0500 Message-ID: <1413125.YF2HxR6oBY@zeus> User-Agent: KMail/4.9.5 (FreeBSD/10.0-CURRENT; KDE/4.9.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 28 Feb 2013 00:30:41 -0000 Hi, During recent upgrades to Current, I have been experiencing timeouts with the ath0 device. These are the errors that I am receiving. Any ideas? V/r Derrick ath0: ath_tx_tid_drain_print: norm: node 0xffffff802adf3000: bf=0xffffff8001d6e000: addbaw=0, dobaw=0, seqno=0, retry=0 ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: bf=0xffffff8001d6e000: txq[3] axq_depth=0, axq_aggr_depth=0 ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: bf=0xffffff8001d6e000: tid txq_depth=2 hwq_depth=0, bar_wait=0, isfiltered=0 ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: tid 16: sched=1, paused=0, incomp=0, baw_head=0, baw_tail=0 txa_start=-1, ni_txseqs=5 NODS 00:22:5f:78:b1:0a->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 0M 4000 0000 ffff ffff ffff 0022 5f78 b10a ffff ffff ffff 3000 0000 0108 8284 8b96 0c12 1824 3014 0100 000f ac04 0100 000f ac04 0100 000f ac02 0000 3204 3048 606c ath0: device timeout ath0: ath_tx_tid_drain_print: norm: node 0xffffff80270e6000: bf=0xffffff8001d6ee10: addbaw=0, dobaw=0, seqno=0, retry=0 ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: bf=0xffffff8001d6ee10: txq[3] axq_depth=0, axq_aggr_depth=0 ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: bf=0xffffff8001d6ee10: tid txq_depth=2 hwq_depth=0, bar_wait=0, isfiltered=0 ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: tid 16: sched=1, paused=0, incomp=0, baw_head=0, baw_tail=0 txa_start=-1, ni_txseqs=5 NODS 00:22:5f:78:b1:0a->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 0M 4000 0000 ffff ffff ffff 0022 5f78 b10a ffff ffff ffff 3000 0000 0108 8284 8b96 0c12 1824 3014 0100 000f ac04 0100 000f ac04 0100 000f ac02 0000 3204 3048 606c ath0: device timeout FreeBSD 10.0-CURRENT #0 r247397: Wed Feb 27 08:53:24 EST 2013 ath0@pci0:2:0:0: class=0x028000 card=0x3041103c chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR928X Wireless Network Adapter (PCI-Express)' class = network From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 02:45:07 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03D461FB for ; Thu, 28 Feb 2013 02:45:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 81469323 for ; Thu, 28 Feb 2013 02:45:06 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so1027256wgb.8 for ; Wed, 27 Feb 2013 18:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=V+WqpaTXi4ggjfoMcVjDXQHKeKQdRWGzknmCeKgoq7A=; b=0krnN1tlOSLr/36wzdN8kxTGUlbyqH/h5WnCI6Llv9IE7ebVjvlE6J9Gyll1ZJNHYo Np8wsDNPXStlSfAaKLdWSwnZzdGdypN8kEMEUA/XJo1UxQ3pzy0Kj/Z2Koexx66Jx5Y8 lznk2Inod+MCjbXquIrzsLCx4GUzaoG3j0ik9KO0Q1uniorkvoCAdnj0SlNb0LAtjTY4 9AV63feDQ/IauNtPqKMdhhudcQzPJXUGtnQgQxcVF9h3L/RqlQGIpB+asjvhBFQm6U7I Qqr/uwwymCLYkFK1SWJMmk4gOgsZr6XD7bOJIH/cZr3t8R+hkUgHpYpDizBApiCGIGL9 Gzew== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr7513457wib.33.1362019505131; Wed, 27 Feb 2013 18:45:05 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Wed, 27 Feb 2013 18:45:04 -0800 (PST) In-Reply-To: <1413125.YF2HxR6oBY@zeus> References: <1413125.YF2HxR6oBY@zeus> Date: Wed, 27 Feb 2013 18:45:04 -0800 X-Google-Sender-Auth: is5hhh0P1CZh7Phsjj7CKbRigwI Message-ID: Subject: Re: ath0 Device Timeout Issues From: Adrian Chadd To: Derrick Dantavious Edwards Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 02:45:07 -0000 These are only during probe requests, right? adrian On 27 February 2013 16:30, Derrick Dantavious Edwards wrote: > Hi, > During recent upgrades to Current, I have been experiencing timeouts with the > ath0 device. These are the errors that I am receiving. Any ideas? > > V/r > > Derrick > > > > ath0: ath_tx_tid_drain_print: norm: node 0xffffff802adf3000: > bf=0xffffff8001d6e000: addbaw=0, dobaw=0, seqno=0, retry=0 > ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: bf=0xffffff8001d6e000: > txq[3] axq_depth=0, axq_aggr_depth=0 > ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: bf=0xffffff8001d6e000: > tid txq_depth=2 hwq_depth=0, bar_wait=0, isfiltered=0 > ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: tid 16: sched=1, > paused=0, incomp=0, baw_head=0, baw_tail=0 txa_start=-1, ni_txseqs=5 > NODS 00:22:5f:78:b1:0a->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 0M > 4000 0000 ffff ffff ffff 0022 5f78 b10a ffff ffff ffff 3000 0000 0108 8284 > 8b96 0c12 1824 3014 0100 000f ac04 0100 000f ac04 0100 000f ac02 0000 3204 > 3048 606c > ath0: device timeout > ath0: ath_tx_tid_drain_print: norm: node 0xffffff80270e6000: > bf=0xffffff8001d6ee10: addbaw=0, dobaw=0, seqno=0, retry=0 > ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: bf=0xffffff8001d6ee10: > txq[3] axq_depth=0, axq_aggr_depth=0 > ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: bf=0xffffff8001d6ee10: > tid txq_depth=2 hwq_depth=0, bar_wait=0, isfiltered=0 > ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: tid 16: sched=1, > paused=0, incomp=0, baw_head=0, baw_tail=0 txa_start=-1, ni_txseqs=5 > NODS 00:22:5f:78:b1:0a->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 0M > 4000 0000 ffff ffff ffff 0022 5f78 b10a ffff ffff ffff 3000 0000 0108 8284 > 8b96 0c12 1824 3014 0100 000f ac04 0100 000f ac04 0100 000f ac02 0000 3204 > 3048 606c > ath0: device timeout > > FreeBSD 10.0-CURRENT #0 r247397: Wed Feb 27 08:53:24 EST 2013 > > ath0@pci0:2:0:0: class=0x028000 card=0x3041103c chip=0x002a168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR928X Wireless Network Adapter (PCI-Express)' > class = network > > _______________________________________________ > 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 Thu Feb 28 02:59:45 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E65647F; Thu, 28 Feb 2013 02:59:45 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-ye0-f181.google.com (mail-ye0-f181.google.com [209.85.213.181]) by mx1.freebsd.org (Postfix) with ESMTP id 183463C6; Thu, 28 Feb 2013 02:59:44 +0000 (UTC) Received: by mail-ye0-f181.google.com with SMTP id l2so205429yen.40 for ; Wed, 27 Feb 2013 18:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=xy9BR41Oj9cKpQlMqcfs2qbJhECrDRd3xtmGWAp/uI4=; b=DIarAE0hNQ6lDFUmJdQNRDdHKUfea+zqreYB6Bn2Lcgwhp/vyhkCz1Hkb3K6JNjw+H efvY/hqXn0FTsmwQoy+4yt5wds8ZmEYJiyHVBS/oORcIVkPslX69v8nogRNq1zlzXLhE sYUh9l2NEhkvKNxPCCxIIemICw9U8Hrrx4tEnZvq4pvDRQaMDAVsMemA9erpqXDB6nfk hUbttYQ1V4RfmhAjy684tgcyIb2iMa3h21VrubkYKYEpak0gLA3mPGax92fNLQivJ+74 Ng5jYvJBACjOTVs0fDIVR9JnaVs67fBzG6MTB4GEopSm04WTjTGgZhRkoZ3ANZ/mgaBA lcoQ== X-Received: by 10.236.69.99 with SMTP id m63mr3645799yhd.46.1362020378322; Wed, 27 Feb 2013 18:59:38 -0800 (PST) Received: from zeus.localnet (c-71-226-137-213.hsd1.ga.comcast.net. [71.226.137.213]) by mx.google.com with ESMTPS id x8sm11251765yhn.12.2013.02.27.18.59.37 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 18:59:37 -0800 (PST) From: Derrick Dantavious Edwards To: Adrian Chadd , freebsd-wireless@freebsd.org Subject: Re: ath0 Device Timeout Issues Date: Wed, 27 Feb 2013 21:59:35 -0500 Message-ID: <2287510.yA44TplU79@zeus> User-Agent: KMail/4.9.5 (FreeBSD/10.0-CURRENT; KDE/4.9.5; amd64; ; ) In-Reply-To: References: <1413125.YF2HxR6oBY@zeus> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 28 Feb 2013 02:59:45 -0000 On Wednesday, February 27, 2013 06:45:04 PM you wrote: > These are only during probe requests, right? > > > > > adrian > > > On 27 February 2013 16:30, Derrick Dantavious Edwards > > wrote: > > Hi, > > > > During recent upgrades to Current, I have been experiencing timeouts with > > the ath0 device. These are the errors that I am receiving. Any ideas? > > > > V/r > > > > Derrick > > > > > > > > ath0: ath_tx_tid_drain_print: norm: node 0xffffff802adf3000: > > bf=0xffffff8001d6e000: addbaw=0, dobaw=0, seqno=0, retry=0 > > ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: > > bf=0xffffff8001d6e000: txq[3] axq_depth=0, axq_aggr_depth=0 > > ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: > > bf=0xffffff8001d6e000: tid txq_depth=2 hwq_depth=0, bar_wait=0, > > isfiltered=0 > > ath0: ath_tx_tid_drain_print: node 0xffffff802adf3000: tid 16: sched=1, > > paused=0, incomp=0, baw_head=0, baw_tail=0 txa_start=-1, ni_txseqs=5 > > NODS 00:22:5f:78:b1:0a->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 0M > > > > 4000 0000 ffff ffff ffff 0022 5f78 b10a ffff ffff ffff 3000 0000 0108 > > 8284 > > > > 8b96 0c12 1824 3014 0100 000f ac04 0100 000f ac04 0100 000f ac02 0000 3204 > > 3048 606c > > ath0: device timeout > > ath0: ath_tx_tid_drain_print: norm: node 0xffffff80270e6000: > > bf=0xffffff8001d6ee10: addbaw=0, dobaw=0, seqno=0, retry=0 > > ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: > > bf=0xffffff8001d6ee10: txq[3] axq_depth=0, axq_aggr_depth=0 > > ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: > > bf=0xffffff8001d6ee10: tid txq_depth=2 hwq_depth=0, bar_wait=0, > > isfiltered=0 > > ath0: ath_tx_tid_drain_print: node 0xffffff80270e6000: tid 16: sched=1, > > paused=0, incomp=0, baw_head=0, baw_tail=0 txa_start=-1, ni_txseqs=5 > > NODS 00:22:5f:78:b1:0a->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 0M > > > > 4000 0000 ffff ffff ffff 0022 5f78 b10a ffff ffff ffff 3000 0000 0108 > > 8284 > > > > 8b96 0c12 1824 3014 0100 000f ac04 0100 000f ac04 0100 000f ac02 0000 3204 > > 3048 606c > > ath0: device timeout > > > > FreeBSD 10.0-CURRENT #0 r247397: Wed Feb 27 08:53:24 EST 2013 > > > > ath0@pci0:2:0:0: class=0x028000 card=0x3041103c chip=0x002a168c > > rev=0x01 hdr=0x00 > > > > vendor = 'Atheros Communications Inc.' > > device = 'AR928X Wireless Network Adapter (PCI-Express)' > > class = network > > > > _______________________________________________ > > 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" Yes. When I start the system, I get those messages. Wireless Link fails to establish thus causing all services requring link to fail....ie NFS . Soon after I am at the command prompt or GUI, I can ping hosts however, I have to /etc/rc.d/mountlate to get remote filesystems connected. Thanks for your assistance. V/r Derrick From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 03:27:23 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 973F09FC for ; Thu, 28 Feb 2013 03:27:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 36AB875D for ; Thu, 28 Feb 2013 03:27:23 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t44so1100291wey.12 for ; Wed, 27 Feb 2013 19:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3do/tfB5DN3sp0n5u/XJ/ryk/MHdGKVNhvY7EPb5IOo=; b=CSV6oZhO3CXEzYMQDIMBqGJ/u31HCvAWTt1d0Ng6vdhllz+/N3bYeCcWgmzWaHuyO7 M3kU3w0sdvE9eSOl6nzYiLraHdRqTrP0LcMA178e8Gcjv1k5kTsX0BkU3pBJk6PHNMCG oABhMxoc01s1Rg+ejOlERynRSkS/EK2CVw9ERxtqQ7TOuT3LDgR2djhHCPUhHc/7yXwd Weph25vQyVbogmf28dpsLyntOVnMatwr9QpKzXrqZpS9Y4wG5bPy6voHisCllocwJObs m3nMBozixLNc8ZWLg3Zu9uSkdGrSM2LljNxaos38W49zkOFX/I8LVIgBOPnjItrfaVLt lWAg== MIME-Version: 1.0 X-Received: by 10.180.108.229 with SMTP id hn5mr2744330wib.28.1362022041777; Wed, 27 Feb 2013 19:27:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Wed, 27 Feb 2013 19:27:21 -0800 (PST) In-Reply-To: <2287510.yA44TplU79@zeus> References: <1413125.YF2HxR6oBY@zeus> <2287510.yA44TplU79@zeus> Date: Wed, 27 Feb 2013 19:27:21 -0800 X-Google-Sender-Auth: T65aMjNigVJgv6zphnqShgVNKSo Message-ID: Subject: Re: ath0 Device Timeout Issues From: Adrian Chadd To: Derrick Dantavious Edwards Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 03:27:23 -0000 On 27 February 2013 18:59, Derrick Dantavious Edwards wrote: > > Yes. When I start the system, I get those messages. Wireless Link fails to > establish thus causing all services requring link to fail....ie NFS . Soon > after I am at the command prompt or GUI, I can ping hosts however, I have to > /etc/rc.d/mountlate to get remote filesystems connected. Thanks for your > assistance. > right. Well, those network services should only (re)start once the network link is up. But as to why the network link is taking a while to come up; I'm not sure. The device timeouts are a known race. It's not indicative that a device timeout actually did occur. Fixing the watchdog to be actually correct is on my TODO list but it's fallen behind in priority. I have a feeling that the probe requests aren't being given enough time to go out. Would you mind trying to change the eventtimer / timesource (sysctl kern.eventtimer and sysctl kern.timecounter); see if that helps things along? Thanks, adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 10:03:31 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEB9820F for ; Thu, 28 Feb 2013 10:03:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 774CE18DF for ; Thu, 28 Feb 2013 10:03:31 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D0CD04AC57 for ; Thu, 28 Feb 2013 14:03:29 +0400 (MSK) Date: Thu, 28 Feb 2013 14:03:24 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1297065968.20130228140324@serebryakov.spb.ru> To: freebsd-wireless@freebsd.org Subject: Are 802.11s and "classical" AP compatible? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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, 28 Feb 2013 10:03:31 -0000 Hello, Freebsd-wireless. ath could have several VAPs, each with its own SSID and security settings (but with shared channel(s), of course). Is it possible to do 802.11s node and "classical" AP on one card, to have 802.11s <-> WiFi gateway with one piece of hardware? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 10:04:42 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 777D622B; Thu, 28 Feb 2013 10:04:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by mx1.freebsd.org (Postfix) with ESMTP id 4A81D18E6; Thu, 28 Feb 2013 10:04:41 +0000 (UTC) Received: by mail-da0-f41.google.com with SMTP id j17so797769dan.28 for ; Thu, 28 Feb 2013 02:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LtNkxVUkZblya7p/A23Xh6xDY8hWJKgO4GszvEkGi6g=; b=Ifnt8Ph3kQZE/wknN5BD/iWmgcgsP0L31i2994tLq/49Qiqxy/NAR6JYfTvH5ukpKs T9MKexxz3nr3JHJLL4Eq4qn9AnCXyoV+cBRZ/QQUi7upHgR9wUXKHOZ+E+eF1VD/dmES Z5wVxs7goya+dQb9frWRxeMLMiTcN8gbAnqRHWKby5KMK+3wlyaX5nR3/GYpCkmI9uYl MdztDbahhyO9S4Lq67BOzejsfdLuEZsY+D+JMAlX8O1tvXXC+O+uEQjKuDDr3yd0ca1T 9hKh3Aexu/GiEHAvOPafytD9vHuYSwS5zeiSfpVnTBbCSJAh9GqOz5Mei+z7p66iKTB+ YK+A== MIME-Version: 1.0 X-Received: by 10.66.122.74 with SMTP id lq10mr12312096pab.189.1362045881492; Thu, 28 Feb 2013 02:04:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.70.5.36 with HTTP; Thu, 28 Feb 2013 02:04:41 -0800 (PST) In-Reply-To: <1297065968.20130228140324@serebryakov.spb.ru> References: <1297065968.20130228140324@serebryakov.spb.ru> Date: Thu, 28 Feb 2013 02:04:41 -0800 X-Google-Sender-Auth: oDz7IYdagXUa7_JfjUVy-I3NQHw Message-ID: Subject: Re: Are 802.11s and "classical" AP compatible? From: Adrian Chadd To: Lev Serebryakov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 10:04:42 -0000 not yet, sorry. adrian On 28 February 2013 02:03, Lev Serebryakov wrote: > Hello, Freebsd-wireless. > > ath could have several VAPs, each with its own SSID and security > settings (but with shared channel(s), of course). > > Is it possible to do 802.11s node and "classical" AP on one card, to > have 802.11s <-> WiFi gateway with one piece of hardware? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > 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 Thu Feb 28 10:12:03 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D24F92B5; Thu, 28 Feb 2013 10:12:03 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7FEF31921; Thu, 28 Feb 2013 10:12:03 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6A8774AC57; Thu, 28 Feb 2013 14:11:52 +0400 (MSK) Date: Thu, 28 Feb 2013 14:11:47 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <19510652834.20130228141147@serebryakov.spb.ru> To: Adrian Chadd Subject: Re: Are 802.11s and "classical" AP compatible? In-Reply-To: References: <1297065968.20130228140324@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 10:12:03 -0000 Hello, Adrian. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 14:04= :41: AC> not yet, sorry. Is it limitation of FreeBSD's drivers or "universal" one? Friend of my have some ideas about such gateway, but he could use Linux-based "firmaware" (OpenWRT-based, really) as well. Do you know if Linux supports such mode? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 10:24:52 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3917B83F; Thu, 28 Feb 2013 10:24:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by mx1.freebsd.org (Postfix) with ESMTP id F0EEC19C3; Thu, 28 Feb 2013 10:24:51 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id bg4so1059800pad.26 for ; Thu, 28 Feb 2013 02:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4rtpDmEPUfNnOE7sbkPhcYSe/gtsPJqJ7kQ6byv0C5Y=; b=PmvSu53LW23cKyBRkVBI7x4H2hAP4SyODRZo3tnGzLCwIKcnHalb6mMZg4xuqAhN0+ M3rVTtoh8Ue9Vquq6jvC++kLFwsz68hQALpp9WHXLfw/UJ+NVWc0eF+gSd2XMu6HN0ve ajYMu6hQOp7Z53lQJZQ9Z07D8o5d+SZr68IuuKgLHGS6b6bUsYJX0xKvNjmey/H9LlZ1 o3N6JydM634Ji7EwQrn2pzsx3UzFEUirCKYSbBTIKByKds44wh4Z+ouMq0yCaiCtcEEA cJvxjIIKemhGLQTx++55I41aLT6ycPoN0tHW/aBQcoKYdnB+dVG6ZjpdqVs7uAthA3NB B2qw== MIME-Version: 1.0 X-Received: by 10.68.31.130 with SMTP id a2mr8015791pbi.213.1362046778975; Thu, 28 Feb 2013 02:19:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.70.5.36 with HTTP; Thu, 28 Feb 2013 02:19:38 -0800 (PST) In-Reply-To: <19510652834.20130228141147@serebryakov.spb.ru> References: <1297065968.20130228140324@serebryakov.spb.ru> <19510652834.20130228141147@serebryakov.spb.ru> Date: Thu, 28 Feb 2013 02:19:38 -0800 X-Google-Sender-Auth: qfnECvZZMj8_lFfZ2ZzhlC-erQk Message-ID: Subject: Re: Are 802.11s and "classical" AP compatible? From: Adrian Chadd To: Lev Serebryakov Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 10:24:52 -0000 On 28 February 2013 02:11, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 28 =C6=C5=D7=D2=C1=CC=D1 2013 =C7., 14:04:41: > > AC> not yet, sorry. > Is it limitation of FreeBSD's drivers or "universal" one? Friend of > my have some ideas about such gateway, but he could use Linux-based > "firmaware" (OpenWRT-based, really) as well. Do you know if Linux > supports such mode? You can hack around it to make it work, but the basic problem is the Atheros MAC only supports one mode at a time - AP or STA or IBSS. When doing mesh you want to synchonise TSF different to when you're in STA = mode. The Linux guys have ath9k doing AP+mesh and STA+mesh, for various values of "works". I haven't personally tried it but I've heard reports that it does work. Again, for various values of "work". :-) You could give it a try and spend the extra time making all of the 802.11s quirks work; then figure out what other quirky behaviour happens when you're also in AP or STA mode. I don't have the time to sit down and solve whatever issues do creep up when doing mesh + other VAPs, sorry. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 11:20:27 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09C57D0A; Thu, 28 Feb 2013 11:20:27 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-gg0-x22b.google.com (mail-gg0-x22b.google.com [IPv6:2607:f8b0:4002:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id B213D1BE7; Thu, 28 Feb 2013 11:20:26 +0000 (UTC) Received: by mail-gg0-f171.google.com with SMTP id j1so225554ggn.30 for ; Thu, 28 Feb 2013 03:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=hdmNVon1uavx8Euuk95+diAOglDqnEOAcj2yzedEJTU=; b=RydxwByROTuBiOoJS7wHqH4BuUdsJ5sdzJnR37WpfVqwPNVvBD4p7R/JJWWn/91Dps 2fe8O5aUXTcuO8MdF22FWaoUsHfMvU9V5yt3OuRiEo5ghnrrL02F3o7WqRG0TJThsiEo ao/fo04GeWQuymKLYkjrzCxYWhHGvOVwdxJf09qL0ywEmDpljGHs4wDPU5fMz5ZXbPyQ dkl07gOP04GsJsuqNYacG4fyd7xfrrzYGbnUvZYcF5miJoYI1o3VIi7iqUla5q0siqTq U6dBr/KrzAQMOkvdOa3Xm8TvV1UpOnC6F8qGvAsdB/JmJ8CufyiPCv96IuDT1+lzOQSv lpUg== X-Received: by 10.236.175.67 with SMTP id y43mr4285241yhl.162.1362050426245; Thu, 28 Feb 2013 03:20:26 -0800 (PST) Received: from zeus.localnet (c-71-226-137-213.hsd1.ga.comcast.net. [71.226.137.213]) by mx.google.com with ESMTPS id w2sm12680925yhh.7.2013.02.28.03.20.25 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 03:20:25 -0800 (PST) From: Derrick Dantavious Edwards To: Adrian Chadd Subject: Re: ath0 Device Timeout Issues Date: Thu, 28 Feb 2013 06:20:23 -0500 Message-ID: <7632564.pQ3RMLadSs@zeus> User-Agent: KMail/4.9.5 (FreeBSD/10.0-CURRENT; KDE/4.9.5; amd64; ; ) In-Reply-To: References: <1413125.YF2HxR6oBY@zeus> <2287510.yA44TplU79@zeus> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 11:20:27 -0000 On 27 February 2013 18:59, Derrick Dantavious Edwards wrote: > > Yes. When I start the system, I get those messages. Wireless Link fails to > establish thus causing all services requring link to fail....ie NFS . Soon > after I am at the command prompt or GUI, I can ping hosts however, I have to > /etc/rc.d/mountlate to get remote filesystems connected. Thanks for your > assistance. > right. Well, those network services should only (re)start once the network link is up. But as to why the network link is taking a while to come up; I'm not sure. The device timeouts are a known race. It's not indicative that a device timeout actually did occur. Fixing the watchdog to be actually correct is on my TODO list but it's fallen behind in priority. I have a feeling that the probe requests aren't being given enough time to go out. Would you mind trying to change the eventtimer / timesource (sysctl kern.eventtimer and sysctl kern.timecounter); see if that helps things along? Thanks, adrian Sure, I have no problem making a change. I placed the available options for my system below. Which do you prefer I use for this test? Derrick root@zeus:~ # sysctl kern.eventtimer kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.et.LAPIC.frequency: 49887865 kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.HPET.flags: 7 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 550 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.et.HPET4.flags: 3 kern.eventtimer.et.HPET4.frequency: 14318180 kern.eventtimer.et.HPET4.quality: 440 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) i8254(100) RTC(0) kern.eventtimer.singlemul: 2 kern.eventtimer.idletick: 0 kern.eventtimer.activetick: 1 kern.eventtimer.timer: LAPIC kern.eventtimer.periodic: 0 root@zeus:~ # sysctl kern.timecounter kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 2161173885 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 20336 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 3908063 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 2410520996 kern.timecounter.tc.TSC-low.frequency: 1247196540 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.stepwarnings: 0 kern.timecounter.hardware: TSC-low kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) i8254(0) HPET(950) dummy(-1000000) kern.timecounter.tick: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.smp_tsc: 1 kern.timecounter.tsc_shift: 1 From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 17:34:31 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C2FECC53 for ; Thu, 28 Feb 2013 17:34:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 60E2862A for ; Thu, 28 Feb 2013 17:34:31 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id fm10so1628979wgb.21 for ; Thu, 28 Feb 2013 09:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=doFygKYSHHopFG6idXEYLOvEkcsHbQ4vYMhBOlZIIs8=; b=jR2iNf1KZgZ3rAL6R/MKEl5UMbfEoVyLlErpQsGpZLY/wWAf7ls6obg0hGMYoiQyYx z+WpfwqBIt4LEH0pvecoR7CgUIT3RVMvW12OKIq2mjOs6uaAszZC8C3sHP8sISc4xuJo Ka1G+l5EBj/EbpzP5x/6lJ5wNKmMJp++ANFir0is1yzfZtt0PvtLaKyjhdig3P4hWsQH lzq3Nxygcw7FZBmHe471FiBtGrkkAUJbpm3wBz5/1rYPysZ64mUJgQ0L5ipXMCABvRoh dL93Cl6cLiOfmdGGjgn1l9ioE2cqLGik25ht0n1Hc4AFiRak3fJplbCRDSGorthYbDrb t54Q== MIME-Version: 1.0 X-Received: by 10.180.105.232 with SMTP id gp8mr34238417wib.33.1362072870384; Thu, 28 Feb 2013 09:34:30 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Thu, 28 Feb 2013 09:34:30 -0800 (PST) In-Reply-To: <7632564.pQ3RMLadSs@zeus> References: <1413125.YF2HxR6oBY@zeus> <2287510.yA44TplU79@zeus> <7632564.pQ3RMLadSs@zeus> Date: Thu, 28 Feb 2013 09:34:30 -0800 X-Google-Sender-Auth: R-NGqoQYwgLuy2eesluycZEBlmo Message-ID: Subject: Re: ath0 Device Timeout Issues From: Adrian Chadd To: Derrick Dantavious Edwards Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 17:34:31 -0000 Just experiment with changing the kern.eventtimer.periodic and kern.timecounter.hardware values. Thanks, Adrian On 28 February 2013 03:20, Derrick Dantavious Edwards wrote: > On 27 February 2013 18:59, Derrick Dantavious Edwards > wrote: >> >> Yes. When I start the system, I get those messages. Wireless Link fails > to >> establish thus causing all services requring link to fail....ie NFS . Soon >> after I am at the command prompt or GUI, I can ping hosts however, I have to >> /etc/rc.d/mountlate to get remote filesystems connected. Thanks for your >> assistance. >> > > right. Well, those network services should only (re)start once the > network link is up. > > But as to why the network link is taking a while to come up; I'm not sure. > > The device timeouts are a known race. It's not indicative that a > device timeout actually did occur. Fixing the watchdog to be actually > correct is on my TODO list but it's fallen behind in priority. > > I have a feeling that the probe requests aren't being given enough > time to go out. Would you mind trying to change the eventtimer / > timesource (sysctl kern.eventtimer and sysctl kern.timecounter); see > if that helps things along? > > Thanks, > > > > adrian > > Sure, I have no problem making a change. I placed the available options > for my system below. Which do you prefer I use for this test? > > Derrick > > root@zeus:~ # sysctl kern.eventtimer > kern.eventtimer.et.LAPIC.flags: 7 > kern.eventtimer.et.LAPIC.frequency: 49887865 > kern.eventtimer.et.LAPIC.quality: 600 > kern.eventtimer.et.HPET.flags: 7 > kern.eventtimer.et.HPET.frequency: 14318180 > kern.eventtimer.et.HPET.quality: 550 > kern.eventtimer.et.HPET1.flags: 3 > kern.eventtimer.et.HPET1.frequency: 14318180 > kern.eventtimer.et.HPET1.quality: 440 > kern.eventtimer.et.HPET2.flags: 3 > kern.eventtimer.et.HPET2.frequency: 14318180 > kern.eventtimer.et.HPET2.quality: 440 > kern.eventtimer.et.HPET3.flags: 3 > kern.eventtimer.et.HPET3.frequency: 14318180 > kern.eventtimer.et.HPET3.quality: 440 > kern.eventtimer.et.HPET4.flags: 3 > kern.eventtimer.et.HPET4.frequency: 14318180 > kern.eventtimer.et.HPET4.quality: 440 > kern.eventtimer.et.RTC.flags: 17 > kern.eventtimer.et.RTC.frequency: 32768 > kern.eventtimer.et.RTC.quality: 0 > kern.eventtimer.et.i8254.flags: 1 > kern.eventtimer.et.i8254.frequency: 1193182 > kern.eventtimer.et.i8254.quality: 100 > kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) > HPET4(440) i8254(100) RTC(0) > kern.eventtimer.singlemul: 2 > kern.eventtimer.idletick: 0 > kern.eventtimer.activetick: 1 > kern.eventtimer.timer: LAPIC > kern.eventtimer.periodic: 0 > > root@zeus:~ # sysctl kern.timecounter > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 2161173885 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 20336 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.ACPI-fast.counter: 3908063 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.TSC-low.mask: 4294967295 > kern.timecounter.tc.TSC-low.counter: 2410520996 > kern.timecounter.tc.TSC-low.frequency: 1247196540 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.stepwarnings: 0 > kern.timecounter.hardware: TSC-low > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) i8254(0) HPET(950) > dummy(-1000000) > kern.timecounter.tick: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.smp_tsc: 1 > kern.timecounter.tsc_shift: 1 > From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 23:35:34 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0DE9DFD for ; Thu, 28 Feb 2013 23:35:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC2C956 for ; Thu, 28 Feb 2013 23:35:33 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id fm10so1994572wgb.9 for ; Thu, 28 Feb 2013 15:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZnVtT+9dEHUmDEKHcUgfrlmsVAUoT1C5LGKVHT/xuWk=; b=s4HGNeJW3Vl5NiEojuBp7kcLeRQXTyByfKOMFZRKHUhbucMgxIVv5GHNF6UYeXQ72u XCSmLFQXqHWCyUGonhSFoXj+M/EN0nTWi/VQynlNN7MBMrSg1sLAUTPbN0BWA/l8KJcY ymjx2ESxzbSw1qXlOEpJ4gHhGCOykzRRdzPWL0urbRzjCmw8LhaS6Gq9TRxz8r7GJ/+N cqpXpkhQTE8++so5cKrBXP1Xjac0qy6Nu+NnKAwveg4NqkKFRVMTDiqVds90zJE5y1aI cii7zdwcgnmV+8amfU8kDB8i9hXlZ/vUZpi6DR6VPVccc37Y1/TS/E0vZNBoB8KmkXwJ /V9g== MIME-Version: 1.0 X-Received: by 10.180.73.238 with SMTP id o14mr616358wiv.32.1362094533020; Thu, 28 Feb 2013 15:35:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Thu, 28 Feb 2013 15:35:32 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Feb 2013 15:35:32 -0800 X-Google-Sender-Auth: qI2xwgv3oysixWn7r2xCzxQGeUY Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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, 28 Feb 2013 23:35:34 -0000 Hi, Right - but then I still need to hold long held locks here across the net80211 _and_ the driver. Ie: * net80211 needs to hold a lock for the entire process of dequeuing a frame and running it to completion. It can't do this: * grab lock * dequeue frame * release lock --> here things race * grab net80211 lock * run with frame * release net80211 lock So you have to hold _some_ lock for the entire length of time you're processing that frame: * grab queue lock * dequeue frame * grab net80211 lock * process frame * release net80211 lock * release queue lock Same deal goes with the driver. That's the unfortunate side effect of having multiple stack and driver transmit paths all wanting to service the same queue. So either you have these long held locks but you can do fully inline, direct-dispatch transmit; or you use taskqueues and just serialise everything through the taskqueue. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 23:38:22 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49935EB0 for ; Thu, 28 Feb 2013 23:38:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id E08CB974 for ; Thu, 28 Feb 2013 23:38:21 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so1970919wgb.20 for ; Thu, 28 Feb 2013 15:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=su9Ipnm9sUbILPYaKFTd2vCC84Z9YEvWmOSktftGa1U=; b=w5kEgnCbXvEFB86HuhEEBe67Ur5e9JcBrYP6KAtmQUzQ8+l2YLv2Wqk9onRJigV4u9 zs+MkcWzTEUIaAj6cdK25LjoYgdHImd8nXWYgBHHKuyqQQ+35PFRM1K6ipwFfPrggUe7 UnmoJqJlUokrh9dqGNmdFMOEcSlnA/fVF5P4I5zHlxvCCqiXSspmiNpSbCduAME7sPyf APGJZEpilqifRE8JhnhSoJBQFApR0mTiq1Ve1l/0Ga/57FdKrhIajppEZvBgJuzE8x0H eiWCEnxOphaqy2ZczW6IUtSD+O0Rnn2BWcEznpXfsA4RzfMTP5ORKMa4yE4ao3yB5xIN K1ug== MIME-Version: 1.0 X-Received: by 10.180.73.238 with SMTP id o14mr624583wiv.32.1362094700711; Thu, 28 Feb 2013 15:38:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Thu, 28 Feb 2013 15:38:20 -0800 (PST) Date: Thu, 28 Feb 2013 15:38:20 -0800 X-Google-Sender-Auth: L8RShp7Cp2ReKHc1KA26wGwVV_g Message-ID: Subject: [RFC] replace ic->ic_raw_xmit() calls with a method - ieee80211_raw_xmit() 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, 28 Feb 2013 23:38:22 -0000 Hi, As part of eventually making ic_raw_xmit() go via the vap/ic queue, I'd like to methodise this. Right now the stack calls ic->ic_raw_xmit(ni, mbuf, params) directly. I'd like to stick it inside a method call. Later on the raw frames can be queued via the VAP TX queue and processed in-order. This doesn't (yet) deal with all of the odd locking and serialisation issues; it's just to avoid calling that driver method direct. Comments? Does anyone have a problem with this? Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Sat Mar 2 09:46:36 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 50F16E5F for ; Sat, 2 Mar 2013 09:46:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id C38D8283 for ; Sat, 2 Mar 2013 09:46:35 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id l13so453225wie.0 for ; Sat, 02 Mar 2013 01:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=ubsyw4u9agZs+BmCfOiyBnpYvj0GWtsqiGlO76IfCEY=; b=03G0ecH3hnboAtvPR9kD5/vwFkRDzgyZ9XxNoNRcCPXRoLSm6/o+/9TOtTFtIzb7P0 bIeP0wpoUx1H7RGI0FFnLo3Aa9a87N/ia3+1VRrg7KpI4KPIvutdh/q51fBd1Cf5g5fi MRB3nvIfVP59LR+8cXKki6NfoRJTdnpBbdnlAo4JOuI304IrVKYWWT0Up+rB+J0EUUt5 Eg7QqaWLo5+DHGMuIgsOepxolMURsxOy4zrivOeGARwuTq5DgFUPp+EQ/gqwRQUNyuYg 4YSQHFWW1hhWWhEKldXOPcvUpP9mfQN8nJLl37CeclucLglRlgXzh46A4Sd+Wne0ngS6 TV2Q== MIME-Version: 1.0 X-Received: by 10.180.81.42 with SMTP id w10mr2289616wix.28.1362217594922; Sat, 02 Mar 2013 01:46:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Sat, 2 Mar 2013 01:46:34 -0800 (PST) Date: Sat, 2 Mar 2013 01:46:34 -0800 X-Google-Sender-Auth: ERLnOar5nYnaXr6_giy6NCIKN8U Message-ID: Subject: [RFC] net80211 TX, take 4 (final) 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: Sat, 02 Mar 2013 09:46:36 -0000 Hi, So here's where I'm at: * There's the serialisation of frames that have 802.11 state attached - eg, the encap path for normal VAP TX, for management frame TX, mesh, FF TX, etc; * There's then the serialisation of _dispatching those frames in order to the driver_; * The former will be too hard to serialise via a queue - at least until I get a whole bunch more time and can rewrite all of the different frame TX dispatch bits; * And we don't have an easy way to dispatch frames in order to the underlying driver - all we have is if_transmit() which hands a frame to the driver; it doesn't at all enforce ordering. So what I think I'm going to settle on: Immediate: * Create an IC TX serialisation lock which (for now) serialises both the IC transmission and the VAP TX state; * Grab the IC TX Lock when it's time to encapsulate an 802.3 frame and push it either onto a driver queue (via parent->if_transmit()); * If the driver does deferred transmission (ie, if it calls if_start to drain the parent ifnet queue after TX completion or reset) then it should also grab the IC TX lock too, just to ensure that driver dispatch is done in-order - but this isn't strictly needed, see below. Now, the why: * There's plenty of paths into TX - most notably the various places that create raw management frames to dispatch; * I don't mind that various places are grabbing 802.11 state (ie sequence numbers) and pushing things in-order to the driver - but they're doing it via ic_raw_xmit() rather than via the driver transmit method; * And we have to serialise frames from the point we assign 802.11 encapsulation state all the way through to queuing to the driver - AND the driver has to dequeue/handle these in order; * .. and if_transmit() by itself doesn't give us that. Now, I don't want to invent a new queue method. What I want to do is get this working correct now, and worry about fixing it when I'm at BSDCan and can discuss this with other networking people. What I'd like to do later on, once this is in -HEAD: * I'd like to create a new mbuf tag - that holds "802.11 TX state". This for now will include the TX BPF parameters but it can grow to include other things. * I'd then like to create a way to encapsulate a list of mbuf LISTS - right now the bufring and the mbuf packet lists use m_nextpkt - but net80211 creates fragment lists to pass to the driver by using m_nextpkt. So right now if we TX fragments we silently leak mbufs. It sucks, but that's what I have to deal with. * Next, the VAP transmit path and anything else calling parent->if_transmit() (with what I hope is an encapsulated, in-order frame) should queue mbuf lists into an ic staging queue; * Next, create a single-threaded driver dispatch method - likely a taskqueue for now - that walks the ic staging queue and calls the driver transmit method; * Then I'd like all the places that call ic->ic_raw_xmit() to instead create a new frame and push it into the ic staging queue, maintaining the correct sequence number ordering; * .. and teach the ic dispatch task to call either parent->if_transmit() or ic->ic_raw_xmit() depending upon if the frame was raw or not. * Once that's done, I can unwind that lock back to be per-VAP or per-STA, as now we're not using it as a "driver queue ordering" enforcing lock. _THEN_: * Migrate all wifi drivers to use if_transmit() instead of if_start(), so mbuf lists can be handed to the driver; * I'd like to teach all the wifi drivers about the "802.11 TX state" tag - and if an mbuf appears with the mbuf tag, it's passed through the driver raw method; * .. and then _I can kill ic_raw_xmit() entirely_. What I'd really really like to do: The main shortcoming here is the lack of ordered driver dispatching. Right now we call parent->if_transmit() which will either directly dispatch to the driver or queue via IF_ENQUEUE(), then call if_start()). What I really really want to do here is separate out driver queuing from driver dispatch - I want to hold a VAP or STA TX lock whilst setting up the 802.11 encapsulation and whilst I push it into this queue - and then I want to release the lock and call the driver dispatch routine. The driver is then responsible for dequeuing and handling frames in order. Right now there's no way to guarantee the driver handles things in the right order without holding a lock across calling parent->if_transmit(), which totally sucks. I'll talk with the networking cabal about this as I think they've been thinking about the larger scale requirements for this kind of queue discipline/management. So - with this final plan in mind - what do people think? I think I've got all the basic things down pat. Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Sat Mar 2 11:04:10 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8847CB44 for ; Sat, 2 Mar 2013 11:04:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id 02F5A6C8 for ; Sat, 2 Mar 2013 11:04:09 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm6so370372wib.8 for ; Sat, 02 Mar 2013 03:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Jk2NBxJ8LddS7RB+t488MGL6crrGPJkoPLU4SCe3Ae4=; b=mJbVnoKuKa+Hp2o6SzhMOMTZ60jemtQKk02T+dNYi7Hx+TCcu8ieUX2IREomH3mkn8 sn0riV8fKgBIqBMHu92Cl0Kb2X/WDBnATxL0UxKzDVA5egry6rDMhkRE5WfNnbyj6d0g 1IVvy7ZzHtq00lDsVcbM3jCjUIY4hrPkaDboVS1/VFE5aqjpRVVv8E52HuN7sFib8BYu pochp6nZ6yLHzKxmch+itUa8KLEbBj48yK2Vk1Cl3A6Q4NBQcN/U6C70j+0UPuAZQ5c7 jZr/g9Imytt4eh3LS7EUXokkfJIQARXyEsWAx6zOfusoiC4PAfjU6SW4T04+hXKumLM/ pA5g== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr2469286wib.32.1362222243321; Sat, 02 Mar 2013 03:04:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Sat, 2 Mar 2013 03:04:03 -0800 (PST) In-Reply-To: References: Date: Sat, 2 Mar 2013 03:04:03 -0800 X-Google-Sender-Auth: qpedIwP-4IxzX6CulgYzZ823giE Message-ID: Subject: Re: negotiating HT params at assoc in sta mode From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Sat, 02 Mar 2013 11:04:10 -0000 Did we ever get any consensus on the right thing to do here? :) Adrian