* [RFC PATCH 03/17] zd1211rw: fix beacon interval setup
From: Jussi Kivilinna @ 2011-01-04 23:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110104234745.25309.72030.stgit@fate.lan>
Vendor driver uses CR_BNC_INTERVAL at various places, one is HW_EnableBeacon()
that combinies beacon interval with BSS-type flag and DTIM value in upper
16bit of u32. The other one is HW_UpdateBcnInterval() that set_aw_pt_bi()
appears to be based on. HW_UpdateBcnInterval() takes interval argument as u16
and uses that for calculations, set_aw_pt_bi() uses u32 value that has flags
and dtim in upper part. This clearly seems wrong. Also HW_UpdateBcnInterval()
updates only lower 16bit part of CR_BNC_INTERVAL. So make set_aw_pt_bi() do
calculations on only lower u16 part of s->beacon_interval.
Also set 32bit beacon interval register before reading values from device,
as HW_EnableBeacon() on vendor driver does. This is required to make beacon
work on AP-mode, simply reading and then writing updated values is not enough
at least with zd1211b.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/zd1211rw/zd_chip.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
index 6effe18..8c05737 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -848,11 +848,12 @@ static int get_aw_pt_bi(struct zd_chip *chip, struct aw_pt_bi *s)
static int set_aw_pt_bi(struct zd_chip *chip, struct aw_pt_bi *s)
{
struct zd_ioreq32 reqs[3];
+ u16 b_interval = s->beacon_interval & 0xffff;
- if (s->beacon_interval <= 5)
- s->beacon_interval = 5;
- if (s->pre_tbtt < 4 || s->pre_tbtt >= s->beacon_interval)
- s->pre_tbtt = s->beacon_interval - 1;
+ if (b_interval <= 5)
+ b_interval = 5;
+ if (s->pre_tbtt < 4 || s->pre_tbtt >= b_interval)
+ s->pre_tbtt = b_interval - 1;
if (s->atim_wnd_period >= s->pre_tbtt)
s->atim_wnd_period = s->pre_tbtt - 1;
@@ -861,7 +862,7 @@ static int set_aw_pt_bi(struct zd_chip *chip, struct aw_pt_bi *s)
reqs[1].addr = CR_PRE_TBTT;
reqs[1].value = s->pre_tbtt;
reqs[2].addr = CR_BCN_INTERVAL;
- reqs[2].value = s->beacon_interval;
+ reqs[2].value = (s->beacon_interval & ~0xffff) | b_interval;
return zd_iowrite32a_locked(chip, reqs, ARRAY_SIZE(reqs));
}
@@ -873,10 +874,13 @@ static int set_beacon_interval(struct zd_chip *chip, u32 interval)
struct aw_pt_bi s;
ZD_ASSERT(mutex_is_locked(&chip->mutex));
+
+ r = zd_iowrite32_locked(chip, interval, CR_BCN_INTERVAL);
+ if (r)
+ return r;
r = get_aw_pt_bi(chip, &s);
if (r)
return r;
- s.beacon_interval = interval;
return set_aw_pt_bi(chip, &s);
}
^ permalink raw reply related
* [RFC PATCH 02/17] zd1211rw: cancel process_intr work on zd_chip_disable_int()
From: Jussi Kivilinna @ 2011-01-04 23:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110104234745.25309.72030.stgit@fate.lan>
OOPS if worker is running and disconnect() is called (triggered
by unpluging device). Much harder to trigger at this stage but
later when we have AP beacon work in process_intr it happens very
easy.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/zd1211rw/zd_chip.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
index 30f8d40..6effe18 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -1406,6 +1406,9 @@ void zd_chip_disable_int(struct zd_chip *chip)
mutex_lock(&chip->mutex);
zd_usb_disable_int(&chip->usb);
mutex_unlock(&chip->mutex);
+
+ /* cancel pending interrupt work */
+ cancel_work_sync(&zd_chip_to_mac(chip)->process_intr);
}
int zd_chip_enable_rxtx(struct zd_chip *chip)
^ permalink raw reply related
* [RFC PATCH 01/17] zd1211rw: fix tx-queue disabling
From: Jussi Kivilinna @ 2011-01-04 23:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110104234745.25309.72030.stgit@fate.lan>
When stress testing AP-mode I hit OOPS when unpluging or rmmodding
driver.
It appears that when tx-queue is disabled, tx-urbs might be left pending.
These can cause ehci to call non-existing tx_urb_complete() (after rmmod)
or uninitialized/reseted private structure (after disconnect()). Add skb
queue for submitted packets and unlink pending urbs on zd_usb_disable_tx().
Part of the problem seems to be usb->free_urb_list that isn't always
working as it should, causing machine freeze when trying to free the list
in zd_usb_disable_tx(). Caching free urbs isn't what other drivers seem
to be doing (usbnet for example) so strip free_usb_list.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/zd1211rw/zd_usb.c | 113 ++++++++++++++------------------
drivers/net/wireless/zd1211rw/zd_usb.h | 3 -
2 files changed, 51 insertions(+), 65 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 06041cb..ed5379b 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -778,15 +778,34 @@ void zd_usb_disable_rx(struct zd_usb *usb)
void zd_usb_disable_tx(struct zd_usb *usb)
{
struct zd_usb_tx *tx = &usb->tx;
+ struct sk_buff_head *q = &tx->submitted_queue;
+ struct sk_buff *skb, *skbnext;
unsigned long flags;
- struct list_head *pos, *n;
+ int qlen;
spin_lock_irqsave(&tx->lock, flags);
- list_for_each_safe(pos, n, &tx->free_urb_list) {
- list_del(pos);
- usb_free_urb(list_entry(pos, struct urb, urb_list));
- }
tx->enabled = 0;
+ spin_unlock(&tx->lock);
+
+ /* unlink all submitted tx-urbs */
+ spin_lock(&q->lock);
+ skb_queue_walk_safe(q, skb, skbnext) {
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ usb_unlink_urb(info->rate_driver_data[1]);
+ }
+ qlen = skb_queue_len(q);
+ spin_unlock(&q->lock);
+
+ /* wait until unlink has completed */
+ while (qlen > 0) {
+ msleep(20);
+
+ spin_lock(&q->lock);
+ qlen = skb_queue_len(q);
+ spin_unlock(&q->lock);
+ }
+
+ spin_lock(&tx->lock);
tx->submitted_urbs = 0;
/* The stopped state is ignored, relying on ieee80211_wake_queues()
* in a potentionally following zd_usb_enable_tx().
@@ -814,56 +833,6 @@ void zd_usb_enable_tx(struct zd_usb *usb)
spin_unlock_irqrestore(&tx->lock, flags);
}
-/**
- * alloc_tx_urb - provides an tx URB
- * @usb: a &struct zd_usb pointer
- *
- * Allocates a new URB. If possible takes the urb from the free list in
- * usb->tx.
- */
-static struct urb *alloc_tx_urb(struct zd_usb *usb)
-{
- struct zd_usb_tx *tx = &usb->tx;
- unsigned long flags;
- struct list_head *entry;
- struct urb *urb;
-
- spin_lock_irqsave(&tx->lock, flags);
- if (list_empty(&tx->free_urb_list)) {
- urb = usb_alloc_urb(0, GFP_ATOMIC);
- goto out;
- }
- entry = tx->free_urb_list.next;
- list_del(entry);
- urb = list_entry(entry, struct urb, urb_list);
-out:
- spin_unlock_irqrestore(&tx->lock, flags);
- return urb;
-}
-
-/**
- * free_tx_urb - frees a used tx URB
- * @usb: a &struct zd_usb pointer
- * @urb: URB to be freed
- *
- * Frees the transmission URB, which means to put it on the free URB
- * list.
- */
-static void free_tx_urb(struct zd_usb *usb, struct urb *urb)
-{
- struct zd_usb_tx *tx = &usb->tx;
- unsigned long flags;
-
- spin_lock_irqsave(&tx->lock, flags);
- if (!tx->enabled) {
- usb_free_urb(urb);
- goto out;
- }
- list_add(&urb->urb_list, &tx->free_urb_list);
-out:
- spin_unlock_irqrestore(&tx->lock, flags);
-}
-
static void tx_dec_submitted_urbs(struct zd_usb *usb)
{
struct zd_usb_tx *tx = &usb->tx;
@@ -878,7 +847,7 @@ static void tx_dec_submitted_urbs(struct zd_usb *usb)
spin_unlock_irqrestore(&tx->lock, flags);
}
-static void tx_inc_submitted_urbs(struct zd_usb *usb)
+static void tx_inc_submitted_urbs(struct zd_usb *usb, struct urb *urb)
{
struct zd_usb_tx *tx = &usb->tx;
unsigned long flags;
@@ -929,8 +898,9 @@ free_urb:
*/
info = IEEE80211_SKB_CB(skb);
usb = &zd_hw_mac(info->rate_driver_data[0])->chip.usb;
+ skb_unlink(skb, &usb->tx.submitted_queue);
zd_mac_tx_to_dev(skb, urb->status);
- free_tx_urb(usb, urb);
+ usb_free_urb(urb);
tx_dec_submitted_urbs(usb);
return;
resubmit:
@@ -955,11 +925,22 @@ resubmit:
*/
int zd_usb_tx(struct zd_usb *usb, struct sk_buff *skb)
{
- int r;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ int r, enabled;
struct usb_device *udev = zd_usb_to_usbdev(usb);
struct urb *urb;
+ struct zd_usb_tx *tx = &usb->tx;
+ unsigned long flags;
- urb = alloc_tx_urb(usb);
+ spin_lock_irqsave(&tx->lock, flags);
+ enabled = tx->enabled;
+ spin_unlock_irqrestore(&tx->lock, flags);
+ if (!enabled) {
+ r = -ENOENT;
+ goto out;
+ }
+
+ urb = usb_alloc_urb(0, GFP_ATOMIC);
if (!urb) {
r = -ENOMEM;
goto out;
@@ -968,13 +949,18 @@ int zd_usb_tx(struct zd_usb *usb, struct sk_buff *skb)
usb_fill_bulk_urb(urb, udev, usb_sndbulkpipe(udev, EP_DATA_OUT),
skb->data, skb->len, tx_urb_complete, skb);
+ info->rate_driver_data[1] = urb;
+ skb_queue_tail(&tx->submitted_queue, skb);
+
r = usb_submit_urb(urb, GFP_ATOMIC);
- if (r)
+ if (r) {
+ skb_unlink(skb, &tx->submitted_queue);
goto error;
- tx_inc_submitted_urbs(usb);
+ }
+ tx_inc_submitted_urbs(usb, urb);
return 0;
error:
- free_tx_urb(usb, urb);
+ usb_free_urb(urb);
out:
return r;
}
@@ -1007,7 +993,7 @@ static inline void init_usb_tx(struct zd_usb *usb)
spin_lock_init(&tx->lock);
tx->enabled = 0;
tx->stopped = 0;
- INIT_LIST_HEAD(&tx->free_urb_list);
+ skb_queue_head_init(&tx->submitted_queue);
tx->submitted_urbs = 0;
}
@@ -1240,6 +1226,7 @@ static void disconnect(struct usb_interface *intf)
ieee80211_unregister_hw(hw);
/* Just in case something has gone wrong! */
+ zd_usb_disable_tx(usb);
zd_usb_disable_rx(usb);
zd_usb_disable_int(usb);
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.h b/drivers/net/wireless/zd1211rw/zd_usb.h
index 1b1655c..b71baa0 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.h
+++ b/drivers/net/wireless/zd1211rw/zd_usb.h
@@ -185,7 +185,6 @@ struct zd_usb_rx {
/**
* struct zd_usb_tx - structure used for transmitting frames
* @lock: lock for transmission
- * @free_urb_list: list of free URBs, contains all the URBs, which can be used
* @submitted_urbs: atomic integer that counts the URBs having sent to the
* device, which haven't been completed
* @enabled: enabled flag, indicates whether tx is enabled
@@ -193,7 +192,7 @@ struct zd_usb_rx {
*/
struct zd_usb_tx {
spinlock_t lock;
- struct list_head free_urb_list;
+ struct sk_buff_head submitted_queue;
int submitted_urbs;
int enabled;
int stopped;
^ permalink raw reply related
* [RFC PATCH 0/17] zd1211rw: add support for AP mode
From: Jussi Kivilinna @ 2011-01-04 23:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Drake, Ulrich Kunitz
Hello!
This ended up being much bigger task I expected. Anyway AP mode is now
usable and zd1211rw should be less crashy now. I'm still sending this
as RFC as it touches and adds a lot of code.
-Jussi
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Wolfgang Kufner @ 2011-01-04 22:31 UTC (permalink / raw)
To: Aleksandar Milivojevic
Cc: Luis Correia, Luis R. Rodriguez, linux-wireless, users
In-Reply-To: <AANLkTikCcgEiqeJLDn0Pes_2=usj6ZXo7hhL48MBnH_-@mail.gmail.com>
Hi Aleksandar,
I know just about nothing about regulatory domains but I think it
might be good to try with a current compat-wireless next. I notice
that the these log lines:
"cfg80211: Received country IE:"
"cfg80211: We intersect both of these and get:"
do not exist in linux-next anymore since this commit:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=4f366c5dabcb936dd5754a35188bd699181fe1ce
Maybe a fix for this issue is already in compat-wireless.
HTH,
Wolfgang
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2011-01-04 22:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <AANLkTinvrdj4jbzH3COVZ9gW8W0h0em7uD6DBWBEXUp=@mail.gmail.com>
On Tue, Jan 4, 2011 at 10:19 AM, Paul Stewart <pstew@google.com> wrote:
> On Thu, Dec 16, 2010 at 9:44 AM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> Try this:
>
> Happy new year. I've tried this patch, and the system continues to
> suspend and resume successfully (i.e, the fix from the earlier patches
> continues to alleviate the original problem), however the system
> continues to be "deaf" to beacons at resume time if the system
> suspends and resumes while associated. You don't need a ChromeOS
> system to reproduce this issue. Just associate to the network and
> suspend/resume. On resume the system believes it should be
> associated, but then the beacon loss timer kicks in and we
> disassociate, since we are never successful in receiving a response.
Whoops. I didn't apply that change correctly. Actually, I think this
change works. I think I may have spotted a couple of unrelated
anomalies I'll trace down and address separately.
--
Paul
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Aleksandar Milivojevic @ 2011-01-04 21:53 UTC (permalink / raw)
To: Luis Correia; +Cc: Helmut Schaa, linux-wireless, Luis R. Rodriguez, users
In-Reply-To: <AANLkTikREOFV+WGWgo9yh9bTrz346kF0muKE8gs5N+km@mail.gmail.com>
Searching around a bit more, I found an article saying that regulatory
domain in theory could be set from any beacon packet the wireless card
sees (even before it actually connects to any particular wireless
network), not only from beacon packets from my WiFi network. If this
is true (I don't know much about this topic, and even less about
internal workings of regulatory domain support in linux kernel), could
it be possible that one of my neighbors has illegal or misconfigured
AP? This would be a very long shot, as it sounds a bit strange that
regulatory domain could be set based on third network (not the one I'm
connected to), and also I haven't experienced any problems with other
operating systems (such as Mac OS X).
Anyhow, I still find that line in log files about switching regulatory
domain from "US" to "98" (at which point a bunch of frequencies are
permanently dropped) to be rather odd.
On Tue, Jan 4, 2011 at 12:54 PM, Aleksandar Milivojevic
<alex@milivojevic.org> wrote:
> On Tue, Jan 4, 2011 at 11:32 AM, Aleksandar Milivojevic
> <alex@milivojevic.org> wrote:
>>
>> On Tue, Jan 4, 2011 at 11:01 AM, Luis Correia <buga@loide.net> wrote:
>>>
>>> Hi all,
>>>
>>> On Tue, Jan 4, 2011 at 18:46, Helmut Schaa <helmut.schaa@googlemail.com>
>>> wrote:
>>> > Hi Aleksandar,
>>> >
>>> > looks like a somewhat strange regulatory handling. However, I'm not
>>> > really
>>> > familiar with the regulatory stuff. Maybe Luis can give us some
>>> > info/ideas
>>> > regarding this ...
>>> >
>>> > Luis, mind to have a look at the regulatory messages below?
>>> >
>>>
>>> Yes, there is something fishy with it.
>>>
>>> this is what is allowed for Ireland
>>>
>>> country IE:
>>> (2402 - 2482 @ 40), (N/A, 20)
>>> (5170 - 5250 @ 40), (N/A, 20)
>>> (5250 - 5330 @ 40), (N/A, 20), DFS
>>> (5490 - 5710 @ 40), (N/A, 27), DFS
>>>
>>>
>>> Apparently IE Ireland does allow 5Ghz channels, and something is
>>> really strange is going on.
>>>
>>> Maybe if the Airport Extreme was changed to a new channel, it would
>>> improve.
>>>
>>> But I'm not totally sure.
>>>
>>> We might also be looking at an old regulatory daemon or database.
>>
>> The way I read the debug log file was that IE was an empty string (I would
>> expect to see "Received country IE: XX", not "Received country IE:". Also,
>> my regulatory domain is US, not Ireland. I double-checked settings in my
>> Airport Extreme router, and it is correctly set to US there. Looking into
>> the messages log file, it correctly shows country as US as well ("cfg80211:
>> Regulatory domain: US").
>
> Looking at the two log snippets from my original email, I noticed something
> odd.
> The /var/log/messages shows two entries saying "cfg80211: Regulatory domain:
> US", followed by the line saying "cfg80211: Regulatory domain: 98".
> Whatever '98' is and wherever it comes from!? Bottom line, once bunch of
> frequencies are dropped (due to switching to reg. domain '98'), they don't
> seem to be re-added once reg. domain is switched back to US later in the
> logs (I found references on the web saying that framework doesn't allow for
> relaxing of restrictions).
> Searching the web, I found quite a bit of references to similar problems,
> and few hints. Many of the pages I found show similar thing as the one
> found in my log snippets (first setting regulatory domain to correct
> country, then the line setting to "98"). I'll try running stuff like 'iw
> reg get" to see what it reports when I get home later in the evening, and
> also check if there are any config files for passing options (such as
> setting local regulatory domain) for cfg80211 module (and its friends) in
> /etc/modprobe.d directory.
> One minor data point. All the hardware I'm using was purchased new in the
> US in normal retail stores, and used only in US. If there's anything hard
> coded regarding the regulatory domains in the devices themselves (both my
> Apple wireless router and Linksys wireless card), I would expect it to be
> set to US as well. As I wrote previously, my wireless router allows me to
> set country where the device is used, and it is set to US. I'll
> double-check if there's anything in /etc/modprobe.d on the Linux side.
>>>
>>> Luis Correia
>>> > Am Dienstag, 4. Januar 2011 schrieb Aleksandar Milivojevic:
>>> >> I've searched around a bit and haven't found much information that
>>> >> looks
>>> >> like the problem I'm experiencing with rt2x00 drivers.
>>> >>
>>> >> The hardware I have is Linksys WUSB600N USB stick, v1 hardware
>>> >> revision,
>>> >> which should have RT2870 chipset. The kernel used is from a generic
>>> >> Ubuntu
>>> >> 10.10 distribution (uname shows "Linux toporko 2.6.35-24-generic
>>> >> #42-Ubuntu
>>> >> SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux"). The output of lsusb
>>> >> identifies device as:
>>> >>
>>> >> Bus 001 Device 003: ID 1737:0071 Linksys WUSB600N Dual-Band Wireless-N
>>> >> USB
>>> >> Network Adapter
>>> >>
>>> >> The problem I'm experiencing is that I'm able to connect to my AP (an
>>> >> Apple
>>> >> Airport Extreme operating at 5GHZ) shortly after boot. However,
>>> >> shortly
>>> >> after connection is made (usually within few minutes), the connection
>>> >> is
>>> >> dropped, and all subsequent attempts to re-connect to AP fail.
>>> >> Reloading
>>> >> the driver helps to reconnect, but connection is again dropped after
>>> >> few
>>> >> minutes. I also have another AP (an old Linksys WRT54G) operating on
>>> >> 2.4GHz, and it seems same issue is present if I attempt to connect to
>>> >> it
>>> >> (haven't experimented with this other setup much, as I'm much more
>>> >> interested in connecting to my WiFi-N network).
>>> >>
>>> >> The list of relevant loaded drivers on the system shows (looking for
>>> >> anything starting with 'rt' in the name):
>>> >> rt2800usb 8367 0
>>> >> rt2800lib 28897 1 rt2800usb
>>> >> rt2x00usb 9779 2 rt2800usb,rt2800lib
>>> >> rt2x00lib 27275 2 rt2800lib,rt2x00usb
>>> >> led_class 2633 1 rt2x00lib
>>> >> mac80211 231541 2 rt2x00usb,rt2x00lib
>>> >> cfg80211 144470 2 rt2x00lib,mac80211
>>> >>
>>> >> I have rt2870sta driver blacklisted to prevent it from conflicting
>>> >> with
>>> >> rt2x00 drivers.
>>> >>
>>> >> Looking at the log files, it seems /var/log/messages and
>>> >> /var/log/debug
>>> >> contain most interesting logs.
>>> >>
>>> >> I found following snippet in /var/log/messages:
>>> >>
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.143600]
>>> >> ADDRCONF(NETDEV_CHANGE):
>>> >> wlan0: link becomes ready
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.143712] cfg80211: Calling CRDA
>>> >> for
>>> >> country: US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219910] cfg80211: Regulatory
>>> >> domain:
>>> >> US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219914] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219918] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219923] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219928] cfg80211: Regulatory
>>> >> domain:
>>> >> US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219930] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219935] (2402000 KHz -
>>> >> 2472000
>>> >> KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219939] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219943] (5250000 KHz -
>>> >> 5330000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219947] (5490000 KHz -
>>> >> 5600000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219951] (5650000 KHz -
>>> >> 5710000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219955] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219960] cfg80211: Regulatory
>>> >> domain:
>>> >> 98
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219962] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219966] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219971] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220189] cfg80211: Current
>>> >> regulatory
>>> >> domain updated by AP to: US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220192] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220196] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220200] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.409801] padlock: VIA PadLock
>>> >> not
>>> >> detected.
>>> >> Jan 3 10:40:20 toporko kernel: [ 112.656632] lo: Disabled Privacy
>>> >> Extensions
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.593983] cfg80211: Calling CRDA
>>> >> to
>>> >> update world regulatory domain
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625264] cfg80211: World
>>> >> regulatory
>>> >> domain updated:
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625272] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625277] (2402000 KHz -
>>> >> 2472000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625282] (2457000 KHz -
>>> >> 2482000
>>> >> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625286] (2474000 KHz -
>>> >> 2494000
>>> >> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625290] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625294] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >>
>>> >>
>>> >> I also found similar snippet in /var/log/debug. Interestingly, unlike
>>> >> the
>>> >> one above that lists IE as US (which is correct for my location, and
>>> >> corresponds to the settings in my AP), in debug log file IE is
>>> >> strangely
>>> >> blank with bunch of lines about disabled frequencies:
>>> >>
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.114337] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.114955] wlan0: authenticated
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.118103] wlan0: associate with
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.119214] wlan0: RX AssocResp
>>> >> from
>>> >> 00:1e:52:79:e9:ff (capab=0x511 status=0 aid=1)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.119220] wlan0: associated
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219901] cfg80211: Received
>>> >> country
>>> >> IE:
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219925] cfg80211: CRDA thinks
>>> >> this
>>> >> should applied:
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219957] cfg80211: We intersect
>>> >> both
>>> >> of these and get:
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219977] cfg80211: Leaving
>>> >> channel
>>> >> 2412 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219981] cfg80211: Leaving
>>> >> channel
>>> >> 2417 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219985] cfg80211: Leaving
>>> >> channel
>>> >> 2422 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219988] cfg80211: Leaving
>>> >> channel
>>> >> 2427 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219992] cfg80211: Leaving
>>> >> channel
>>> >> 2432 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220044] cfg80211: Leaving
>>> >> channel
>>> >> 2437 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220048] cfg80211: Leaving
>>> >> channel
>>> >> 2442 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220052] cfg80211: Leaving
>>> >> channel
>>> >> 2447 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220056] cfg80211: Leaving
>>> >> channel
>>> >> 2452 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220059] cfg80211: Leaving
>>> >> channel
>>> >> 2457 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220063] cfg80211: Leaving
>>> >> channel
>>> >> 2462 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220066] cfg80211: Leaving
>>> >> channel
>>> >> 2467 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220070] cfg80211: Leaving
>>> >> channel
>>> >> 2472 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220073] cfg80211: Leaving
>>> >> channel
>>> >> 2484 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220078] cfg80211: Disabling
>>> >> channel
>>> >> 5260 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220081] cfg80211: Disabling
>>> >> channel
>>> >> 5270 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220084] cfg80211: Disabling
>>> >> channel
>>> >> 5280 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220087] cfg80211: Disabling
>>> >> channel
>>> >> 5300 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220091] cfg80211: Disabling
>>> >> channel
>>> >> 5310 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220094] cfg80211: Disabling
>>> >> channel
>>> >> 5320 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220097] cfg80211: Disabling
>>> >> channel
>>> >> 5500 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220100] cfg80211: Disabling
>>> >> channel
>>> >> 5510 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220103] cfg80211: Disabling
>>> >> channel
>>> >> 5520 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220106] cfg80211: Disabling
>>> >> channel
>>> >> 5540 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220109] cfg80211: Disabling
>>> >> channel
>>> >> 5550 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220113] cfg80211: Disabling
>>> >> channel
>>> >> 5560 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220116] cfg80211: Disabling
>>> >> channel
>>> >> 5580 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220119] cfg80211: Disabling
>>> >> channel
>>> >> 5590 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220122] cfg80211: Disabling
>>> >> channel
>>> >> 5600 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220125] cfg80211: Disabling
>>> >> channel
>>> >> 5620 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220128] cfg80211: Disabling
>>> >> channel
>>> >> 5630 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220131] cfg80211: Disabling
>>> >> channel
>>> >> 5640 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220135] cfg80211: Disabling
>>> >> channel
>>> >> 5660 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220138] cfg80211: Disabling
>>> >> channel
>>> >> 5670 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220141] cfg80211: Disabling
>>> >> channel
>>> >> 5680 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220144] cfg80211: Disabling
>>> >> channel
>>> >> 5700 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220148] cfg80211: Disabling
>>> >> channel
>>> >> 5835 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220151] cfg80211: Disabling
>>> >> channel
>>> >> 5845 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220154] cfg80211: Disabling
>>> >> channel
>>> >> 5855 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220157] cfg80211: Disabling
>>> >> channel
>>> >> 5865 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220160] cfg80211: Disabling
>>> >> channel
>>> >> 5920 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220163] cfg80211: Disabling
>>> >> channel
>>> >> 5940 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220167] cfg80211: Disabling
>>> >> channel
>>> >> 5960 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220170] cfg80211: Disabling
>>> >> channel
>>> >> 5980 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220173] cfg80211: Disabling
>>> >> channel
>>> >> 6040 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220176] cfg80211: Disabling
>>> >> channel
>>> >> 6060 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220179] cfg80211: Disabling
>>> >> channel
>>> >> 6080 MHz on phy0 due to Country IE
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.564046] No probe response from
>>> >> AP
>>> >> 00:1e:52:79:e9:ff after 500ms, disconnecting.
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.593968] cfg80211: All devices
>>> >> are
>>> >> disconnected, going to restore regulatory settings
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.593977] cfg80211: Restoring
>>> >> regulatory settings
>>> >> Jan 3 10:41:34 toporko kernel: [ 186.856369] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:41:34 toporko kernel: [ 187.056156] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 2)
>>> >> Jan 3 10:41:35 toporko kernel: [ 187.256419] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 3)
>>> >> Jan 3 10:41:35 toporko kernel: [ 187.456054] wlan0: authentication
>>> >> with
>>> >> 00:1e:52:79:e9:ff timed out
>>> >> Jan 3 10:41:47 toporko kernel: [ 200.054031] wlan0: direct probe to
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:41:48 toporko kernel: [ 200.252050] wlan0: direct probe to
>>> >> 00:1e:52:79:e9:ff (try 2)
>>> >> Jan 3 10:41:48 toporko kernel: [ 200.452085] wlan0: direct probe to
>>> >> 00:1e:52:79:e9:ff (try 3)
>>> >
>>> > We received an empty country IE and as a result disabled serveral 11a
>>> > channels.
>>> > Maybe even the one we are currently associated to?
>>> >
>>> > Thanks,
>>> > Helmut
>>> >
>>> > _______________________________________________
>>> > users mailing list
>>> > users@rt2x00.serialmonkey.com
>>> >
>>> > http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
>>> >
>>>
>>> _______________________________________________
>>> users mailing list
>>> users@rt2x00.serialmonkey.com
>>>
>>> http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
>>
>
>
^ permalink raw reply
* Re: Breakage in rtlwifi/base.c for 2010-12-24
From: Larry Finger @ 2011-01-04 21:05 UTC (permalink / raw)
To: Philip Prindeville; +Cc: linux-wireless
In-Reply-To: <4D237C41.70607@redfish-solutions.com>
On 01/04/2011 02:00 PM, Philip Prindeville wrote:
> Anyone else seeing the following breakage? I'm building the 2010-12-24
> snapshot against 2.6.27.49:
>
> CC [M]
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.o
>
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:
> In function '_rtl_init_deferred_work':
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229:
> error: implicit declaration of function 'alloc_workqueue'
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229:
> warning: assignment makes pointer from integer without a cast
The call create_workqueue() is obsolete and is being replaced by
alloc_workqueue(). Unfortunately, older kernels do not have the newer call. A
patch for compat-wireless has been submitted, but I don't think the package has
rebuilt successfully since then. You have two options: (1) if you do not need a
driver for the RTL8192CE/RTL8187CE cards, then deselect them from the build, or
(2) Find the line in drivers/net/wireless/rtlwifi/base.c that says
rtlpriv->works.rtl_wq = alloc_workqueue(rtlpriv->cfg->name, 0, 0);
and replace it with
rtlpriv->works.rtl_wq = create_workqueue(rtlpriv->cfg->name);
Larry
^ permalink raw reply
* Breakage in rtlwifi/base.c for 2010-12-24
From: Philip Prindeville @ 2011-01-04 20:00 UTC (permalink / raw)
To: linux-wireless
Anyone else seeing the following breakage? I'm building the 2010-12-24 snapshot against 2.6.27.49:
CC [M] /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.o
/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c: In function '_rtl_init_deferred_work':
/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229: error: implicit declaration of function 'alloc_workqueue'
/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229: warning: assignment makes pointer from integer without a cast
make[5]: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.o] Error 1
make[4]: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi] Error 2
make[3]: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless] Error 2
make[2]: *** [_module_/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24] Error 2
make[2]: Leaving directory `/home/philipp/astlinux/build_i586/linux-2.6.27.49-astlinux'
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24'
make: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/net/wireless/lib80211.ko] Error 2
^ permalink raw reply
* Compat-wireless release for 2011-01-04 is baked
From: Compat-wireless cronjob account @ 2011-01-04 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
9b210cb..959f374 history -> origin/history
+ bfa221f...924c697 master -> origin/master (forced update)
3643e0e..03ed6a3 stable -> origin/stable
* [new tag] next-20110104 -> next-20110104
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
/usr/bin/sha1sum: *.tar.bz2: No such file or directory
compat-wireless code metrics
774934 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [PATCH v2 1/6] ath9k_htc: Fix warning on device removal
From: Sujith @ 2011-01-04 19:51 UTC (permalink / raw)
To: John W. Linville; +Cc: Sujith, linux-wireless@vger.kernel.org
In-Reply-To: <20110104194337.GB13239@tuxdriver.com>
John W. Linville wrote:
> On Tue, Dec 28, 2010 at 02:27:52PM +0530, Sujith wrote:
> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> >
> > The commit "ath9k_hw: warn if we cannot change the power to the chip"
> > introduced a new warning to indicate chip powerup failures, but this
> > is not required for devices that have been removed. Handle USB device
> > removal properly by checking for unplugged status.
> >
> > For PCI devices, this warning will still be seen when the card is pulled
> > out, not sure how to check for card removal.
> >
> > Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
>
> This doesn't seem to apply cleanly?
Sent a rebased version. Thanks.
Sujith
^ permalink raw reply
* [PATCH v2] ath9k_htc: Fix warning on device removal
From: Sujith @ 2011-01-04 19:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Sujith.Manoharan
From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
The commit "ath9k_hw: warn if we cannot change the power to the chip"
introduced a new warning to indicate chip powerup failures, but this
is not required for devices that have been removed. Handle USB device
removal properly by checking for unplugged status.
For PCI devices, this warning will still be seen when the card is pulled
out, not sure how to check for card removal.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/eeprom.h | 2 --
drivers/net/wireless/ath/ath9k/hif_usb.c | 6 +++---
drivers/net/wireless/ath/ath9k/htc.h | 5 ++---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 5 +----
drivers/net/wireless/ath/ath9k/hw.c | 4 +++-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++++
drivers/net/wireless/ath/ath9k/wmi.c | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index f6f09d1..58e2ddc 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -23,8 +23,6 @@
#include <net/cfg80211.h>
#include "ar9003_eeprom.h"
-#define AH_USE_EEPROM 0x1
-
#ifdef __BIG_ENDIAN
#define AR5416_EEPROM_MAGIC 0x5aa5
#else
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 22b68b3..c20c8c8 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -993,16 +993,16 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
{
struct usb_device *udev = interface_to_usbdev(interface);
struct hif_device_usb *hif_dev = usb_get_intfdata(interface);
+ bool unplugged = (udev->state == USB_STATE_NOTATTACHED) ? true : false;
if (hif_dev) {
- ath9k_htc_hw_deinit(hif_dev->htc_handle,
- (udev->state == USB_STATE_NOTATTACHED) ? true : false);
+ ath9k_htc_hw_deinit(hif_dev->htc_handle, unplugged);
ath9k_htc_hw_free(hif_dev->htc_handle);
ath9k_hif_usb_dev_deinit(hif_dev);
usb_set_intfdata(interface, NULL);
}
- if (hif_dev->flags & HIF_USB_START)
+ if (!unplugged && (hif_dev->flags & HIF_USB_START))
ath9k_hif_usb_reboot(udev);
kfree(hif_dev);
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index fdf9d5f..e6c2f0a 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -339,9 +339,8 @@ void ath_htc_cancel_btcoex_work(struct ath9k_htc_priv *priv);
#define OP_ASSOCIATED BIT(7)
#define OP_ENABLE_BEACON BIT(8)
#define OP_LED_DEINIT BIT(9)
-#define OP_UNPLUGGED BIT(10)
-#define OP_BT_PRIORITY_DETECTED BIT(11)
-#define OP_BT_SCAN BIT(12)
+#define OP_BT_PRIORITY_DETECTED BIT(10)
+#define OP_BT_SCAN BIT(11)
struct ath9k_htc_priv {
struct device *dev;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 0f6be35..724f545 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -851,9 +851,6 @@ int ath9k_htc_probe_device(struct htc_target *htc_handle, struct device *dev,
if (ret)
goto err_init;
- /* The device may have been unplugged earlier. */
- priv->op_flags &= ~OP_UNPLUGGED;
-
ret = ath9k_init_device(priv, devid, product, drv_info);
if (ret)
goto err_init;
@@ -873,7 +870,7 @@ void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug)
/* Check if the device has been yanked out. */
if (hotunplug)
- htc_handle->drv_priv->op_flags |= OP_UNPLUGGED;
+ htc_handle->drv_priv->ah->ah_flags |= AH_UNPLUGGED;
ath9k_deinit_device(htc_handle->drv_priv);
ath9k_deinit_wmi(htc_handle->drv_priv);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 4b51ed4..fde9786 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1615,7 +1615,9 @@ bool ath9k_hw_setpower(struct ath_hw *ah, enum ath9k_power_mode mode)
* simply keep the ATH_DBG_WARN_ON_ONCE() but make
* ath9k_hw_setpower() return type void.
*/
- ATH_DBG_WARN_ON_ONCE(!status);
+
+ if (!(ah->ah_flags & AH_UNPLUGGED))
+ ATH_DBG_WARN_ON_ONCE(!status);
return status;
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index b8ffaa5..5a3dfec 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -646,6 +646,10 @@ struct ath_nf_limits {
s16 nominal;
};
+/* ah_flags */
+#define AH_USE_EEPROM 0x1
+#define AH_UNPLUGGED 0x2 /* The card has been physically removed. */
+
struct ath_hw {
struct ieee80211_hw *hw;
struct ath_common common;
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index 8f42ea7..573daca 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -250,7 +250,7 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
int time_left, ret = 0;
unsigned long flags;
- if (wmi->drv_priv->op_flags & OP_UNPLUGGED)
+ if (ah->ah_flags & AH_UNPLUGGED)
return 0;
skb = alloc_skb(headroom + cmd_len, GFP_ATOMIC);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v2 1/6] ath9k_htc: Fix warning on device removal
From: John W. Linville @ 2011-01-04 19:43 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless, Sujith.Manoharan
In-Reply-To: <19737.42640.829281.50449@gargle.gargle.HOWL>
On Tue, Dec 28, 2010 at 02:27:52PM +0530, Sujith wrote:
> From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
>
> The commit "ath9k_hw: warn if we cannot change the power to the chip"
> introduced a new warning to indicate chip powerup failures, but this
> is not required for devices that have been removed. Handle USB device
> removal properly by checking for unplugged status.
>
> For PCI devices, this warning will still be seen when the card is pulled
> out, not sure how to check for card removal.
>
> Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
This doesn't seem to apply cleanly?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] ath9k_htc: Really fix packet injection
From: Sujith @ 2011-01-04 19:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Sujith.Manoharan
From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
The chainmask value along with other configuration has to be set
on the target for packet injection. Fix this and also move the monitor
interface addition before the channel set segment to ensure that
the opmode is updated properly.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc.h | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 37 +++++++++++++++++-------
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index a099b3e..1ce506f 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -433,6 +433,7 @@ void ath9k_htc_txep(void *priv, struct sk_buff *skb, enum htc_endpoint_id ep_id,
void ath9k_htc_beaconep(void *drv_priv, struct sk_buff *skb,
enum htc_endpoint_id ep_id, bool txok);
+int ath9k_htc_update_cap_target(struct ath9k_htc_priv *priv);
void ath9k_htc_station_work(struct work_struct *work);
void ath9k_htc_aggr_work(struct work_struct *work);
void ath9k_ani_work(struct work_struct *work);;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 845b4c9..f4d576b 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -301,6 +301,16 @@ static int ath9k_htc_add_monitor_interface(struct ath9k_htc_priv *priv)
priv->nstations++;
+ /*
+ * Set chainmask etc. on the target.
+ */
+ ret = ath9k_htc_update_cap_target(priv);
+ if (ret)
+ ath_dbg(common, ATH_DBG_CONFIG,
+ "Failed to update capability in target\n");
+
+ priv->ah->is_monitoring = true;
+
return 0;
err_vif:
@@ -328,6 +338,7 @@ static int ath9k_htc_remove_monitor_interface(struct ath9k_htc_priv *priv)
}
priv->nstations--;
+ priv->ah->is_monitoring = false;
return 0;
}
@@ -419,7 +430,7 @@ static int ath9k_htc_remove_station(struct ath9k_htc_priv *priv,
return 0;
}
-static int ath9k_htc_update_cap_target(struct ath9k_htc_priv *priv)
+int ath9k_htc_update_cap_target(struct ath9k_htc_priv *priv)
{
struct ath9k_htc_cap_target tcap;
int ret;
@@ -1186,6 +1197,20 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
}
}
+ /*
+ * Monitor interface should be added before
+ * IEEE80211_CONF_CHANGE_CHANNEL is handled.
+ */
+ if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
+ if (conf->flags & IEEE80211_CONF_MONITOR) {
+ if (ath9k_htc_add_monitor_interface(priv))
+ ath_err(common, "Failed to set monitor mode\n");
+ else
+ ath_dbg(common, ATH_DBG_CONFIG,
+ "HW opmode set to Monitor mode\n");
+ }
+ }
+
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
struct ieee80211_channel *curchan = hw->conf.channel;
int pos = curchan->hw_value;
@@ -1221,16 +1246,6 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
ath_update_txpow(priv);
}
- if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
- if (conf->flags & IEEE80211_CONF_MONITOR) {
- if (ath9k_htc_add_monitor_interface(priv))
- ath_err(common, "Failed to set monitor mode\n");
- else
- ath_dbg(common, ATH_DBG_CONFIG,
- "HW opmode set to Monitor mode\n");
- }
- }
-
if (changed & IEEE80211_CONF_CHANGE_IDLE) {
mutex_lock(&priv->htc_pm_lock);
if (!priv->ps_idle) {
--
1.7.3.4
^ permalink raw reply related
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Luis Correia @ 2011-01-04 19:01 UTC (permalink / raw)
To: Helmut Schaa; +Cc: users, Luis R. Rodriguez, linux-wireless
In-Reply-To: <201101041946.56978.helmut.schaa@googlemail.com>
Hi all,
On Tue, Jan 4, 2011 at 18:46, Helmut Schaa <helmut.schaa@googlemail.com> wrote:
> Hi Aleksandar,
>
> looks like a somewhat strange regulatory handling. However, I'm not really
> familiar with the regulatory stuff. Maybe Luis can give us some info/ideas
> regarding this ...
>
> Luis, mind to have a look at the regulatory messages below?
>
Yes, there is something fishy with it.
this is what is allowed for Ireland
country IE:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 40), (N/A, 20)
(5250 - 5330 @ 40), (N/A, 20), DFS
(5490 - 5710 @ 40), (N/A, 27), DFS
Apparently IE Ireland does allow 5Ghz channels, and something is
really strange is going on.
Maybe if the Airport Extreme was changed to a new channel, it would improve.
But I'm not totally sure.
We might also be looking at an old regulatory daemon or database.
Luis Correia
> Am Dienstag, 4. Januar 2011 schrieb Aleksandar Milivojevic:
>> I've searched around a bit and haven't found much information that looks
>> like the problem I'm experiencing with rt2x00 drivers.
>>
>> The hardware I have is Linksys WUSB600N USB stick, v1 hardware revision,
>> which should have RT2870 chipset. The kernel used is from a generic Ubuntu
>> 10.10 distribution (uname shows "Linux toporko 2.6.35-24-generic #42-Ubuntu
>> SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux"). The output of lsusb
>> identifies device as:
>>
>> Bus 001 Device 003: ID 1737:0071 Linksys WUSB600N Dual-Band Wireless-N USB
>> Network Adapter
>>
>> The problem I'm experiencing is that I'm able to connect to my AP (an Apple
>> Airport Extreme operating at 5GHZ) shortly after boot. However, shortly
>> after connection is made (usually within few minutes), the connection is
>> dropped, and all subsequent attempts to re-connect to AP fail. Reloading
>> the driver helps to reconnect, but connection is again dropped after few
>> minutes. I also have another AP (an old Linksys WRT54G) operating on
>> 2.4GHz, and it seems same issue is present if I attempt to connect to it
>> (haven't experimented with this other setup much, as I'm much more
>> interested in connecting to my WiFi-N network).
>>
>> The list of relevant loaded drivers on the system shows (looking for
>> anything starting with 'rt' in the name):
>> rt2800usb 8367 0
>> rt2800lib 28897 1 rt2800usb
>> rt2x00usb 9779 2 rt2800usb,rt2800lib
>> rt2x00lib 27275 2 rt2800lib,rt2x00usb
>> led_class 2633 1 rt2x00lib
>> mac80211 231541 2 rt2x00usb,rt2x00lib
>> cfg80211 144470 2 rt2x00lib,mac80211
>>
>> I have rt2870sta driver blacklisted to prevent it from conflicting with
>> rt2x00 drivers.
>>
>> Looking at the log files, it seems /var/log/messages and /var/log/debug
>> contain most interesting logs.
>>
>> I found following snippet in /var/log/messages:
>>
>> Jan 3 10:39:38 toporko kernel: [ 70.143600] ADDRCONF(NETDEV_CHANGE):
>> wlan0: link becomes ready
>> Jan 3 10:39:38 toporko kernel: [ 70.143712] cfg80211: Calling CRDA for
>> country: US
>> Jan 3 10:39:38 toporko kernel: [ 70.219910] cfg80211: Regulatory domain:
>> US
>> Jan 3 10:39:38 toporko kernel: [ 70.219914] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.219918] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219923] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219928] cfg80211: Regulatory domain:
>> US
>> Jan 3 10:39:38 toporko kernel: [ 70.219930] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.219935] (2402000 KHz - 2472000
>> KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219939] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219943] (5250000 KHz - 5330000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219947] (5490000 KHz - 5600000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219951] (5650000 KHz - 5710000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219955] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219960] cfg80211: Regulatory domain:
>> 98
>> Jan 3 10:39:38 toporko kernel: [ 70.219962] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.219966] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219971] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.220189] cfg80211: Current regulatory
>> domain updated by AP to: US
>> Jan 3 10:39:38 toporko kernel: [ 70.220192] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.220196] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.220200] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.409801] padlock: VIA PadLock not
>> detected.
>> Jan 3 10:40:20 toporko kernel: [ 112.656632] lo: Disabled Privacy
>> Extensions
>> Jan 3 10:41:31 toporko kernel: [ 183.593983] cfg80211: Calling CRDA to
>> update world regulatory domain
>> Jan 3 10:41:31 toporko kernel: [ 183.625264] cfg80211: World regulatory
>> domain updated:
>> Jan 3 10:41:31 toporko kernel: [ 183.625272] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:41:31 toporko kernel: [ 183.625277] (2402000 KHz - 2472000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625282] (2457000 KHz - 2482000
>> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625286] (2474000 KHz - 2494000
>> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625290] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625294] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>
>>
>> I also found similar snippet in /var/log/debug. Interestingly, unlike the
>> one above that lists IE as US (which is correct for my location, and
>> corresponds to the settings in my AP), in debug log file IE is strangely
>> blank with bunch of lines about disabled frequencies:
>>
>> Jan 3 10:39:38 toporko kernel: [ 70.114337] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:39:38 toporko kernel: [ 70.114955] wlan0: authenticated
>> Jan 3 10:39:38 toporko kernel: [ 70.118103] wlan0: associate with
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:39:38 toporko kernel: [ 70.119214] wlan0: RX AssocResp from
>> 00:1e:52:79:e9:ff (capab=0x511 status=0 aid=1)
>> Jan 3 10:39:38 toporko kernel: [ 70.119220] wlan0: associated
>> Jan 3 10:39:38 toporko kernel: [ 70.219901] cfg80211: Received country
>> IE:
>> Jan 3 10:39:38 toporko kernel: [ 70.219925] cfg80211: CRDA thinks this
>> should applied:
>> Jan 3 10:39:38 toporko kernel: [ 70.219957] cfg80211: We intersect both
>> of these and get:
>> Jan 3 10:39:38 toporko kernel: [ 70.219977] cfg80211: Leaving channel
>> 2412 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219981] cfg80211: Leaving channel
>> 2417 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219985] cfg80211: Leaving channel
>> 2422 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219988] cfg80211: Leaving channel
>> 2427 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219992] cfg80211: Leaving channel
>> 2432 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220044] cfg80211: Leaving channel
>> 2437 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220048] cfg80211: Leaving channel
>> 2442 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220052] cfg80211: Leaving channel
>> 2447 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220056] cfg80211: Leaving channel
>> 2452 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220059] cfg80211: Leaving channel
>> 2457 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220063] cfg80211: Leaving channel
>> 2462 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220066] cfg80211: Leaving channel
>> 2467 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220070] cfg80211: Leaving channel
>> 2472 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220073] cfg80211: Leaving channel
>> 2484 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220078] cfg80211: Disabling channel
>> 5260 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220081] cfg80211: Disabling channel
>> 5270 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220084] cfg80211: Disabling channel
>> 5280 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220087] cfg80211: Disabling channel
>> 5300 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220091] cfg80211: Disabling channel
>> 5310 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220094] cfg80211: Disabling channel
>> 5320 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220097] cfg80211: Disabling channel
>> 5500 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220100] cfg80211: Disabling channel
>> 5510 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220103] cfg80211: Disabling channel
>> 5520 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220106] cfg80211: Disabling channel
>> 5540 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220109] cfg80211: Disabling channel
>> 5550 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220113] cfg80211: Disabling channel
>> 5560 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220116] cfg80211: Disabling channel
>> 5580 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220119] cfg80211: Disabling channel
>> 5590 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220122] cfg80211: Disabling channel
>> 5600 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220125] cfg80211: Disabling channel
>> 5620 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220128] cfg80211: Disabling channel
>> 5630 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220131] cfg80211: Disabling channel
>> 5640 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220135] cfg80211: Disabling channel
>> 5660 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220138] cfg80211: Disabling channel
>> 5670 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220141] cfg80211: Disabling channel
>> 5680 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220144] cfg80211: Disabling channel
>> 5700 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220148] cfg80211: Disabling channel
>> 5835 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220151] cfg80211: Disabling channel
>> 5845 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220154] cfg80211: Disabling channel
>> 5855 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220157] cfg80211: Disabling channel
>> 5865 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220160] cfg80211: Disabling channel
>> 5920 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220163] cfg80211: Disabling channel
>> 5940 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220167] cfg80211: Disabling channel
>> 5960 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220170] cfg80211: Disabling channel
>> 5980 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220173] cfg80211: Disabling channel
>> 6040 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220176] cfg80211: Disabling channel
>> 6060 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220179] cfg80211: Disabling channel
>> 6080 MHz on phy0 due to Country IE
>> Jan 3 10:41:31 toporko kernel: [ 183.564046] No probe response from AP
>> 00:1e:52:79:e9:ff after 500ms, disconnecting.
>> Jan 3 10:41:31 toporko kernel: [ 183.593968] cfg80211: All devices are
>> disconnected, going to restore regulatory settings
>> Jan 3 10:41:31 toporko kernel: [ 183.593977] cfg80211: Restoring
>> regulatory settings
>> Jan 3 10:41:34 toporko kernel: [ 186.856369] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:41:34 toporko kernel: [ 187.056156] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 2)
>> Jan 3 10:41:35 toporko kernel: [ 187.256419] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 3)
>> Jan 3 10:41:35 toporko kernel: [ 187.456054] wlan0: authentication with
>> 00:1e:52:79:e9:ff timed out
>> Jan 3 10:41:47 toporko kernel: [ 200.054031] wlan0: direct probe to
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:41:48 toporko kernel: [ 200.252050] wlan0: direct probe to
>> 00:1e:52:79:e9:ff (try 2)
>> Jan 3 10:41:48 toporko kernel: [ 200.452085] wlan0: direct probe to
>> 00:1e:52:79:e9:ff (try 3)
>
> We received an empty country IE and as a result disabled serveral 11a channels.
> Maybe even the one we are currently associated to?
>
> Thanks,
> Helmut
>
> _______________________________________________
> users mailing list
> users@rt2x00.serialmonkey.com
> http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
>
^ permalink raw reply
* Re: [PATCH 0/8] wireless: DFS region support
From: John W. Linville @ 2011-01-04 18:49 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: kathy.giori, amod.bodas, david.quan, michael.green,
linux-wireless
In-Reply-To: <1292864555-28661-1-git-send-email-lrodriguez@atheros.com>
On Mon, Dec 20, 2010 at 12:02:26PM -0500, Luis R. Rodriguez wrote:
> This series has a list of changes to kernel and userspace to start addressing
> DFS region support. I've cheated and figured out a way to alter the current
> regulatory database in such a way that it remains backwards compatible with
> older databases so that no new CRDAs are required and we don't have to provide
> two releases for old kernels and newer kernels for wireless-regdb updates.
>
> In the end we end up passing the DFS region to the drivers. In terms of our DFS
> development roadmap this covers parts I and II as promissed that I would take care
> of by tomorrow, and leaves open now the chance for developers to start working
> on part III: "Where do we stuff DFS parameters for each region":
>
> http://wireless.kernel.org/en/developers/DFS
>
> In tomorrow's meeting we can cover who is going to work on part III. People who
> want to work on part III can start using these patches on their systems.
>
> John, lets wait to merge these until Wednesday, I post these in patch form as I
> think they are ready but tomorrow's discussions may push us to alter this a
> bit, not sure. I will also review what we have done here with Michael Green so
> he is on the same page.
Well, now there has been plenty of time to reflect...comments? :-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Helmut Schaa @ 2011-01-04 18:46 UTC (permalink / raw)
To: users; +Cc: Aleksandar Milivojevic, linux-wireless, Luis R. Rodriguez
In-Reply-To: <AANLkTim0AM3=T=TMu79ZQi79+CKANamBcz620n2xm8bW@mail.gmail.com>
Hi Aleksandar,
looks like a somewhat strange regulatory handling. However, I'm not really
familiar with the regulatory stuff. Maybe Luis can give us some info/ideas
regarding this ...
Luis, mind to have a look at the regulatory messages below?
Am Dienstag, 4. Januar 2011 schrieb Aleksandar Milivojevic:
> I've searched around a bit and haven't found much information that looks
> like the problem I'm experiencing with rt2x00 drivers.
>
> The hardware I have is Linksys WUSB600N USB stick, v1 hardware revision,
> which should have RT2870 chipset. The kernel used is from a generic Ubuntu
> 10.10 distribution (uname shows "Linux toporko 2.6.35-24-generic #42-Ubuntu
> SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux"). The output of lsusb
> identifies device as:
>
> Bus 001 Device 003: ID 1737:0071 Linksys WUSB600N Dual-Band Wireless-N USB
> Network Adapter
>
> The problem I'm experiencing is that I'm able to connect to my AP (an Apple
> Airport Extreme operating at 5GHZ) shortly after boot. However, shortly
> after connection is made (usually within few minutes), the connection is
> dropped, and all subsequent attempts to re-connect to AP fail. Reloading
> the driver helps to reconnect, but connection is again dropped after few
> minutes. I also have another AP (an old Linksys WRT54G) operating on
> 2.4GHz, and it seems same issue is present if I attempt to connect to it
> (haven't experimented with this other setup much, as I'm much more
> interested in connecting to my WiFi-N network).
>
> The list of relevant loaded drivers on the system shows (looking for
> anything starting with 'rt' in the name):
> rt2800usb 8367 0
> rt2800lib 28897 1 rt2800usb
> rt2x00usb 9779 2 rt2800usb,rt2800lib
> rt2x00lib 27275 2 rt2800lib,rt2x00usb
> led_class 2633 1 rt2x00lib
> mac80211 231541 2 rt2x00usb,rt2x00lib
> cfg80211 144470 2 rt2x00lib,mac80211
>
> I have rt2870sta driver blacklisted to prevent it from conflicting with
> rt2x00 drivers.
>
> Looking at the log files, it seems /var/log/messages and /var/log/debug
> contain most interesting logs.
>
> I found following snippet in /var/log/messages:
>
> Jan 3 10:39:38 toporko kernel: [ 70.143600] ADDRCONF(NETDEV_CHANGE):
> wlan0: link becomes ready
> Jan 3 10:39:38 toporko kernel: [ 70.143712] cfg80211: Calling CRDA for
> country: US
> Jan 3 10:39:38 toporko kernel: [ 70.219910] cfg80211: Regulatory domain:
> US
> Jan 3 10:39:38 toporko kernel: [ 70.219914] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.219918] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219923] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219928] cfg80211: Regulatory domain:
> US
> Jan 3 10:39:38 toporko kernel: [ 70.219930] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.219935] (2402000 KHz - 2472000
> KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219939] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219943] (5250000 KHz - 5330000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219947] (5490000 KHz - 5600000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219951] (5650000 KHz - 5710000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219955] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219960] cfg80211: Regulatory domain:
> 98
> Jan 3 10:39:38 toporko kernel: [ 70.219962] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.219966] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219971] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.220189] cfg80211: Current regulatory
> domain updated by AP to: US
> Jan 3 10:39:38 toporko kernel: [ 70.220192] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.220196] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.220200] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.409801] padlock: VIA PadLock not
> detected.
> Jan 3 10:40:20 toporko kernel: [ 112.656632] lo: Disabled Privacy
> Extensions
> Jan 3 10:41:31 toporko kernel: [ 183.593983] cfg80211: Calling CRDA to
> update world regulatory domain
> Jan 3 10:41:31 toporko kernel: [ 183.625264] cfg80211: World regulatory
> domain updated:
> Jan 3 10:41:31 toporko kernel: [ 183.625272] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:41:31 toporko kernel: [ 183.625277] (2402000 KHz - 2472000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625282] (2457000 KHz - 2482000
> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625286] (2474000 KHz - 2494000
> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625290] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625294] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>
>
> I also found similar snippet in /var/log/debug. Interestingly, unlike the
> one above that lists IE as US (which is correct for my location, and
> corresponds to the settings in my AP), in debug log file IE is strangely
> blank with bunch of lines about disabled frequencies:
>
> Jan 3 10:39:38 toporko kernel: [ 70.114337] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:39:38 toporko kernel: [ 70.114955] wlan0: authenticated
> Jan 3 10:39:38 toporko kernel: [ 70.118103] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:39:38 toporko kernel: [ 70.119214] wlan0: RX AssocResp from
> 00:1e:52:79:e9:ff (capab=0x511 status=0 aid=1)
> Jan 3 10:39:38 toporko kernel: [ 70.119220] wlan0: associated
> Jan 3 10:39:38 toporko kernel: [ 70.219901] cfg80211: Received country
> IE:
> Jan 3 10:39:38 toporko kernel: [ 70.219925] cfg80211: CRDA thinks this
> should applied:
> Jan 3 10:39:38 toporko kernel: [ 70.219957] cfg80211: We intersect both
> of these and get:
> Jan 3 10:39:38 toporko kernel: [ 70.219977] cfg80211: Leaving channel
> 2412 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219981] cfg80211: Leaving channel
> 2417 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219985] cfg80211: Leaving channel
> 2422 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219988] cfg80211: Leaving channel
> 2427 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219992] cfg80211: Leaving channel
> 2432 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220044] cfg80211: Leaving channel
> 2437 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220048] cfg80211: Leaving channel
> 2442 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220052] cfg80211: Leaving channel
> 2447 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220056] cfg80211: Leaving channel
> 2452 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220059] cfg80211: Leaving channel
> 2457 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220063] cfg80211: Leaving channel
> 2462 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220066] cfg80211: Leaving channel
> 2467 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220070] cfg80211: Leaving channel
> 2472 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220073] cfg80211: Leaving channel
> 2484 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220078] cfg80211: Disabling channel
> 5260 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220081] cfg80211: Disabling channel
> 5270 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220084] cfg80211: Disabling channel
> 5280 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220087] cfg80211: Disabling channel
> 5300 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220091] cfg80211: Disabling channel
> 5310 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220094] cfg80211: Disabling channel
> 5320 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220097] cfg80211: Disabling channel
> 5500 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220100] cfg80211: Disabling channel
> 5510 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220103] cfg80211: Disabling channel
> 5520 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220106] cfg80211: Disabling channel
> 5540 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220109] cfg80211: Disabling channel
> 5550 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220113] cfg80211: Disabling channel
> 5560 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220116] cfg80211: Disabling channel
> 5580 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220119] cfg80211: Disabling channel
> 5590 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220122] cfg80211: Disabling channel
> 5600 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220125] cfg80211: Disabling channel
> 5620 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220128] cfg80211: Disabling channel
> 5630 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220131] cfg80211: Disabling channel
> 5640 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220135] cfg80211: Disabling channel
> 5660 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220138] cfg80211: Disabling channel
> 5670 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220141] cfg80211: Disabling channel
> 5680 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220144] cfg80211: Disabling channel
> 5700 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220148] cfg80211: Disabling channel
> 5835 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220151] cfg80211: Disabling channel
> 5845 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220154] cfg80211: Disabling channel
> 5855 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220157] cfg80211: Disabling channel
> 5865 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220160] cfg80211: Disabling channel
> 5920 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220163] cfg80211: Disabling channel
> 5940 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220167] cfg80211: Disabling channel
> 5960 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220170] cfg80211: Disabling channel
> 5980 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220173] cfg80211: Disabling channel
> 6040 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220176] cfg80211: Disabling channel
> 6060 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220179] cfg80211: Disabling channel
> 6080 MHz on phy0 due to Country IE
> Jan 3 10:41:31 toporko kernel: [ 183.564046] No probe response from AP
> 00:1e:52:79:e9:ff after 500ms, disconnecting.
> Jan 3 10:41:31 toporko kernel: [ 183.593968] cfg80211: All devices are
> disconnected, going to restore regulatory settings
> Jan 3 10:41:31 toporko kernel: [ 183.593977] cfg80211: Restoring
> regulatory settings
> Jan 3 10:41:34 toporko kernel: [ 186.856369] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:41:34 toporko kernel: [ 187.056156] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 2)
> Jan 3 10:41:35 toporko kernel: [ 187.256419] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 3)
> Jan 3 10:41:35 toporko kernel: [ 187.456054] wlan0: authentication with
> 00:1e:52:79:e9:ff timed out
> Jan 3 10:41:47 toporko kernel: [ 200.054031] wlan0: direct probe to
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:41:48 toporko kernel: [ 200.252050] wlan0: direct probe to
> 00:1e:52:79:e9:ff (try 2)
> Jan 3 10:41:48 toporko kernel: [ 200.452085] wlan0: direct probe to
> 00:1e:52:79:e9:ff (try 3)
We received an empty country IE and as a result disabled serveral 11a channels.
Maybe even the one we are currently associated to?
Thanks,
Helmut
^ permalink raw reply
* Re: (rt61pci/hostapd) no packet activity when encryption is enabled and interface is bridged
From: Helmut Schaa @ 2011-01-04 18:36 UTC (permalink / raw)
To: C Anthony Risinger; +Cc: linux-wireless
In-Reply-To: <AANLkTimPmCZ3O0WKe4OH1z4+rmtUtAr2wqsrFOUCJg_Q@mail.gmail.com>
Am Dienstag, 4. Januar 2011 schrieb C Anthony Risinger:
> On Mon, Jan 3, 2011 at 10:30 PM, C Anthony Risinger <anthony@extof.me> wrote:
> >
> > problem summary: an rt61pci driven card does not seem to allow any
> > packets to enter/exit it's bridge ONLY WHEN ENCRYPTION is enabled;
> > without it, everything works perfectly.
>
> hmmmmm....
>
> it would seem:
>
> options rt61pci nohwcrypt=1
>
> solves the problem. what does this mean? do i have a bad chip?
I don't think so. Might be related to [1].
Helmut
[1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=fa8b4b22d543b4052602b0c86065150613ed19e8
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: Larry Finger @ 2011-01-04 18:19 UTC (permalink / raw)
To: John W. Linville; +Cc: Rafał Miłecki, linux-wireless, b43-dev
In-Reply-To: <20110104181140.GC11333@tuxdriver.com>
On 01/04/2011 12:11 PM, John W. Linville wrote:
> On Tue, Jan 04, 2011 at 10:08:36AM -0600, Larry Finger wrote:
>> On 01/04/2011 09:50 AM, Rafał Miłecki wrote:
>>> W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
>>> <zajec5@gmail.com> napisał:
>>>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>>>> ---
>>>> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
>>>> support seems to be on the same level as for PHYs 1 and 2.
>>>
>>> John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
>>>
>>> It means:
>>> [PATCH 1/4] b43: use correct firmware for newer cores
>>> [PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
>>> [PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
>>> [PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
>>>
>>> [PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
>>> [PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
>>> and this one.
>>
>> John,
>>
>> I have been testing these patches with a 14e4:432b device for at least two
>> weeks. With them, the driver still does not handle WPA/WPA2 encryption and falls
>> over with OFDM rates, but it is rock solid with WEP encryption and at 11 Mb/s.
>> Rafał and I have some ideas why the limitations, but the holidays have
>> interfered with debugging.
>>
>> Larry
>
> And with merging...
>
> I hope to get caught-up soon.
I hope there are some rtlwifi/rtl8192ce updates there as well. I'll wait for
some new merges before I bug you about the specific patches.
Larry
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2011-01-04 18:19 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <20101216174410.GB5677@tux>
On Thu, Dec 16, 2010 at 9:44 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> Try this:
Happy new year. I've tried this patch, and the system continues to
suspend and resume successfully (i.e, the fix from the earlier patches
continues to alleviate the original problem), however the system
continues to be "deaf" to beacons at resume time if the system
suspends and resumes while associated. You don't need a ChromeOS
system to reproduce this issue. Just associate to the network and
suspend/resume. On resume the system believes it should be
associated, but then the beacon loss timer kicks in and we
disassociate, since we are never successful in receiving a response.
--
Paul
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: John W. Linville @ 2011-01-04 18:11 UTC (permalink / raw)
To: Larry Finger; +Cc: Rafał Miłecki, linux-wireless, b43-dev
In-Reply-To: <4D234604.8010602@lwfinger.net>
On Tue, Jan 04, 2011 at 10:08:36AM -0600, Larry Finger wrote:
> On 01/04/2011 09:50 AM, Rafał Miłecki wrote:
> > W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
> > <zajec5@gmail.com> napisał:
> >> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> >> ---
> >> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
> >> support seems to be on the same level as for PHYs 1 and 2.
> >
> > John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
> >
> > It means:
> > [PATCH 1/4] b43: use correct firmware for newer cores
> > [PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
> > [PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
> > [PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
> >
> > [PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
> > [PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
> > and this one.
>
> John,
>
> I have been testing these patches with a 14e4:432b device for at least two
> weeks. With them, the driver still does not handle WPA/WPA2 encryption and falls
> over with OFDM rates, but it is rock solid with WEP encryption and at 11 Mb/s.
> Rafał and I have some ideas why the limitations, but the holidays have
> interfered with debugging.
>
> Larry
And with merging...
I hope to get caught-up soon.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 07/15]drivers:net:wireless:iwlwifi Typo change diable to disable.
From: John W. Linville @ 2011-01-04 17:56 UTC (permalink / raw)
To: Justin P. Mattock
Cc: trivial, linux-m68k, linux-kernel, netdev, ivtv-devel,
linux-media, linux-wireless, linux-scsi, spi-devel-general, devel,
linux-usb
In-Reply-To: <1293750484-1161-7-git-send-email-justinmattock@gmail.com>
On Thu, Dec 30, 2010 at 03:07:56PM -0800, Justin P. Mattock wrote:
> The below patch fixes a typo "diable" to "disable". Please let me know if this
> is correct or not.
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Acked-by: John W. Linville <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Tp-link wn7200nd - cannot associate
From: Helmut Schaa @ 2011-01-04 16:42 UTC (permalink / raw)
To: Chin Shi Hong; +Cc: Ming-Ching Tiew, linux-wireless
In-Reply-To: <AANLkTimk8pnx3F+pwVTZ6sA+=-_h+4u+i=YTzp05Qf=A@mail.gmail.com>
Am Montag, 3. Januar 2011 schrieb Chin Shi Hong:
> Good luck with you. My rt3090 also not work on 64 bit ubuntu but work
> on 32 bit ubuntu.
Might be fixed with [1].
Helmut
[1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=412b31334b831a8c2909afaca017c5a236ac2dd0
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: Larry Finger @ 2011-01-04 16:08 UTC (permalink / raw)
To: John W. Linville; +Cc: Rafał Miłecki, linux-wireless, b43-dev
In-Reply-To: <AANLkTikwKOLJ6A-DTEuVg43_g_cWgDg2xK4M6qQ0Lm4U@mail.gmail.com>
On 01/04/2011 09:50 AM, Rafał Miłecki wrote:
> W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
> <zajec5@gmail.com> napisał:
>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>> ---
>> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
>> support seems to be on the same level as for PHYs 1 and 2.
>
> John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
>
> It means:
> [PATCH 1/4] b43: use correct firmware for newer cores
> [PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
> [PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
> [PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
>
> [PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
> [PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
> and this one.
John,
I have been testing these patches with a 14e4:432b device for at least two
weeks. With them, the driver still does not handle WPA/WPA2 encryption and falls
over with OFDM rates, but it is rock solid with WEP encryption and at 11 Mb/s.
Rafał and I have some ideas why the limitations, but the holidays have
interfered with debugging.
Larry
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: Rafał Miłecki @ 2011-01-04 15:50 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: b43-dev, Rafał Miłecki
In-Reply-To: <1292963384-23684-1-git-send-email-zajec5@gmail.com>
W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
<zajec5@gmail.com> napisał:
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> ---
> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
> support seems to be on the same level as for PHYs 1 and 2.
John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
It means:
[PATCH 1/4] b43: use correct firmware for newer cores
[PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
[PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
[PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
[PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
[PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
and this one.
--
Rafał
^ 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