Two fixes intended for the wireless tree. The issue with the .flush() has
been giving me a lot of email from RedHat's bugzilla server. Hope this
patch will silence that ;-)
The other issue was introduced with regulatory changes made by Seth Forshee
as he remove rule for channel 14 upon my review comment, but n_rules field
was not decreased so we got a random rule with bad side-effects.
Cc: Seth Forshee <[email protected]>
Arend van Spriel (2):
brcmsmac: fix mismatch in number of custom regulatory rules
brcmsmac: rework of mac80211 .flush() callback operation
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 2 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 41 +++++++++++++-------
.../net/wireless/brcm80211/brcmsmac/mac80211_if.h | 3 +-
drivers/net/wireless/brcm80211/brcmsmac/main.c | 21 +++-------
drivers/net/wireless/brcm80211/brcmsmac/pub.h | 4 +-
5 files changed, 38 insertions(+), 33 deletions(-)
--
1.7.9.5
On 09/05/2012 11:49 AM, Arend van Spriel wrote:
> Two fixes intended for the wireless tree. The issue with the .flush() has
> been giving me a lot of email from RedHat's bugzilla server. Hope this
> patch will silence that ;-)
Hi John,
I should remove that smile above, but are you planning to take these for
v3.6. At least the first patch is a clear bug fix that I would like
to have applied.
Gr. AvS
>
> Arend van Spriel (2):
> brcmsmac: fix mismatch in number of custom regulatory rules
> brcmsmac: rework of mac80211 .flush() callback operation
>
> drivers/net/wireless/brcm80211/brcmsmac/channel.c | 2 +-
> .../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 41 +++++++++++++-------
> .../net/wireless/brcm80211/brcmsmac/mac80211_if.h | 3 +-
> drivers/net/wireless/brcm80211/brcmsmac/main.c | 21 +++-------
> drivers/net/wireless/brcm80211/brcmsmac/pub.h | 4 +-
> 5 files changed, 38 insertions(+), 33 deletions(-)
>
On 09/05/2012 12:21 PM, Arend van Spriel wrote:
> On 09/05/2012 07:33 PM, Brad Figg wrote:
>> On 09/05/2012 09:57 AM, Seth Forshee wrote:
>>> On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
>>>> This patch addresses a long standing issue of the driver with the
>>>> mac80211 .flush() callback. Since implementing the .flush() callback
>>>> a number of issues have been fixed, but a WARN_ON_ONCE() was still
>>>> triggered because the flush takes too much time. The flush now
>>>> makes use of a waitqueue and still has a timeout on which a warning
>>>> is given.
>>>
>>> Brad Figg and I have been testing this patch with a 3.5 kernel. With the
>>> patch we're both still seeing the warning from brcms_ops_flush(), and
>>> Brad has also seen the "No where to go" message in
>>> brcms_c_prec_enq_head(). But the connection continues to work when this
>>> happens, whereas previously we had to reconnect, so this is definitely
>>> an improvement.
>>>
>>> Seth
>>>
>>
>> Arend,
>>
>> Though the driver is definitely better, it is still struggling quite a
>> bit as can be seen in the iperf output found at:
>> http://pastebin.ubuntu.com/1187578/
>>
>
> Thanks, Brad
>
> I was focusing on the warning in the flush callback. I actually could not reproduce the "nowhere to go" message under my ubuntu test laptop.
>
> The root cause of your problem seems the "nowhere to go". Basically, all packet queues in the driver have reached their limit. In that case packets are simply dropped.
>
> Could you provide following info:
> * cpu info
> * wireless device id
> * scan data of your AP
> * kernel configuration
>
> If I can download the kernel debian package of your 3.5 kernel from somewhere that would be great.
>
> Gr. AvS
>
Arend,
I just filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1046507
which should contain all this information.
If there is _anything_ more I can provide to you or test for you do not
hesitate to ask.
Brad
--
Brad Figg [email protected] http://www.canonical.com
On Wed, Sep 05, 2012 at 12:37:40PM +0200, Arend van Spriel wrote:
> On 09/05/2012 12:20 PM, Stanislaw Gruszka wrote:
> >On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
> >>+ ret = wait_event_timeout(wl->tx_flush_wq,
> >>+ brcms_tx_flush_completed(wl),
> >>+ msecs_to_jiffies(BRCMS_FLUSH_TIMEOUT));
> >>+
> >>+ ieee80211_wake_queues(hw);
> >>+ WARN_ON(!ret);
> >Any particular reason why this WARN_ON is after ieee80211_wake_queues() ?
> >
>
> The wait has a timeout so the warning indicates flush did not
> complete as in the old implementation. Maybe a WARN_ON_ONCE() would
> be better, but I have not observed the warning yet.
Yeah, but I rather asked why it is _after_ ieee80211_wake_queues(),
not before, just after wait_event_timeout().
Not big deal thought, just if something wrong will happen in
ieee80211_wake_queues() order of error prints will be confusing.
Stanislaw
On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
> This patch addresses a long standing issue of the driver with the
> mac80211 .flush() callback. Since implementing the .flush() callback
> a number of issues have been fixed, but a WARN_ON_ONCE() was still
> triggered because the flush takes too much time. The flush now
> makes use of a waitqueue and still has a timeout on which a warning
> is given.
Brad Figg and I have been testing this patch with a 3.5 kernel. With the
patch we're both still seeing the warning from brcms_ops_flush(), and
Brad has also seen the "No where to go" message in
brcms_c_prec_enq_head(). But the connection continues to work when this
happens, whereas previously we had to reconnect, so this is definitely
an improvement.
Seth
On 09/05/2012 09:33 PM, Seth Forshee wrote:
> On Wed, Sep 05, 2012 at 09:21:08PM +0200, Arend van Spriel wrote:
>> If I can download the kernel debian package of your 3.5 kernel from
>> somewhere that would be great.
>
> You can get the debs for the kernel from
> http://people.canonical.com/~sforshee/linux-3.5.0-13.14~lp000000v201209051242/.
>
> Seth
>
>
I see the two brcmsmac patches there. Are those applied to this kernel?
Gr. AvS
On Wed, Sep 05, 2012 at 11:49:21AM +0200, Arend van Spriel wrote:
> The driver provides the cfg80211 regulatory framework with a set of
> custom rules. However, there was a mismatch in number of rules
> and the actual rules provided. This resulted in setting an invalid
> power level:
>
> ieee80211 phy0: brcms_ops_config: change channel 13
> ieee80211 phy0: brcms_ops_config: Error setting power_level (8758364)
>
> Closer look in cfg80211 regulatory blurb showed following bogus rule:
> cfg80211: 0 KHz - -60446948 KHz @ 875836468 KHz), (875836468 mBi, 875836468 mBm)
>
> Cc: Seth Forshee <[email protected]>
> Reviewed-by: Piotr Haber <[email protected]>
> Reviewed-by: Pieter-Paul Giesberts <[email protected]>
> Signed-off-by: Arend van Spriel <[email protected]>
Oddly enough I don't see the bogus rule on my machine. But the fix is
obviously correct.
Reviewed-by: Seth Forshee <[email protected]>
This patch addresses a long standing issue of the driver with the
mac80211 .flush() callback. Since implementing the .flush() callback
a number of issues have been fixed, but a WARN_ON_ONCE() was still
triggered because the flush takes too much time. The flush now
makes use of a waitqueue and still has a timeout on which a warning
is given.
bugzilla: 42840 <https://bugzilla.kernel.org/show_bug.cgi?id=42840>
bugzilla@redhat: <https://bugzilla.redhat.com/show_bug.cgi?id=799168>
bugzilla@redhat: <https://bugzilla.redhat.com/show_bug.cgi?id=787649>
Cc: stable <[email protected]>
Cc: Jonathan Nieder <[email protected]>
Cc: Stanislaw Gruszka <[email protected]>
Cc: Camaleón <[email protected]>
Cc: Milan Bouchet-Valat <[email protected]>
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Hante Meuleman <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 41 +++++++++++++-------
.../net/wireless/brcm80211/brcmsmac/mac80211_if.h | 3 +-
drivers/net/wireless/brcm80211/brcmsmac/main.c | 21 +++-------
drivers/net/wireless/brcm80211/brcmsmac/pub.h | 4 +-
4 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
index a5edebe..56c419b 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
@@ -35,6 +35,7 @@
#include "main.h"
#define N_TX_QUEUES 4 /* #tx queues on mac80211<->driver interface */
+#define BRCMS_FLUSH_TIMEOUT 100 /* msec */
/* Flags we support */
#define MAC_FILTERS (FIF_PROMISC_IN_BSS | \
@@ -693,16 +694,35 @@ static void brcms_ops_rfkill_poll(struct ieee80211_hw *hw)
wiphy_rfkill_set_hw_state(wl->pub->ieee_hw->wiphy, blocked);
}
+static bool brcms_tx_flush_completed(struct brcms_info *wl)
+{
+ bool result;
+
+ spin_lock_bh(&wl->lock);
+ result = brcms_c_tx_flush_completed(wl->wlc);
+ spin_unlock_bh(&wl->lock);
+ return result;
+}
+
static void brcms_ops_flush(struct ieee80211_hw *hw, bool drop)
{
struct brcms_info *wl = hw->priv;
+ int ret;
no_printk("%s: drop = %s\n", __func__, drop ? "true" : "false");
- /* wait for packet queue and dma fifos to run empty */
- spin_lock_bh(&wl->lock);
- brcms_c_wait_for_tx_completion(wl->wlc, drop);
- spin_unlock_bh(&wl->lock);
+ ieee80211_stop_queues(hw);
+ if (drop) {
+ spin_lock_bh(&wl->lock);
+ brcms_c_pktq_flush(wl->wlc);
+ spin_unlock_bh(&wl->lock);
+ }
+ ret = wait_event_timeout(wl->tx_flush_wq,
+ brcms_tx_flush_completed(wl),
+ msecs_to_jiffies(BRCMS_FLUSH_TIMEOUT));
+
+ ieee80211_wake_queues(hw);
+ WARN_ON(!ret);
}
static const struct ieee80211_ops brcms_ops = {
@@ -757,6 +777,7 @@ void brcms_dpc(unsigned long data)
done:
spin_unlock_bh(&wl->lock);
+ wake_up(&wl->tx_flush_wq);
}
/*
@@ -1008,6 +1029,8 @@ static struct brcms_info *brcms_attach(struct bcma_device *pdev)
atomic_set(&wl->callbacks, 0);
+ init_waitqueue_head(&wl->tx_flush_wq);
+
/* setup the bottom half handler */
tasklet_init(&wl->tasklet, brcms_dpc, (unsigned long) wl);
@@ -1594,13 +1617,3 @@ bool brcms_rfkill_set_hw_state(struct brcms_info *wl)
spin_lock_bh(&wl->lock);
return blocked;
}
-
-/*
- * precondition: perimeter lock has been acquired
- */
-void brcms_msleep(struct brcms_info *wl, uint ms)
-{
- spin_unlock_bh(&wl->lock);
- msleep(ms);
- spin_lock_bh(&wl->lock);
-}
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.h b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.h
index 9358bd5..947ccac 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.h
@@ -68,6 +68,8 @@ struct brcms_info {
spinlock_t lock; /* per-device perimeter lock */
spinlock_t isr_lock; /* per-device ISR synchronization lock */
+ /* tx flush */
+ wait_queue_head_t tx_flush_wq;
/* timer related fields */
atomic_t callbacks; /* # outstanding callback functions */
@@ -100,7 +102,6 @@ extern struct brcms_timer *brcms_init_timer(struct brcms_info *wl,
extern void brcms_free_timer(struct brcms_timer *timer);
extern void brcms_add_timer(struct brcms_timer *timer, uint ms, int periodic);
extern bool brcms_del_timer(struct brcms_timer *timer);
-extern void brcms_msleep(struct brcms_info *wl, uint ms);
extern void brcms_dpc(unsigned long data);
extern void brcms_timer(struct brcms_timer *t);
extern void brcms_fatal_error(struct brcms_info *wl);
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 03ca653..ee44126 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -7979,23 +7979,14 @@ int brcms_c_get_curband(struct brcms_c_info *wlc)
return wlc->band->bandunit;
}
-void brcms_c_wait_for_tx_completion(struct brcms_c_info *wlc, bool drop)
+void brcms_c_pktq_flush(struct brcms_c_info *wlc)
{
- int timeout = 20;
-
- /* flush packet queue when requested */
- if (drop)
- brcmu_pktq_flush(&wlc->pkt_queue->q, false, NULL, NULL);
-
- /* wait for queue and DMA fifos to run dry */
- while (!pktq_empty(&wlc->pkt_queue->q) || brcms_txpktpendtot(wlc) > 0) {
- brcms_msleep(wlc->wl, 1);
-
- if (--timeout == 0)
- break;
- }
+ brcmu_pktq_flush(&wlc->pkt_queue->q, false, NULL, NULL);
+}
- WARN_ON_ONCE(timeout == 0);
+bool brcms_c_tx_flush_completed(struct brcms_c_info *wlc)
+{
+ return pktq_empty(&wlc->pkt_queue->q) && !brcms_txpktpendtot(wlc);
}
void brcms_c_set_beacon_listen_interval(struct brcms_c_info *wlc, u8 interval)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/pub.h b/drivers/net/wireless/brcm80211/brcmsmac/pub.h
index 5855f4f..59caa1c 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/pub.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/pub.h
@@ -350,8 +350,6 @@ extern void brcms_c_associate_upd(struct brcms_c_info *wlc, bool state);
extern void brcms_c_scan_start(struct brcms_c_info *wlc);
extern void brcms_c_scan_stop(struct brcms_c_info *wlc);
extern int brcms_c_get_curband(struct brcms_c_info *wlc);
-extern void brcms_c_wait_for_tx_completion(struct brcms_c_info *wlc,
- bool drop);
extern int brcms_c_set_channel(struct brcms_c_info *wlc, u16 channel);
extern int brcms_c_set_rate_limit(struct brcms_c_info *wlc, u16 srl, u16 lrl);
extern void brcms_c_get_current_rateset(struct brcms_c_info *wlc,
@@ -368,5 +366,7 @@ extern int brcms_c_set_tx_power(struct brcms_c_info *wlc, int txpwr);
extern int brcms_c_get_tx_power(struct brcms_c_info *wlc);
extern bool brcms_c_check_radio_disabled(struct brcms_c_info *wlc);
extern void brcms_c_mute(struct brcms_c_info *wlc, bool on);
+extern void brcms_c_pktq_flush(struct brcms_c_info *wlc);
+extern bool brcms_c_tx_flush_completed(struct brcms_c_info *wlc);
#endif /* _BRCM_PUB_H_ */
--
1.7.9.5
On 09/05/2012 09:46 PM, Brad Figg wrote:
> On 09/05/2012 12:21 PM, Arend van Spriel wrote:
>> On 09/05/2012 07:33 PM, Brad Figg wrote:
>>> On 09/05/2012 09:57 AM, Seth Forshee wrote:
>>>> On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
>>>>> This patch addresses a long standing issue of the driver with the
>>>>> mac80211 .flush() callback. Since implementing the .flush() callback
>>>>> a number of issues have been fixed, but a WARN_ON_ONCE() was still
>>>>> triggered because the flush takes too much time. The flush now
>>>>> makes use of a waitqueue and still has a timeout on which a warning
>>>>> is given.
>>>>
>>>> Brad Figg and I have been testing this patch with a 3.5 kernel. With the
>>>> patch we're both still seeing the warning from brcms_ops_flush(), and
>>>> Brad has also seen the "No where to go" message in
>>>> brcms_c_prec_enq_head(). But the connection continues to work when this
>>>> happens, whereas previously we had to reconnect, so this is definitely
>>>> an improvement.
>>>>
>>>> Seth
>>>>
>>>
>>> Arend,
>>>
>>> Though the driver is definitely better, it is still struggling quite a
>>> bit as can be seen in the iperf output found at:
>>> http://pastebin.ubuntu.com/1187578/
>>>
>>
>> Thanks, Brad
>>
>> I was focusing on the warning in the flush callback. I actually could not reproduce the "nowhere to go" message under my ubuntu test laptop.
>>
>> The root cause of your problem seems the "nowhere to go". Basically, all packet queues in the driver have reached their limit. In that case packets are simply dropped.
>>
>> Could you provide following info:
>> * cpu info
>> * wireless device id
>> * scan data of your AP
>> * kernel configuration
>>
>> If I can download the kernel debian package of your 3.5 kernel from somewhere that would be great.
>>
>> Gr. AvS
>>
>
> Arend,
>
> I just filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1046507
> which should contain all this information.
>
> If there is _anything_ more I can provide to you or test for you do not
> hesitate to ask.
I will not (hesitate, that is).
Gr. AvS
On Mon, Sep 10, 2012 at 03:22:30PM +0200, Arend van Spriel wrote:
> On 09/05/2012 11:49 AM, Arend van Spriel wrote:
> >Two fixes intended for the wireless tree. The issue with the .flush() has
> >been giving me a lot of email from RedHat's bugzilla server. Hope this
> >patch will silence that ;-)
>
> Hi John,
>
> I should remove that smile above, but are you planning to take these
> for v3.6. At least the first patch is a clear bug fix that I would
> like
> to have applied.
>
> Gr. AvS
Arend,
I held-off on these because of the continuing discussion...
I definitely 'feel your pain' re: Red Hat bugzilla and the second
patch. But I'm not sure it meets either the 'small' or 'obvious'
tests, so I would prefer to leave it out for now. I'll take the
first one now.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On 09/10/2012 08:33 PM, John W. Linville wrote:
> On Mon, Sep 10, 2012 at 03:22:30PM +0200, Arend van Spriel wrote:
>> On 09/05/2012 11:49 AM, Arend van Spriel wrote:
>>> Two fixes intended for the wireless tree. The issue with the .flush() has
>>> been giving me a lot of email from RedHat's bugzilla server. Hope this
>>> patch will silence that ;-)
>>
>> Hi John,
>>
>> I should remove that smile above, but are you planning to take these
>> for v3.6. At least the first patch is a clear bug fix that I would
>> like
>> to have applied.
>>
>> Gr. AvS
>
> Arend,
>
> I held-off on these because of the continuing discussion...
Understood.
> I definitely 'feel your pain' re: Red Hat bugzilla and the second
> patch. But I'm not sure it meets either the 'small' or 'obvious'
> tests, so I would prefer to leave it out for now. I'll take the
> first one now.
Thanks. I wanted to make sure the first patch got in. While the second
improves the runtime behavior, it does not address the root cause
(whatever that is) so I agree to keep it out until I hammer it down.
> Thanks,
>
> John
>
Gr. AvS
On 09/05/2012 07:33 PM, Brad Figg wrote:
> On 09/05/2012 09:57 AM, Seth Forshee wrote:
>> On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
>>> This patch addresses a long standing issue of the driver with the
>>> mac80211 .flush() callback. Since implementing the .flush() callback
>>> a number of issues have been fixed, but a WARN_ON_ONCE() was still
>>> triggered because the flush takes too much time. The flush now
>>> makes use of a waitqueue and still has a timeout on which a warning
>>> is given.
>>
>> Brad Figg and I have been testing this patch with a 3.5 kernel. With the
>> patch we're both still seeing the warning from brcms_ops_flush(), and
>> Brad has also seen the "No where to go" message in
>> brcms_c_prec_enq_head(). But the connection continues to work when this
>> happens, whereas previously we had to reconnect, so this is definitely
>> an improvement.
>>
>> Seth
>>
>
> Arend,
>
> Though the driver is definitely better, it is still struggling quite a
> bit as can be seen in the iperf output found at:
> http://pastebin.ubuntu.com/1187578/
>
Thanks, Brad
I was focusing on the warning in the flush callback. I actually could
not reproduce the "nowhere to go" message under my ubuntu test laptop.
The root cause of your problem seems the "nowhere to go". Basically, all
packet queues in the driver have reached their limit. In that case
packets are simply dropped.
Could you provide following info:
* cpu info
* wireless device id
* scan data of your AP
* kernel configuration
If I can download the kernel debian package of your 3.5 kernel from
somewhere that would be great.
Gr. AvS
On 09/05/2012 12:20 PM, Stanislaw Gruszka wrote:
> On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
>> + ret = wait_event_timeout(wl->tx_flush_wq,
>> + brcms_tx_flush_completed(wl),
>> + msecs_to_jiffies(BRCMS_FLUSH_TIMEOUT));
>> +
>> + ieee80211_wake_queues(hw);
>> + WARN_ON(!ret);
> Any particular reason why this WARN_ON is after ieee80211_wake_queues() ?
>
The wait has a timeout so the warning indicates flush did not complete
as in the old implementation. Maybe a WARN_ON_ONCE() would be better,
but I have not observed the warning yet.
Gr. AvS
On Wed, Sep 05, 2012 at 09:21:08PM +0200, Arend van Spriel wrote:
> If I can download the kernel debian package of your 3.5 kernel from
> somewhere that would be great.
You can get the debs for the kernel from
http://people.canonical.com/~sforshee/linux-3.5.0-13.14~lp000000v201209051242/.
Seth
On Wed, Sep 05, 2012 at 10:00:55PM +0200, Arend van Spriel wrote:
> On 09/05/2012 09:33 PM, Seth Forshee wrote:
> >On Wed, Sep 05, 2012 at 09:21:08PM +0200, Arend van Spriel wrote:
> >>If I can download the kernel debian package of your 3.5 kernel from
> >>somewhere that would be great.
> >
> >You can get the debs for the kernel from
> >http://people.canonical.com/~sforshee/linux-3.5.0-13.14~lp000000v201209051242/.
> >
> >Seth
> >
> >
>
> I see the two brcmsmac patches there. Are those applied to this kernel?
Yes, they are applied to that build. Otherwise it is our stock kernel
for Ubuntu 12.10.
On 09/05/2012 09:57 AM, Seth Forshee wrote:
> On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
>> This patch addresses a long standing issue of the driver with the
>> mac80211 .flush() callback. Since implementing the .flush() callback
>> a number of issues have been fixed, but a WARN_ON_ONCE() was still
>> triggered because the flush takes too much time. The flush now
>> makes use of a waitqueue and still has a timeout on which a warning
>> is given.
>
> Brad Figg and I have been testing this patch with a 3.5 kernel. With the
> patch we're both still seeing the warning from brcms_ops_flush(), and
> Brad has also seen the "No where to go" message in
> brcms_c_prec_enq_head(). But the connection continues to work when this
> happens, whereas previously we had to reconnect, so this is definitely
> an improvement.
>
> Seth
>
Arend,
Though the driver is definitely better, it is still struggling quite a
bit as can be seen in the iperf output found at:
http://pastebin.ubuntu.com/1187578/
--
Brad Figg [email protected] http://www.canonical.com
On Wed, Sep 05, 2012 at 11:49:22AM +0200, Arend van Spriel wrote:
> + ret = wait_event_timeout(wl->tx_flush_wq,
> + brcms_tx_flush_completed(wl),
> + msecs_to_jiffies(BRCMS_FLUSH_TIMEOUT));
> +
> + ieee80211_wake_queues(hw);
> + WARN_ON(!ret);
Any particular reason why this WARN_ON is after ieee80211_wake_queues() ?
Stanislaw
The driver provides the cfg80211 regulatory framework with a set of
custom rules. However, there was a mismatch in number of rules
and the actual rules provided. This resulted in setting an invalid
power level:
ieee80211 phy0: brcms_ops_config: change channel 13
ieee80211 phy0: brcms_ops_config: Error setting power_level (8758364)
Closer look in cfg80211 regulatory blurb showed following bogus rule:
cfg80211: 0 KHz - -60446948 KHz @ 875836468 KHz), (875836468 mBi, 875836468 mBm)
Cc: Seth Forshee <[email protected]>
Reviewed-by: Piotr Haber <[email protected]>
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/channel.c b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
index 7ed7d75..64a48f0 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/channel.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
@@ -77,7 +77,7 @@
NL80211_RRF_NO_IBSS)
static const struct ieee80211_regdomain brcms_regdom_x2 = {
- .n_reg_rules = 7,
+ .n_reg_rules = 6,
.alpha2 = "X2",
.reg_rules = {
BRCM_2GHZ_2412_2462,
--
1.7.9.5