* cfg80211 rfkill interface
From: Arend Van Spriel @ 2011-01-10 19:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
Hi Johannes,
I am looking into implementing rfkill into our brcm80211 open-source driver. Our driver detects disable switch by an interrupt, but switching back does not give an interrupt. For the latter I wanted to use the rfkill_poll callback and wiphy_rfkill_start_polling. However, I tried a wiphy_rfkill_stop_polling in the rfkill_poll callback when rf is unblocked, and this resulted in a system hang. So I moved the wiphy_rfkill_stop_polling to the start callback. Does that make sense or is there another way you would recommend?
Gr. AvS
^ permalink raw reply
* Re: cfg80211 rfkill interface
From: Johannes Berg @ 2011-01-10 19:45 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <400C43189542CE41BC0A5B252FC90136952F059529@SJEXCHCCR02.corp.ad.broadcom.com>
Hi Arend,
> I am looking into implementing rfkill into our brcm80211 open-source
> driver. Our driver detects disable switch by an interrupt, but
> switching back does not give an interrupt.
Interesting, but I guess it makes some sense.
> For the latter I wanted to use the rfkill_poll callback and
> wiphy_rfkill_start_polling.
Right, makes sense.
> However, I tried a wiphy_rfkill_stop_polling in the rfkill_poll
> callback when rf is unblocked, and this resulted in a system hang.
Yeah, I'm not surprised. start_polling will work from anywhere, but
stop_polling needs to actually completely sync the poll stop so it can't
be done from within the poll or from within any rfkill callbacks.
> So I moved the wiphy_rfkill_stop_polling to the start callback. Does
> that make sense or is there another way you would recommend?
I think that makes sense.
However, where do you start polling? You have to poll even if the device
is not start()ed, I guess?
johannes
^ permalink raw reply
* RE: [PATCH] mwifiex: remove linked list implementation
From: Bing Zhao @ 2011-01-10 19:51 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, John W. Linville,
Amitkumar Karwar, Kiran Divekar, Frank Huang
In-Reply-To: <1294566437.5345.1.camel@jlt3.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGlu
dXgtd2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtd2lyZWxlc3Mt
b3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YNCj4gSm9oYW5uZXMgQmVyZw0KPiBT
ZW50OiBTdW5kYXksIEphbnVhcnkgMDksIDIwMTEgMTo0NyBBTQ0KPiBUbzogQmluZyBaaGFvDQo+
IENjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IEpvaG4gVy4gTGludmlsbGU7IEFt
aXRrdW1hciBLYXJ3YXI7IEtpcmFuIERpdmVrYXI7IEZyYW5rIEh1YW5nDQo+IFN1YmplY3Q6IFJl
OiBbUEFUQ0hdIG13aWZpZXg6IHJlbW92ZSBsaW5rZWQgbGlzdCBpbXBsZW1lbnRhdGlvbg0KPiAN
Cj4gT24gRnJpLCAyMDExLTAxLTA3IGF0IDE3OjEwIC0wODAwLCBCaW5nIFpoYW8gd3JvdGU6DQo+
IA0KPiA+ICsJdHhfYmFfdHNyX3RibCA9IChzdHJ1Y3QgbXdpZmlleF90eF9iYV9zdHJlYW1fdGJs
ICopDQo+ID4gKwkJCQkJcHJpdi0+dHhfYmFfc3RyZWFtX3RibF9wdHIubmV4dDsNCj4gDQo+IERv
bid0IGRvIHRoYXQuIEFsd2F5cyB1c2UgbGlzdF9maXJzdF9lbnRyeSgpIGV0YywgYmVjYXVzZSBv
dGhlcndpc2UgdGhlDQo+IHN0cnVjdCBsaXN0X2hlYWQgbXVzdCBiZSB0aGUgZmlyc3QgbWVtYmVy
IGluIHRoZSBzdHJ1Y3QsIHdoaWNoIGlzIHZlcnkNCj4gbm9uLWlkZW9tYXRpYyBhbmQgZXZlcnli
b2R5IHdobyBpcyB1c2VkIHRvIHRoZSBrZXJuZWwgd2lsbCBnZXQgaXQgd3JvbmcNCj4gd2hlbiBt
b2RpZnlpbmcgeW91ciBkcml2ZXIuDQo+IA0KPiBUcmVhdCBzdHJ1Y3QgbGlzdF9oZWFkIGFzIGNv
bXBsZXRlbHkgb3BhcXVlIC0tIG5ldmVyIGxvb2sgaW50byBpdC4gVGhlcmUNCj4gYXJlIG1hY3Jv
cyBmb3IgYW55IGtpbmQgb2YgbWFuaXB1bGF0aW9uIHdpdGggaXQuDQo+IA0KPiBBbHNvLCBhbGwg
eW91ciBsb29wcyBhcmUgb3BlbiBjb2RlZCAtLSB1c2UgbGlzdF9mb3JfZWFjaF9lbnRyeSgpIGlu
c3RlYWQNCj4gb2YgZG9pbmcgdGhhdCAoZXZlbiB0aGUgY29kZSBJIHF1b3RlZCBhYm92ZSBpcyBm
cm9tIGFuIG9wZW4gY29kZWQgbG9vcCkNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBXZSB3
aWxsIG1ha2UgY2hhbmdlcyBhbmQgcmVzZW5kIHRoZSBwYXRjaC4NCg0KUmVnYXJkcywNCg0KQmlu
Zw0KDQo+IA0KPiBqb2hhbm5lcw0KPiANCj4gLS0NCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlz
IGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LXdpcmVsZXNzIiBpbg0KPiB0
aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0KPiBNb3Jl
IG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZv
Lmh0bWwNCg==
^ permalink raw reply
* Compat-wireless release for 2011-01-10 is baked
From: Compat-wireless cronjob account @ 2011-01-10 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
d184f08..2a4c30d history -> origin/history
+ f69eb67...4c897f2 master -> origin/master (forced update)
cb600d2..0c21e3a stable -> origin/stable
* [new tag] next-20110110 -> next-20110110
compat-wireless code metrics
782479 - Total upstream lines of code being pulled
2103 - backport code changes
1843 - backport code additions
260 - backport code deletions
7279 - backport from compat module
9382 - total backport code
1.1990 - % of code consists of backport work
1531 - Crap changes not yet posted
1488 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1957 - % of crap code
Base tree: linux-next.git
Base tree version: next-20110110
compat-wireless release: compat-wireless-2011-01-06-pc
^ permalink raw reply
* [Bug 24592] Re: 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2011-01-10 20:09 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, maciej.rutecki, florian, akpm, torvalds,
kernel-testers, netdev, linux-acpi, linux-pm, linux-scsi,
linux-wireless, dri-devel
In-Reply-To: <20110110.000813.173856001.davem@davemloft.net>
On Monday, January 10, 2011, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET)
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
> > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
> > Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
> > Date : 2010-12-08 21:09 (22 days old)
>
> This bug is intended to be fixed by:
>
> commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb
> Author: David S. Miller <davem@davemloft.net>
> Date: Wed Jan 5 15:38:53 2011 -0800
>
> af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks.
>
> unix_release() can asynchornously set socket->sk to NULL, and
> it does so without holding the unix_state_lock() on "other"
> during stream connects.
>
> However, the reverse mapping, sk->sk_socket, is only transitioned
> to NULL under the unix_state_lock().
>
> Therefore make the security hooks follow the reverse mapping instead
> of the forward mapping.
>
> Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2011-01-10 20:11 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, maciej.rutecki, florian, akpm, torvalds,
kernel-testers, netdev, linux-acpi, linux-pm, linux-scsi,
linux-wireless, dri-devel
In-Reply-To: <20110110.000813.173856001.davem@davemloft.net>
On Monday, January 10, 2011, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET)
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
> > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
> > Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
> > Date : 2010-12-08 21:09 (22 days old)
> > Message-ID : <4CFFF3F3.90100@goop.org>
> > References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
>
> This bug is intended to be fixed by:
>
> commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb
> Author: David S. Miller <davem@davemloft.net>
> Date: Wed Jan 5 15:38:53 2011 -0800
>
> af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks.
>
> unix_release() can asynchornously set socket->sk to NULL, and
> it does so without holding the unix_state_lock() on "other"
> during stream connects.
>
> However, the reverse mapping, sk->sk_socket, is only transitioned
> to NULL under the unix_state_lock().
>
> Therefore make the security hooks follow the reverse mapping instead
> of the forward mapping.
>
> Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
OK, thanks for the info, closing.
Rafael
^ permalink raw reply
* ath9k_hw_check_alive routine
From: Bill Jordan @ 2011-01-10 20:23 UTC (permalink / raw)
To: linux-wireless, ath9k-devel, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian
This routine is failing a lot on my AR9160. The ((reg & 0x7E7FFFEF) ==
0x00702400) test is the one that always fails. There is no debug
messages in this path, so it may not be obvious whether others are
experiencing the problem.
This forces ath9k_tasklet to reset the hardware. If I increase the
count to 500, I can eliminate most of the resets, so the hardware
isn't really hung. However, it sometimes takes over 25 milliseconds
before the test condition passes.
I don't have specs for the radio, and the numeric constants aren't
very useful, so I can't tell what condition we are waiting for or why.
Can someone with a spec shed some light on this problem?
bool ath9k_hw_check_alive(struct ath_hw *ah)
{
int count = 50;
u32 reg;
if (AR_SREV_9285_10_OR_LATER(ah))
return true;
do {
reg = REG_READ(ah, AR_OBS_BUS_1);
if ((reg & 0x7E7FFFEF) == 0x00702400)
continue;
switch (reg & 0x7E000B00) {
case 0x1E000000:
case 0x52000B00:
case 0x18000B00:
continue;
default:
return true;
}
} while (count-- > 0);
return false;
}
Thanks,
Bill Jordan
^ permalink raw reply
* [PATCH] wl12xx: reset 5ghz num channels on hw init
From: Arik Nemtsov @ 2011-01-10 21:04 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho, Arik Nemtsov
The number of 5ghz channels is set to 0 when 11a is not supported in the
NVS file. When a single rmmod/insmod of wl12xx_sdio this leads to a
supported band (5ghz) with 0 supported channels, which mac80211
considers illegal.
Fix this by always resetting the number of supported 5ghz channels
before the HW is registered.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
drivers/net/wireless/wl12xx/main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 062247e..44cdefd 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2679,6 +2679,10 @@ int wl1271_init_ieee80211(struct wl1271 *wl)
wl->hw->wiphy->bands[IEEE80211_BAND_2GHZ] = &wl1271_band_2ghz;
wl->hw->wiphy->bands[IEEE80211_BAND_5GHZ] = &wl1271_band_5ghz;
+ /* reset the number of channels as this can be changed at runtime */
+ wl->hw->wiphy->bands[IEEE80211_BAND_5GHZ]->n_channels =
+ ARRAY_SIZE(wl1271_channels_5ghz);
+
wl->hw->queues = 4;
wl->hw->max_rates = 1;
--
1.7.1
^ permalink raw reply related
* Re: Kernel 2.6.37-rc5 rc7 Oops
From: Gertjan van Wingerde @ 2011-01-10 21:08 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, torvalds, alex.arnautu96, linux-kernel,
linux-wireless
In-Reply-To: <20110110.000650.124002380.davem@davemloft.net>
On 01/10/11 09:06, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 29 Dec 2010 21:02:45 +0100
>
>> Le mercredi 29 décembre 2010 à 11:23 -0800, Linus Torvalds a écrit :
>>> On Wed, Dec 29, 2010 at 4:26 AM, Alex Arnautu <alex.arnautu96@gmail.com> wrote:
>>>>
>>>> I get an oops with 2.6.37-rc5 and 2.6.37-rc7-git1.
>>>> http://www.fotoshack.us/fotos/19044P271210_15.14_[01].jpg
>>>
>>> Hmm. Davem added to the list of people involved. This _may_ be fixed
>>> by the "always clone skbs" commit in -rc8 (commit 173021072), but
>>> David can make a better judgment call.
>>>
>>
>> Very unlikely, as commit 173021072 only fix a bug in case mirred is
>> used.
>
> This should be taken to the wireless list (now CC:'d) as the rt2xxx
> driver and the wireless stack are both in that backtrace.
Hmmm, the jpg images of the oops don't seem to be available anymore
(a 404 not found is returned on the URL.
Does anybody still have the backtrace? Otherwise it will be very hard to look
into this.
---
Gertjan.
^ permalink raw reply
* Re: Kernel 2.6.37-rc5 rc7 Oops
From: David Miller @ 2011-01-10 21:12 UTC (permalink / raw)
To: gwingerde
Cc: eric.dumazet, torvalds, alex.arnautu96, linux-kernel,
linux-wireless
In-Reply-To: <4D2B7550.5000008@gmail.com>
From: Gertjan van Wingerde <gwingerde@gmail.com>
Date: Mon, 10 Jan 2011 22:08:32 +0100
> On 01/10/11 09:06, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Wed, 29 Dec 2010 21:02:45 +0100
>>
>>> Le mercredi 29 décembre 2010 à 11:23 -0800, Linus Torvalds a écrit :
>>>> On Wed, Dec 29, 2010 at 4:26 AM, Alex Arnautu <alex.arnautu96@gmail.com> wrote:
>>>>>
>>>>> I get an oops with 2.6.37-rc5 and 2.6.37-rc7-git1.
>>>>> http://www.fotoshack.us/fotos/19044P271210_15.14_[01].jpg
>>>>
>>>> Hmm. Davem added to the list of people involved. This _may_ be fixed
>>>> by the "always clone skbs" commit in -rc8 (commit 173021072), but
>>>> David can make a better judgment call.
>>>>
>>>
>>> Very unlikely, as commit 173021072 only fix a bug in case mirred is
>>> used.
>>
>> This should be taken to the wireless list (now CC:'d) as the rt2xxx
>> driver and the wireless stack are both in that backtrace.
>
> Hmmm, the jpg images of the oops don't seem to be available anymore
> (a 404 not found is returned on the URL.
> Does anybody still have the backtrace? Otherwise it will be very hard to look
> into this.
You must have copy-and-paste'd it wrong, the URL works perfectly fine
for me.
I also put up a copy at:
http://vger.kernel.org/~davem/crash.jpg
^ permalink raw reply
* carl9170: RX and TX interrupt callback ?
From: Chris Pechard @ 2011-01-10 21:24 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20101201211128.GC16125@vigoh>
I am trying to do time measurement using carl9170 firmware side. There was some
interesting previous thread about clock to be used and location of the probe in
the code. My goal is to get a precise time from the moment a packet has been
transmitted (timestamp when the packet has been transmitted) and the arrival of
the next received packet (time when a packet has been fully received). Looking
though the code, there is a loop in src/main.c handling the TX/RX interrupt by
reading the AR9170_MAC_REG_INT_CTRL register and checking the
AR9170_MAC_INT_TXC/RXC bits. Pending on task to be performed in the loop, it
could take tens of microseconds to go through one iteration which affects the
measurement and resulting in having RXC timestamp smaller than TXC timestamp
which is clearly an issue !
My current workaround is to add many check to AR9170_MAC_REG_INT_CTRL in the
main loop to reduce the detection latency which at least gave me better results
(TXC time < RXC time ) but somehow it does not seem AR9170_MAC_REG_INT_CTRL
register is refreshed right away when a packet is received or transmitted. I
would like to know if there is any way to attach a callback function to the RXC
or TXC interrupt so that we get immediate notification instead of depending on
a polling method. If not, is there any way to minimize delays between the time
a packet is sent/received and the TXC/RXC bit flag raised in the register ?
Thanks,
Chris.
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Jamie Kitson @ 2011-01-10 21:35 UTC (permalink / raw)
To: Brett Rudley; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimERVKAz90zPa8e_gikAf3e4G8nwjHHYrK9qsFT@mail.gmail.com>
I don't know if it makes any difference but I tried again, this time
with a 2.6.37 kernel and got a slightly different error (almost
immediately x started, I guess when wireless was coming up):
http://farm6.static.flickr.com/5246/5343639268_88ee4da55e_b.jpg
^ permalink raw reply
* Re: RTL8187L: Can only "enable" hw radio switch after Windows boot
From: Klaas De Craemer @ 2011-01-10 21:49 UTC (permalink / raw)
To: htl10; +Cc: Larry Finger, linux-wireless, Herton Ronaldo Krzesinski
In-Reply-To: <801634.53195.qm@web29514.mail.ird.yahoo.com>
On Mon, Jan 10, 2011 at 20:10, Hin-Tak Leung
<htl10@users.sourceforge.net> wrote:
> --- On Mon, 10/1/11, Klaas De Craemer <klaasdc@gmail.com> wrote:
>
>> Hello all,
>>
>> I can add to this that the rtl8187 driver seems to perform
>> worse then
>> its Windows counterpart (for this device anyway). Today,
>> the Linux
>> driver could not even connect anymore to the AP. Issuing
>> "iwconfig
>> wlan0 apname" just doesn't do anything. I could connect to
>> another,
>> more closer AP in Linux however.
>> I'm very annoyed to announce that, despite the loss in
>> flexibility, we
>> will be moving this box to Windows because the wireless
>> connection
>> then "just works".
>> I'll still check the list and I will remain available to
>> test anything
>> that could help the Linux driver though.
>
> I would suggest you having a go at studying the windows driver under ndiswrapper, and using the kernel debugfs to study how the windows driver communicate with the device via USB and compared that with what the native driver is doing. That was how I got to be associated with the native driver - spotting what it was doing wrong/different from how the vendor linux driver was doing; the same should work with ndiswrapper+windows driver. (it did for a little bit, from personal experience).
>
> There is no magic to it - if you want the driver to work for you, you can spend some time on it. You know the windows driver works "better" (for you), and there is a way to study the windows driver via ndiswrapper and compared that with the native driver, so it is do-able, just time and patience.
>
> AFAIK, none of us have any special secret knowledge about the RTL8187L, much beyond what's publicly avaialable - i.e. the Realtek "official" driver code and a few spec sheets, and studying the windows driver via ndiswrapper; and AFAIK none of us are paid to work on the Realtek driver - Herton probably are paid to work on linux-things (given the e-mail address) but presumably not specifically on any one driver; I just happened to own a laptop with such a device built-in and Larry seems to be more or less of the same situation.
>
> P.S. I am annoyed by the "I am very annoyed..." part of your e-mail message.
>
My apologies if it sounded that negative. What I meant was that I
enjoy using Linux and that it now bothers me to have to put windows on
something like this. I'm still glad that people like you, Larry and
Herton are willing to put so much effort in developing drivers.
Klaas
>
>
>
^ permalink raw reply
* Re: carl9170: RX and TX interrupt callback ?
From: Christian Lamparter @ 2011-01-10 22:39 UTC (permalink / raw)
To: Chris Pechard; +Cc: linux-wireless
In-Reply-To: <907295.15255.qm@web120203.mail.ne1.yahoo.com>
On Monday 10 January 2011 22:24:18 Chris Pechard wrote:
> I am trying to do time measurement using carl9170 firmware side. There was some
> interesting previous thread about clock to be used and location of the probe in
> the code. My goal is to get a precise time from the moment a packet has been
> transmitted (timestamp when the packet has been transmitted) and the arrival of
> the next received packet (time when a packet has been fully received). Looking
> though the code, there is a loop in src/main.c handling the TX/RX interrupt by
> reading the AR9170_MAC_REG_INT_CTRL register and checking the
> AR9170_MAC_INT_TXC/RXC bits. Pending on task to be performed in the loop, it
> could take tens of microseconds to go through one iteration which affects the
> measurement and resulting in having RXC timestamp smaller than TXC timestamp
> which is clearly an issue!
are you sure, you put the right code in the right place :-D .
I've posted code for the same idea a while ago [on this mailing-list] and I
can't remember anything that weird.
> My current workaround is to add many check to AR9170_MAC_REG_INT_CTRL in the
> main loop to reduce the detection latency which at least gave me better results
> (TXC time < RXC time ) but somehow it does not seem AR9170_MAC_REG_INT_CTRL
> register is refreshed right away when a packet is received or transmitted. I
> would like to know if there is any way to attach a callback function to the RXC
> or TXC interrupt so that we get immediate notification instead of depending on
> a polling method.
Oh it is, or it should be easy to get an interrupt event from the MAC processor.
You just have to look through the SH2 platform docs [which are freely available
from Reneas] and setup the interrupt controller accordingly.
If you're stuck and need advice on the f/irq topic, you should definitely ask
Stephen Chen <Stephen.Chen@atheros.com> for assistance. As he's one of the
few persons who know how it works. I certainly can't...
Good Luck!
> If not, is there any way to minimize delays between the time
> a packet is sent/received and the TXC/RXC bit flag raised in the register?
Don't forget the 802.11 is working against you.
CSMA/CA with R/S/D/P/E/IFS, [random] backoff, dynamic ACK delays and
so much more can really spoil the day, if you are not aware that it's
there.
Furthermore, have you tried to contact the people behind similar projects?
Ignacy Gawedzki <i@lri.fr>
David H. Lynch Jr. <dhlii@dlasys.net>
Especially David, since it seems that he's done with it.
Best Regards,
Chr
PS.: you could also go a different route with OpenFWWF.
^ permalink raw reply
* Re: [PATCH 2.6.35] mac80211: fix hard lockup in sta_addba_resp_timer_expired
From: Jarod Wilson @ 2011-01-10 22:41 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Andi Kleen, stable, Kyle McMartin, kernel, linux-wireless,
Johannes Berg
In-Reply-To: <20110110123808.GA3683@redhat.com>
On Mon, Jan 10, 2011 at 01:38:21PM +0100, Stanislaw Gruszka wrote:
> Problem is 2.6.35 specific, bug was introduced in backport
> of upstream 44271488b91c9eecf249e075a1805dd887e222d2 commit.
>
> We can not call del_timer_sync(addba_resp_timer) from
> ___ieee80211_stop_tx_ba_session(), as this function can be called from
> that timer callback. To fix, simply use not synchronous del_timer().
>
> Resolve https://bugzilla.redhat.com/show_bug.cgi?id=667459
Selfishly merged and committed to the F14 kernel tree, because I think I
may be hitting the same issue once in a while here on my own T61. :)
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: Kernel 2.6.37-rc5 rc7 Oops
From: Gertjan van Wingerde @ 2011-01-10 22:55 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, torvalds, alex.arnautu96, linux-kernel,
linux-wireless
In-Reply-To: <20110110.131257.212413498.davem@davemloft.net>
On 01/10/11 22:12, David Miller wrote:
> From: Gertjan van Wingerde <gwingerde@gmail.com>
> Date: Mon, 10 Jan 2011 22:08:32 +0100
>
>> On 01/10/11 09:06, David Miller wrote:
>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>> Date: Wed, 29 Dec 2010 21:02:45 +0100
>>>
>>>> Le mercredi 29 décembre 2010 à 11:23 -0800, Linus Torvalds a écrit :
>>>>> On Wed, Dec 29, 2010 at 4:26 AM, Alex Arnautu <alex.arnautu96@gmail.com> wrote:
>>>>>>
>>>>>> I get an oops with 2.6.37-rc5 and 2.6.37-rc7-git1.
>>>>>> http://www.fotoshack.us/fotos/19044P271210_15.14_[01].jpg
>>>>>
>>>>> Hmm. Davem added to the list of people involved. This _may_ be fixed
>>>>> by the "always clone skbs" commit in -rc8 (commit 173021072), but
>>>>> David can make a better judgment call.
>>>>>
>>>>
>>>> Very unlikely, as commit 173021072 only fix a bug in case mirred is
>>>> used.
>>>
>>> This should be taken to the wireless list (now CC:'d) as the rt2xxx
>>> driver and the wireless stack are both in that backtrace.
>>
>> Hmmm, the jpg images of the oops don't seem to be available anymore
>> (a 404 not found is returned on the URL.
>> Does anybody still have the backtrace? Otherwise it will be very hard to look
>> into this.
>
> You must have copy-and-paste'd it wrong, the URL works perfectly fine
> for me.
>
> I also put up a copy at:
>
> http://vger.kernel.org/~davem/crash.jpg
>
OK. Got it now. My Unix/Linux twisted mind took the [01] in the file name as a
slick indication that there were two pictures, one with 0 there and one with 1
there. It never occurred to me that it was literally the file name ;-) :-(
Anyway, I wonder if this particular oops is fixed by commit:
20ed3166c84d145589a89d8cde12aa32cf2d17f4 mac80211/rt2x00: add ieee80211_tx_status_ni()
which got into Linus' tree after 2.6.37-rc7 but is part of 2.6.37 final.
It looks a lot like the symptoms that that patch was fixing.
---
Gertjan.
^ permalink raw reply
* packet injection not working on rt2800usb, ath9k
From: Andy Pyles @ 2011-01-10 23:08 UTC (permalink / raw)
To: linux-wireless
I'm using linux-wireless snapshot from December, 2010 with the
following driver: rt2800usb
The linux-wireless snapshot for ath9k is from last summer ( July)
As an example I'm building a program based on:
http://wireless.kernel.org/en/users/Documentation/packetspammer
Steps to test:
( Sender Host A rt2800usb: usbid: Bus 001 Device 002: ID 148f:3070
Ralink Technology, Corp. )
1.) sudo iw phy phy0 interface add moni0 type monitor
2.) sudo iw dev moni0 set channel 11
3.) run packet injector via: pcap_inject()
4.) run tcpdump on moni0 and observe injected packet
( Receiver Host B: 04:02.0 Network controller: Atheros Communications
Inc. AR5008 Wireless Network Adapter (rev 01))
1.) sudo iw phy phy0 interface add moni0 type monitor
2.) sudo iw dev moni0 set channel 11
4.) run tcpdump on moni0 injected packet NOT received.
Sanity test1: When I send a packet from A to B, packet is observed on moni0
Sanity test2: ran standalone packetspammer with no modifications with
the same result.
Question: Is this operation supported on these two devices? If not,
what device can you recommend a device where this does work?
regards,
Andy
^ permalink raw reply
* Re: carl9170: RX and TX interrupt callback ?
From: Chris Pechard @ 2011-01-10 23:36 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201101102339.39965.chunkeey@googlemail.com>
Thanks for the pointers, I will definitively contact the people you listed.
Chris.
----- Original Message ----
From: Christian Lamparter <chunkeey@googlemail.com>
To: Chris Pechard <chrispechard@yahoo.com>
Cc: linux-wireless@vger.kernel.org
Sent: Mon, January 10, 2011 2:39:39 PM
Subject: Re: carl9170: RX and TX interrupt callback ?
On Monday 10 January 2011 22:24:18 Chris Pechard wrote:
> I am trying to do time measurement using carl9170 firmware side. There was some
>
> interesting previous thread about clock to be used and location of the probe in
>
> the code. My goal is to get a precise time from the moment a packet has been
> transmitted (timestamp when the packet has been transmitted) and the arrival of
>
> the next received packet (time when a packet has been fully received). Looking
> though the code, there is a loop in src/main.c handling the TX/RX interrupt by
> reading the AR9170_MAC_REG_INT_CTRL register and checking the
> AR9170_MAC_INT_TXC/RXC bits. Pending on task to be performed in the loop, it
> could take tens of microseconds to go through one iteration which affects the
> measurement and resulting in having RXC timestamp smaller than TXC timestamp
> which is clearly an issue!
are you sure, you put the right code in the right place :-D .
I've posted code for the same idea a while ago [on this mailing-list] and I
can't remember anything that weird.
[CP]: :-) I am measuring the delta between when a packet has left the wireless
interface and the time the next packet is received on the interface. This timing
is much less forgiving than measuring the time when a packet is sent to the TX
queue and TXC or RXC has occurred ( the time difference could be more than
double due to firmware latency, 802.11 medium access and packet transmit time).
That's the reason I am interested in fast TXC notification which would
eliminates some of the random delays.
> My current workaround is to add many check to AR9170_MAC_REG_INT_CTRL in the
> main loop to reduce the detection latency which at least gave me better results
>
> (TXC time < RXC time ) but somehow it does not seem AR9170_MAC_REG_INT_CTRL
> register is refreshed right away when a packet is received or transmitted. I
> would like to know if there is any way to attach a callback function to the
>RXC
>
> or TXC interrupt so that we get immediate notification instead of depending on
>
> a polling method.
Oh it is, or it should be easy to get an interrupt event from the MAC processor.
You just have to look through the SH2 platform docs [which are freely available
from Reneas] and setup the interrupt controller accordingly.
If you're stuck and need advice on the f/irq topic, you should definitely ask
Stephen Chen <Stephen.Chen@atheros.com> for assistance. As he's one of the
few persons who know how it works. I certainly can't...
Good Luck!
> If not, is there any way to minimize delays between the time
> a packet is sent/received and the TXC/RXC bit flag raised in the register?
Don't forget the 802.11 is working against you.
CSMA/CA with R/S/D/P/E/IFS, [random] backoff, dynamic ACK delays and
so much more can really spoil the day, if you are not aware that it's
there.
Furthermore, have you tried to contact the people behind similar projects?
Ignacy Gawedzki <i@lri.fr>
David H. Lynch Jr. <dhlii@dlasys.net>
Especially David, since it seems that he's done with it.
Best Regards,
Chr
PS.: you could also go a different route with OpenFWWF.
^ permalink raw reply
* [PATCH] rt2x00: Don't leak mem in error path of rt2x00lib_request_firmware()
From: Jesper Juhl @ 2011-01-10 23:47 UTC (permalink / raw)
To: linux-wireless
Cc: users, linux-kernel, netdev, Gertjan van Wingerde,
John W. Linville, Ivo van Doorn
We need to release_firmware() in order not to leak memory.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
rt2x00firmware.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rt2x00/rt2x00firmware.c b/drivers/net/wireless/rt2x00/rt2x00firmware.c
index f0e1eb7..be0ff78 100644
--- a/drivers/net/wireless/rt2x00/rt2x00firmware.c
+++ b/drivers/net/wireless/rt2x00/rt2x00firmware.c
@@ -58,6 +58,7 @@ static int rt2x00lib_request_firmware(struct rt2x00_dev *rt2x00dev)
if (!fw || !fw->size || !fw->data) {
ERROR(rt2x00dev, "Failed to read Firmware.\n");
+ release_firmware(fw);
return -ENOENT;
}
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH v5 1/2] wl12xx: BA initiator support
From: Levi, Shahar @ 2011-01-11 0:18 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless@vger.kernel.org, Luciano Coelho
In-Reply-To: <AANLkTi=KnSjVVCN=9=PaL9_GYpDOpJFvD-LGxFXEevhw@mail.gmail.com>
On Tue, Jan 11, 2011 at 2:13 AM, Levi, Shahar <shahar_levi@ti.com> wrote:
>
> On Mon, Jan 10, 2011 at 5:00 PM, Luciano Coelho <coelho@ti.com> wrote:
>>
>> On Mon, 2011-01-03 at 14:42 +0100, Shahar Levi wrote:
>> > Add 80211n BA initiator session support wl1271 driver.
>> > Include BA supported FW version auto detection mechanism.
>> > BA initiator session management included in FW independently.
>> >
>> > Signed-off-by: Shahar Levi <shahar_levi@ti.com>
>> > ---
>>
>> Some comments...
>
thanks for your review.
>>
>>
>> > diff --git a/drivers/net/wireless/wl12xx/acx.c b/drivers/net/wireless/wl12xx/acx.c
>> > index cc4068d..54fd68d 100644
>> > --- a/drivers/net/wireless/wl12xx/acx.c
>> > +++ b/drivers/net/wireless/wl12xx/acx.c
>> > @@ -1309,6 +1309,56 @@ out:
>> > return ret;
>> > }
>> >
>> > +/* Configure BA session initiator\receiver parameters setting in the FW. */
>>
>> Please use forward slash here instead of backslash, ie. use
>> "initiator/receiver".
>
np, will be fix.
>>
>>
>> > diff --git a/drivers/net/wireless/wl12xx/acx.h b/drivers/net/wireless/wl12xx/acx.h
>> > index 9cbc3f4..df48468 100644
>> > --- a/drivers/net/wireless/wl12xx/acx.h
>> > +++ b/drivers/net/wireless/wl12xx/acx.h
>> > @@ -1051,6 +1051,40 @@ struct wl1271_acx_ht_information {
>> > u8 padding[3];
>> > } __packed;
>> >
>> > +#define BA_WIN_SIZE 8
>>
>> Should this be DEFAULT_BA_WIN_SIZE?
>
No, the FW support win size of 8. it is not configurable.
>>
>>
>> > diff --git a/drivers/net/wireless/wl12xx/boot.c b/drivers/net/wireless/wl12xx/boot.c
>> > index 4a9f929..cd42e12 100644
>> > --- a/drivers/net/wireless/wl12xx/boot.c
>> > +++ b/drivers/net/wireless/wl12xx/boot.c
>> > @@ -101,6 +101,39 @@ static void wl1271_boot_set_ecpu_ctrl(struct wl1271 *wl, u32 flag)
>> > wl1271_write32(wl, ACX_REG_ECPU_CONTROL, cpu_ctrl);
>> > }
>> >
>> > +static void wl1271_save_fw_ver(struct wl1271 *wl)
>>
>> This function name is not very informative. Why not call it
>> wl1271_parse_fw_ver() instead?
>
np, will be fix
>>
>>
>> > +{
>> > + char fw_ver_str[ETHTOOL_BUSINFO_LEN];
>>
>> This is weird, but it seem to be what is used in cfg80211 (as Shahar
>> pointed out on IRC). IMHO it should be ETHTOOL_FWVERS_LEN instead, both
>> here and in cfg80211.
>>
>> In any case, this is a bit confusing here, because we don't use the
>> fw_version in the wiphy struct (we probably should). Let's keep it like
>> this for now and maybe later we can change.
>>
>> Also, I don't see why you need a local copy here.
>
i use local copy in order to remove '.' (*fw_ver_point = '\0') without
destroyed wl->chip.fw_ver_str.
>>
>> > + char *fw_ver_point;
>> > + int ret, i;
>> > +
>> > + /* copy the fw version to temp str */
>> > + strncpy(fw_ver_str, wl->chip.fw_ver_str, sizeof(fw_ver_str));
>> > +
>> > + for (i = (WL12XX_NUM_FW_VER - 1); i > 0; --i) {
>> > + /* find the last '.' */
>> > + fw_ver_point = strrchr(fw_ver_str, '.');
>> > +
>> > + /* read version number */
>> > + ret = strict_strtoul(fw_ver_point+1, 10, &(wl->chip.fw_ver[i]));
>> > + if (ret < 0) {
>> > + wl1271_warning("fw version incorrect value");
>> > + memset(wl->chip.fw_ver, 0, sizeof(wl->chip.fw_ver));
>> > + return;
>> > + }
>> > +
>> > + /* clean '.' */
>> > + *fw_ver_point = '\0';
>> > + }
>> > +
>> > + ret = strict_strtoul(fw_ver_point-1, 10, &(wl->chip.fw_ver[0]));
>> > + if (ret < 0) {
>> > + wl1271_warning("fw version incorrect value");
>> > + memset(wl->chip.fw_ver, 0, sizeof(wl->chip.fw_ver));
>> > + return;
>> > + }
>> > +}
>>
>> Instead of all this manual parsing, why don't you use sscanf? I think
>> the following could do the work very nicely:
>>
>> ret = sscanf(wl->chip.fw_ver_str + WL12XX_FW_VER_OFFSET,
>> "%lu.%lu.%lu.%lu.%lu", &wl->chip.fw_ver[0],
>> &wl->chip.fw_ver[1], &wl->chip.fw_ver[2]
>> &wl->chip.fw_ver[3], &wl->chip.fw_ver[4]);
>>
>> Wouldn't something like this be much simpler? (or you could use %u if
>> you agree on using unsigned int, see below)
>
good point, i will try and update.
>>
>>
>> > static int wl1271_boot_upload_firmware_chunk(struct wl1271 *wl, void *buf,
>> > diff --git a/drivers/net/wireless/wl12xx/conf.h b/drivers/net/wireless/wl12xx/conf.h
>> > index a16b361..41df771 100644
>> > --- a/drivers/net/wireless/wl12xx/conf.h
>> > +++ b/drivers/net/wireless/wl12xx/conf.h
>> > @@ -1090,6 +1090,12 @@ struct conf_rf_settings {
>> > u8 tx_per_channel_power_compensation_5[CONF_TX_PWR_COMPENSATION_LEN_5];
>> > };
>> >
>> > +#define CONF_BA_INACTIVITY_TIMEOUT 10000
>>
>> If this is a CONFigurable value, it should be in conf.h and in the
>> configuration parameters in main.c, shouldn't it?
>>
>>
>> > diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
>> > index 062247e..c44462d 100644
>> > --- a/drivers/net/wireless/wl12xx/main.c
>> > +++ b/drivers/net/wireless/wl12xx/main.c
>> > @@ -233,7 +233,7 @@ static struct conf_drv_settings default_conf = {
>> > .avg_weight_rssi_beacon = 20,
>> > .avg_weight_rssi_data = 10,
>> > .avg_weight_snr_beacon = 20,
>> > - .avg_weight_snr_data = 10
>> > + .avg_weight_snr_data = 10,
>> > },
>> > .scan = {
>> > .min_dwell_time_active = 7500,
>> > @@ -252,6 +252,9 @@ static struct conf_drv_settings default_conf = {
>> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> > },
>> > },
>> > + .ht = {
>> > + .inactivity_timeout = CONF_BA_INACTIVITY_TIMEOUT,
>> > + },
>>
>> Ah, I see. You are using that macro here, but I guess you could use the
>> value directly, since this is all configuration stuff, so no need to use
>> defines, unless the values mean something specific. Here it is just a
>> measure of time, so a number can be used directly (like in the
>> min_dwell_time_active).
>
np, will be fix
>>
>>
>> > diff --git a/drivers/net/wireless/wl12xx/wl12xx.h b/drivers/net/wireless/wl12xx/wl12xx.h
>> > index 01711fe..7b34393 100644
>> > --- a/drivers/net/wireless/wl12xx/wl12xx.h
>> > +++ b/drivers/net/wireless/wl12xx/wl12xx.h
>> > @@ -38,6 +38,11 @@
>> > #define DRIVER_NAME "wl1271"
>> > #define DRIVER_PREFIX DRIVER_NAME ": "
>> >
>> > +#define WL12XX_BA_SUPPORT_FW_SUB_VER 339
>> > +#define WL12XX_BA_SUPPORT_FW_COST_VER1 33
>> > +#define WL12XX_BA_SUPPORT_FW_COST_VER2_START 50
>> > +#define WL12XX_BA_SUPPORT_FW_COST_VER2_END 60
>>
>> This defines are very confusing. Can you explain a bit?
yes i will add comments.
>>
>> What about
>> "COST" version 0 (like 6.0.0.0.343), will that branch never support BA?Where do the 50 to 60 come from?
>
no, all open source version will be tag from 50 to 60.
>>
>> And what is 33? This kind of magic
>>
>> should be explained.
>>
>>
>> > @@ -161,10 +166,13 @@ struct wl1271_partition_set {
>> >
>> > struct wl1271;
>> >
>> > +#define WL12XX_NUM_FW_VER 5
>> > +
>>
>> WL12XX_FW_VER_OFFSET sounds better to me.
>>
>> And it shouldn't it be 4,
>> which is the "Rev " prefix?
>
the macro represent the number of numbers in the version. it is not offset.
>>
>>
>> > /* FIXME: I'm not sure about this structure name */
>> > struct wl1271_chip {
>> > u32 id;
>> > - char fw_ver[21];
>> > + char fw_ver_str[ETHTOOL_BUSINFO_LEN];
>> > + unsigned long fw_ver[WL12XX_NUM_FW_VER];
>>
>> Why not unsigned int? (and then use %u.%u... as I mentioned earlier).
>
i will try and update.
>>
>> --
>> Cheers,
>> Luca.
>>
Shahar
^ permalink raw reply
* [PATCH 3/4] ath9k: reinitialize block ack window data when starting aggregation
From: Felix Fietkau @ 2011-01-11 0:05 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez, Felix Fietkau
In-Reply-To: <1294704350-50621-2-git-send-email-nbd@openwrt.org>
There might be some old stale data left, which could confuse tracking
of pending tx frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 6ddba4b..ab4f7b4 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -858,6 +858,9 @@ int ath_tx_aggr_start(struct ath_softc *sc, struct ieee80211_sta *sta,
txtid->paused = true;
*ssn = txtid->seq_start = txtid->seq_next;
+ memset(txtid->tx_buf, 0, sizeof(txtid->tx_buf));
+ txtid->baw_head = txtid->baw_tail = 0;
+
return 0;
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/4] ath9k: fix bogus sequence number increases on aggregation tid flush
From: Felix Fietkau @ 2011-01-11 0:05 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez, Felix Fietkau
When a tid pointer is passed to ath_tx_send_normal(), it increases the
starting sequence number for the next AMPDU action frame, which should
only be done if the sequence number assignment is fresh. In this case
it is clearly not.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 332d1fe..1adfebc 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -169,7 +169,7 @@ static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
ath_tx_update_baw(sc, tid, fi->seqno);
ath_tx_complete_buf(sc, bf, txq, &bf_head, &ts, 0, 0);
} else {
- ath_tx_send_normal(sc, txq, tid, &bf_head);
+ ath_tx_send_normal(sc, txq, NULL, &bf_head);
}
spin_lock_bh(&txq->axq_lock);
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/4] ath9k: fix initial sequence number after starting an ampdu session
From: Felix Fietkau @ 2011-01-11 0:05 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez, Felix Fietkau
In-Reply-To: <1294704350-50621-1-git-send-email-nbd@openwrt.org>
txtid->seq_start may not always be up to date, when there is HT non-AMPDU
traffic just before starting an AMPDU session. Relying on txtid->seq_next
is better, since it is also used to generate the sequence numbers for
all QoS data frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 1adfebc..6ddba4b 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -856,7 +856,7 @@ int ath_tx_aggr_start(struct ath_softc *sc, struct ieee80211_sta *sta,
txtid->state |= AGGR_ADDBA_PROGRESS;
txtid->paused = true;
- *ssn = txtid->seq_start;
+ *ssn = txtid->seq_start = txtid->seq_next;
return 0;
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH 4/4] ath9k: reduce the likelihood of baseband hang check false positives
From: Felix Fietkau @ 2011-01-11 0:05 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez, Felix Fietkau
In-Reply-To: <1294704350-50621-3-git-send-email-nbd@openwrt.org>
Since baseband hangs are rare, but the hang check function has a high
false positive rate in some situations, we need to add more reliable
indicators.
In AP mode we can use blocked beacon transmissions as an indicator,
they should be rare enough.
In station mode, we can skip the hang check entirely, since a true
hang will trigger beacon loss detection, and mac80211 will rescan,
which leads to a hw reset that will bring the hardware back to life.
To make this more reliable, we need to skip fast channel changes
if the hardware appears to be stuck.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/main.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index f90a6ca..c753ba4 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -251,6 +251,9 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
if (!ath_stoprecv(sc))
stopped = false;
+ if (!ath9k_hw_check_alive(ah))
+ stopped = false;
+
/* XXX: do not flush receive queue here. We don't want
* to flush data frames already in queue because of
* changing channel. */
@@ -602,7 +605,15 @@ void ath9k_tasklet(unsigned long data)
spin_lock(&sc->sc_pcu_lock);
- if (!ath9k_hw_check_alive(ah))
+ /*
+ * Only run the baseband hang check if beacons stop working in AP or
+ * IBSS mode, because it has a high false positive rate. For station
+ * mode it should not be necessary, since the upper layers will detect
+ * this through a beacon miss automatically and the following channel
+ * change will trigger a hardware reset anyway
+ */
+ if (ath9k_hw_numtxpending(ah, sc->beacon.beaconq) != 0 &&
+ !ath9k_hw_check_alive(ah))
ieee80211_queue_work(sc->hw, &sc->hw_check_work);
if (ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
--
1.7.3.2
^ permalink raw reply related
* Re: ath9k_hw_check_alive routine
From: Felix Fietkau @ 2011-01-11 0:26 UTC (permalink / raw)
To: Bill Jordan
Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian
In-Reply-To: <AANLkTikj+40TksokdnAKzXnBi7CBE5GO4BEKoaxQG79D@mail.gmail.com>
On 2011-01-10 1:23 PM, Bill Jordan wrote:
> This routine is failing a lot on my AR9160. The ((reg& 0x7E7FFFEF) ==
> 0x00702400) test is the one that always fails. There is no debug
> messages in this path, so it may not be obvious whether others are
> experiencing the problem.
>
> This forces ath9k_tasklet to reset the hardware. If I increase the
> count to 500, I can eliminate most of the resets, so the hardware
> isn't really hung. However, it sometimes takes over 25 milliseconds
> before the test condition passes.
>
> I don't have specs for the radio, and the numeric constants aren't
> very useful, so I can't tell what condition we are waiting for or why.
>
> Can someone with a spec shed some light on this problem?
I just posted a 4-patch series, the last patch of that should take care
of this problem. Please test.
- Felix
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox