* Re: [RFC v2] cfg80211: Add HT BSS attributes
From: Sujith @ 2011-01-07 2:15 UTC (permalink / raw)
To: Daniel Halperin; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <AANLkTi=ZcigYLqqmhHc638_AxSODWrVrTV5KELRws3XX@mail.gmail.com>
Daniel Halperin wrote:
> Yeah, me too. Isn't greenfield mode (whether there are legacy devices
> around) part of the operating capabilities and should be supported by
> hostapd?
Yes, hostapd does check if there are non-GF stations in the BSS and updates
the HT operation mode parameters. But the nl80211 interface hook is currently
not implemented.
Sujith
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Eric Dumazet @ 2011-01-07 2:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Christian Lamparter, greearb, linux-wireless, ath9k-devel
In-Reply-To: <AANLkTi=+F_O1_2c07zLEGVDSAkuA2_MwghwRQK9pHMN7@mail.gmail.com>
Le jeudi 06 janvier 2011 à 18:13 -0800, Luis R. Rodriguez a écrit :
> On Thu, Jan 6, 2011 at 6:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> The only way to accept your patch is to use a debugfs option to
> disable it, we need AMSDU support enabled by default.
>
I dont care of my patch ;)
There is a reason I felt it was not appropriate.
> > If the hardware needs 8192 bytes (or 16384) buffers to perform its
> > operation, it should not give them back to linux, because there is no
> > guarantee it can allocate fresh ones for the next frames.
>
> Last I looked at this the issue was not the upper used by the driver
> but an issue of a roundoff by the kernel that ended up on *some*
> machines going a higher order. Not all machines use the higher order.
> I wondered at one point if using ksize() might help here too but
> again, this is a new API. Not sure how to fix it for older kernels.
common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
ah->caps.rx_status_len,
min(common->cachelsz, (u16)64));
Given IEEE80211_MAX_MPDU_LEN is more than 3840, and skb shinfo adds more
than 256 bytes, I can assert rx_bufsize is greater than 4096 : order-1
allocations at minimum.
ksize() wont help you.
Many net drivers perform a copy (r8169.c comes to mind, because of a
hardware flaw).
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Luis R. Rodriguez @ 2011-01-07 2:30 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1294361165-15308-3-git-send-email-greearb@candelatech.com>
On Thu, Jan 6, 2011 at 4:46 PM, <greearb@candelatech.com> wrote:
> +#define ATH9K_MAX_STATIONS 1024
How about making this a Kconfig with a default to a value of the known
(by you) max workable number of STAs that one can use on ath9k, which
is modifiable to other values by power of two up to 1024. Advise in
the kconfig that if more STAs are used then some issue may arise but
should be reported (so the issue can be fixed). This way by default
normal users (you're not normal) won't enable > max known workable
stable number of STAs on ath9k.
Luis
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Eric Dumazet @ 2011-01-07 2:33 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Christian Lamparter, greearb, linux-wireless, ath9k-devel
In-Reply-To: <1294367080.2704.46.camel@edumazet-laptop>
Le vendredi 07 janvier 2011 à 03:24 +0100, Eric Dumazet a écrit :
> Given IEEE80211_MAX_MPDU_LEN is more than 3840, and skb shinfo adds more
> than 256 bytes, I can assert rx_bufsize is greater than 4096 : order-1
On 64bit arches :
sizeof(struct skb_shared_info) = 0x198 = 408
^ permalink raw reply
* Re: [RFC v2] cfg80211: Add HT BSS attributes
From: Daniel Halperin @ 2011-01-07 2:33 UTC (permalink / raw)
To: Sujith; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <19750.30510.548719.848168@gargle.gargle.HOWL>
On Thu, Jan 6, 2011 at 6:15 PM, Sujith <m.sujith@gmail.com> wrote:
> Daniel Halperin wrote:
>> Yeah, me too. Isn't greenfield mode (whether there are legacy devices
>> around) part of the operating capabilities and should be supported by
>> hostapd?
>
> Yes, hostapd does check if there are non-GF stations in the BSS and updates
> the HT operation mode parameters. But the nl80211 interface hook is currently
> not implemented.
>
right.. so don't we want this patch? :) Sorry if I'm being obtuse
Dan
^ permalink raw reply
* Re: [RFC v2] cfg80211: Add HT BSS attributes
From: Sujith @ 2011-01-07 2:39 UTC (permalink / raw)
To: Daniel Halperin; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <AANLkTimgd-EbLBe6KHnj5_9Paeg++rp1v8J5s5hy_NOa@mail.gmail.com>
Daniel Halperin wrote:
> On Thu, Jan 6, 2011 at 6:15 PM, Sujith <m.sujith@gmail.com> wrote:
> > Daniel Halperin wrote:
> >> Yeah, me too. Isn't greenfield mode (whether there are legacy devices
> >> around) part of the operating capabilities and should be supported by
> >> hostapd?
> >
> > Yes, hostapd does check if there are non-GF stations in the BSS and updates
> > the HT operation mode parameters. But the nl80211 interface hook is currently
> > not implemented.
> >
>
> right.. so don't we want this patch? :) Sorry if I'm being obtuse
The Greenfield status is part of opmode (see operation_mode in struct ieee80211_ht_info).
This is already handled by mac80211 through NL80211_ATTR_BSS_HT_OPMODE for AP mode.
Sujith
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Luis R. Rodriguez @ 2011-01-07 2:44 UTC (permalink / raw)
To: Aleksandar Milivojevic
Cc: Wolfgang Kufner, Luis Correia, Luis Rodriguez,
linux-wireless@vger.kernel.org, users@rt2x00.serialmonkey.com,
Helmut Schaa
In-Reply-To: <AANLkTin8JO4UHUYLufSmPhRw0ZndDdjTpueSOHNQbDiZ@mail.gmail.com>
On Thu, Jan 06, 2011 at 08:31:22AM -0800, Aleksandar Milivojevic wrote:
> Playing with it a bit more this morning. Looks like the connection
> from wireless adapter to my AP drops periodically. Sometimes it
> recovers (sometimes after several attempts), sometimes it does not.
> Seems to be very random:
>
> # egrep 'authent|associat' /var/log/debug
> Jan 6 08:00:54 toporko kernel: [ 47.570810] wlan0: authenticate
> with 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:00:54 toporko kernel: [ 47.571321] wlan0: authenticated
> Jan 6 08:00:56 toporko kernel: [ 49.174175] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:00:56 toporko kernel: [ 49.175536] wlan0: associated
> Jan 6 08:06:01 toporko kernel: [ 354.230874] wlan0: authenticate
> with 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:06:01 toporko kernel: [ 354.231364] wlan0: authenticated
> Jan 6 08:06:01 toporko kernel: [ 354.236066] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:06:01 toporko kernel: [ 354.236865] wlan0: associated
> Jan 6 08:09:36 toporko kernel: [ 569.868923] wlan0: authenticate
> with 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:09:36 toporko kernel: [ 569.869416] wlan0: authenticated
> Jan 6 08:09:36 toporko kernel: [ 569.873736] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:09:36 toporko kernel: [ 569.874507] wlan0: associated
> Jan 6 08:09:46 toporko kernel: [ 579.233563] wlan0: authenticate
> with 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:09:46 toporko kernel: [ 579.235574] wlan0: authenticated
> Jan 6 08:09:46 toporko kernel: [ 579.240737] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:09:46 toporko kernel: [ 579.241518] wlan0: associated
> Jan 6 08:09:57 toporko kernel: [ 590.830933] wlan0: authenticate
> with 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:09:57 toporko kernel: [ 590.831435] wlan0: authenticated
> Jan 6 08:09:57 toporko kernel: [ 590.839102] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:09:57 toporko kernel: [ 590.839881] wlan0: associated
> Jan 6 08:21:29 toporko kernel: [ 1282.823289] wlan0: authenticate
> with 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:21:29 toporko kernel: [ 1282.823783] wlan0: authenticated
> Jan 6 08:21:29 toporko kernel: [ 1282.828990] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:21:29 toporko kernel: [ 1282.830132] wlan0: associated
> Jan 6 08:25:30 toporko kernel: [ 1523.433931] wlan0: authenticate
> with 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:25:30 toporko kernel: [ 1523.434930] wlan0: authenticated
> Jan 6 08:25:30 toporko kernel: [ 1523.439868] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 6 08:25:30 toporko kernel: [ 1523.440652] wlan0: associated
>
> So far, it managed to re-connect every time. Though, I'm rather sure
> if I leave it long enough, the last night's case of connection dropped
> completely would repeat sooner or later (even last night, there were
> some connect/disconnect events before connection was dropped
> permanently).
>
> The AP reports signal from wireless card between -70 and -75dB, noise
> at -96dB, and speed at 120mbps (with occasional drop to 45mbps).
> These numbers sound about OK for the location (on the other side of my
> apartment, few walls in between). For comparison, if I position my
> MacBook at same location (right next to my Linux box), AP reports
> signal from its AirPort card at about -60dB and speed in about 100mbps
> range and no drops.
The Linux regulatory code only relies on the Country IE from the AP you
decide to associate to, that's it. Then, as for all the regulatory stuff
popping out once you are associated, its happening because as I see it
you are being disconnected from the AP. The Linux regulatory code will
reset the regulatory settings after you disconnect from an AP.
The disconnect issues should not be regularory related from what I see.
Seems like a general disconnect issue with your driver.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Felix Fietkau @ 2011-01-07 2:45 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1294361165-15308-3-git-send-email-greearb@candelatech.com>
On 2011-01-06 5:46 PM, greearb@candelatech.com wrote:
> From: Ben Greear<greearb@candelatech.com>
>
> The stations hold the ath_node, which holds the tid
> and other xmit logic structures. In order to debug
> stuck xmit logic, we need a way to print out the tid
> state for the stations.
>
> Signed-off-by: Ben Greear<greearb@candelatech.com>
I really don't like the array with the hardcoded size. How about just
adding a struct list_head to the ath_node struct and tracking that?
- Felix
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Ben Greear @ 2011-01-07 2:45 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTikjjKe96Ok09Yz1R_nqsoO+n-9X-abeF8VUoOwQ@mail.gmail.com>
On 01/06/2011 06:30 PM, Luis R. Rodriguez wrote:
> On Thu, Jan 6, 2011 at 4:46 PM,<greearb@candelatech.com> wrote:
>> +#define ATH9K_MAX_STATIONS 1024
>
> How about making this a Kconfig with a default to a value of the known
> (by you) max workable number of STAs that one can use on ath9k, which
> is modifiable to other values by power of two up to 1024. Advise in
> the kconfig that if more STAs are used then some issue may arise but
> should be reported (so the issue can be fixed). This way by default
> normal users (you're not normal) won't enable> max known workable
> stable number of STAs on ath9k.
This is just for debugging at this point. It wastes a bit of memory
when debugfs is enabled, but otherwise doesn't affect anything. It's
not even really a problem if there are more stations than fit in
the array.
I can reproduce all my problems with < 128, so if you'd prefer
the number be smaller, that's fine with me. I don't think it's
worth a configurable value, however.
Thanks,
Ben
>
> Luis
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Ben Greear @ 2011-01-07 2:48 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4D267E47.6050408@openwrt.org>
On 01/06/2011 06:45 PM, Felix Fietkau wrote:
> On 2011-01-06 5:46 PM, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> The stations hold the ath_node, which holds the tid
>> and other xmit logic structures. In order to debug
>> stuck xmit logic, we need a way to print out the tid
>> state for the stations.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
> I really don't like the array with the hardcoded size. How about just adding a struct list_head to the ath_node struct and tracking that?
I can do that..would probably want a pointer back from the ath_node to it's STA struct
as well.
I'll re-work the patch to use a list.
Thanks,
Ben
>
> - Felix
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Luis R. Rodriguez @ 2011-01-07 2:49 UTC (permalink / raw)
To: Ben Greear
Cc: Luis R. Rodriguez, ath9k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org
In-Reply-To: <4D267E4D.7000608@candelatech.com>
On Thu, Jan 06, 2011 at 06:45:33PM -0800, Ben Greear wrote:
> On 01/06/2011 06:30 PM, Luis R. Rodriguez wrote:
> > On Thu, Jan 6, 2011 at 4:46 PM,<greearb@candelatech.com> wrote:
> >> +#define ATH9K_MAX_STATIONS 1024
> >
> > How about making this a Kconfig with a default to a value of the known
> > (by you) max workable number of STAs that one can use on ath9k, which
> > is modifiable to other values by power of two up to 1024. Advise in
> > the kconfig that if more STAs are used then some issue may arise but
> > should be reported (so the issue can be fixed). This way by default
> > normal users (you're not normal) won't enable> max known workable
> > stable number of STAs on ath9k.
>
> This is just for debugging at this point. It wastes a bit of memory
> when debugfs is enabled, but otherwise doesn't affect anything. It's
> not even really a problem if there are more stations than fit in
> the array.
I meant to use the value as a limit on the # of STAs you can create
with one ath9k device. The debugfs can still be used as you did,
only that the limit would come from the kconfig value.
> I can reproduce all my problems with < 128, so if you'd prefer
> the number be smaller, that's fine with me. I don't think it's
> worth a configurable value, however.
I thikn we should limit the # STAs to whatever it is that you can
use in a realiable way, this should be a driver limitation, but
I figured you'd want to configure this to a higher value yourself
for whatever tests you are doing. We should fix it though but at
least other clueless users would not go over stable limit you have
found.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Ben Greear @ 2011-01-07 3:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, ath9k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org
In-Reply-To: <20110107024909.GD20431@tux>
On 01/06/2011 06:49 PM, Luis R. Rodriguez wrote:
> On Thu, Jan 06, 2011 at 06:45:33PM -0800, Ben Greear wrote:
>> On 01/06/2011 06:30 PM, Luis R. Rodriguez wrote:
>>> On Thu, Jan 6, 2011 at 4:46 PM,<greearb@candelatech.com> wrote:
>>>> +#define ATH9K_MAX_STATIONS 1024
>>>
>>> How about making this a Kconfig with a default to a value of the known
>>> (by you) max workable number of STAs that one can use on ath9k, which
>>> is modifiable to other values by power of two up to 1024. Advise in
>>> the kconfig that if more STAs are used then some issue may arise but
>>> should be reported (so the issue can be fixed). This way by default
>>> normal users (you're not normal) won't enable> max known workable
>>> stable number of STAs on ath9k.
>>
>> This is just for debugging at this point. It wastes a bit of memory
>> when debugfs is enabled, but otherwise doesn't affect anything. It's
>> not even really a problem if there are more stations than fit in
>> the array.
>
> I meant to use the value as a limit on the # of STAs you can create
> with one ath9k device. The debugfs can still be used as you did,
> only that the limit would come from the kconfig value.
>
>> I can reproduce all my problems with< 128, so if you'd prefer
>> the number be smaller, that's fine with me. I don't think it's
>> worth a configurable value, however.
>
> I thikn we should limit the # STAs to whatever it is that you can
> use in a realiable way, this should be a driver limitation, but
> I figured you'd want to configure this to a higher value yourself
> for whatever tests you are doing. We should fix it though but at
> least other clueless users would not go over stable limit you have
> found.
I think it's very likely that the problems I find are general issues that
are just much easier to hit with lots of stations. There is probably no
'safe' number of stations...just takes longer to see bugs with
fewer stations.
For instance, you still see the failure-to-stop-DMA errors with a single station, right?
And the tx locking stuff was just easier to exercise with lots of stations,
but it would have been possible to hit it with 2 stations.
The current tx-hang stuff I'm chasing seems like logic bugs in the queueing,
probably nothing in particular about the chipset.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Odd behavior of ssb, b43, b43legacy, and b44
From: Michael Büsch @ 2011-01-07 3:34 UTC (permalink / raw)
To: Larry Finger; +Cc: b43-dev, wireless
In-Reply-To: <4D262109.20504@lwfinger.net>
On Thu, 2011-01-06 at 14:07 -0600, Larry Finger wrote:
> Michael,
>
> On one of my boxes, I have installed two PCI-format BCM43xx cards for testing.
> One is a BCM4306 Rev. 3, which uses b43. The other is a BCM4303, which uses
> b43legacy. The output of lspci -nn for these devices is
>
> 01:09.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g
> Wireless LAN Controller [14e4:4320] (rev 03)
> 01:0a.0 Network controller [0280]: Broadcom Corporation BCM4303 802.11b Wireless
> LAN Controller [14e4:4301] (rev 02)
>
> Upon booting, I noticed the following messages in the log:
>
> b44: b44.c:v2.0
> b44: Invalid MAC address found in EEPROM
> b44 ssb1:1: Problem fetching invariants of chip, aborting
>
> b44: probe of ssb1:1 failed with error -22
>
> As this box does not have a b44 installed, I wondered why this was happening.
> When I unloaded all the drivers and used modprobe to load ssb, I found that b43,
> b43legacy and b44 were all loaded. The console output is
>
> finger@pam:~> lsmod | grep b4 <== none loaded
> finger@pam:~> sudo modprobe -v ssb <== load ssb
> insmod /lib/modules/2.6.37-wl+/kernel/drivers/ssb/ssb.ko
>
> The above looks normal, but look at what is now resident!
>
> finger@pam:~> lsmod | grep b4
> b43legacy 115302 0
> b44 28767 0
> b43 174321 0
> ssb 38157 3 b43legacy,b44,b43
> mac80211 266240 2 b43legacy,b43
> cfg80211 161930 3 b43legacy,b43,mac80211
>
> Any idea why loading ssb should silently load b43legacy AND b44? Any ideas on
> where to look?
>
> Thanks,
>
> Larry
>
Does one of these wireless cards have a dangling ethernet core? I would
not be surprised...
--
Greetings Michael.
^ permalink raw reply
* Re: Odd behavior of ssb, b43, b43legacy, and b44
From: Larry Finger @ 2011-01-07 4:31 UTC (permalink / raw)
To: Michael Büsch; +Cc: b43-dev, wireless
In-Reply-To: <1294371276.15564.0.camel@maggie>
On 01/06/2011 09:34 PM, Michael Büsch wrote:
>
> Does one of these wireless cards have a dangling ethernet core? I would
> not be surprised...
Yes. The core scan for the BCM4303 is as follows:
ssb: Core 0 found: IEEE 802.11 (cc 0x812, rev 0x02, vendor 0x4243)
ssb: Core 1 found: PCMCIA (cc 0x80D, rev 0x00, vendor 0x4243)
ssb: Core 2 found: Fast Ethernet (cc 0x806, rev 0x02, vendor 0x4243)
ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243)
ssb: Core 4 found: PCI (cc 0x804, rev 0x03, vendor 0x4243)
ssb: Sonics Silicon Backplane found on PCI device 0000:01:09.0
Larry
^ permalink raw reply
* [PATCH v2 3/3] ath9k: Keep track of stations for debugfs.
From: greearb @ 2011-01-07 4:49 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Ben Greear
From: Ben Greear <greearb@candelatech.com>
The stations hold the ath_node, which holds the tid
and other xmit logic structures. In order to debug
stuck xmit logic, we need a way to print out the tid
state for the stations.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v1 -> v2: Use linked list instead of array. Protect with spinlock.
:100644 100644 deda815... 3f5c513... M drivers/net/wireless/ath/ath9k/ath9k.h
:100644 100644 faf84e4... 650f00f... M drivers/net/wireless/ath/ath9k/debug.c
:100644 100644 23b2998... 59c01ca... M drivers/net/wireless/ath/ath9k/init.c
:100644 100644 b716ffb... 8684afa... M drivers/net/wireless/ath/ath9k/main.c
drivers/net/wireless/ath/ath9k/ath9k.h | 7 ++-
drivers/net/wireless/ath/ath9k/debug.c | 94 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath9k/init.c | 4 ++
drivers/net/wireless/ath/ath9k/main.c | 13 +++++
4 files changed, 115 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index deda815..3f5c513 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -254,7 +254,10 @@ struct ath_atx_tid {
};
struct ath_node {
- struct ath_common *common;
+#ifdef CONFIG_ATH9K_DEBUGFS
+ struct list_head list; /* for sc->nodes */
+ struct ieee80211_sta *sta; /* station struct we're part of */
+#endif
struct ath_atx_tid tid[WME_NUM_TID];
struct ath_atx_ac ac[WME_NUM_AC];
u16 maxampdu;
@@ -624,6 +627,8 @@ struct ath_softc {
#ifdef CONFIG_ATH9K_DEBUGFS
struct ath9k_debug debug;
+ spinlock_t nodes_lock;
+ struct list_head nodes; /* basically, stations */
#endif
struct ath_beacon_config cur_beacon_conf;
struct delayed_work tx_complete_work;
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index faf84e4..650f00f 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -587,6 +587,8 @@ static const struct file_operations fops_wiphy = {
sc->debug.stats.txstats[WME_AC_BK].elem, \
sc->debug.stats.txstats[WME_AC_VI].elem, \
sc->debug.stats.txstats[WME_AC_VO].elem); \
+ if (len >= size) \
+ goto done; \
} while(0)
#define PRX(str, elem) \
@@ -597,6 +599,8 @@ do { \
(unsigned int)(sc->tx.txq[WME_AC_BK].elem), \
(unsigned int)(sc->tx.txq[WME_AC_VI].elem), \
(unsigned int)(sc->tx.txq[WME_AC_VO].elem)); \
+ if (len >= size) \
+ goto done; \
} while(0)
#define PRQLE(str, elem) \
@@ -607,6 +611,8 @@ do { \
list_empty(&sc->tx.txq[WME_AC_BK].elem), \
list_empty(&sc->tx.txq[WME_AC_VI].elem), \
list_empty(&sc->tx.txq[WME_AC_VO].elem)); \
+ if (len >= size) \
+ goto done; \
} while (0)
static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
@@ -614,7 +620,7 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
{
struct ath_softc *sc = file->private_data;
char *buf;
- unsigned int len = 0, size = 4000;
+ unsigned int len = 0, size = 8000;
int i;
ssize_t retval = 0;
char tmp[32];
@@ -623,7 +629,10 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
if (buf == NULL)
return -ENOMEM;
- len += sprintf(buf, "%30s %10s%10s%10s\n\n", "BE", "BK", "VI", "VO");
+ len += sprintf(buf, "Num-Tx-Queues: %i tx-queues-setup: 0x%x\n"
+ "%30s %10s%10s%10s\n\n",
+ ATH9K_NUM_TX_QUEUES, sc->tx.txqsetup,
+ "BE", "BK", "VI", "VO");
PR("MPDUs Queued: ", queued);
PR("MPDUs Completed: ", completed);
@@ -644,6 +653,14 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
PR("hw-put-tx-buf: ", puttxbuf);
PR("hw-tx-start: ", txstart);
PR("hw-tx-proc-desc: ", txprocdesc);
+ len += snprintf(buf + len, size - len,
+ "%s%11p%11p%10p%10p\n", "txq-memory-address:",
+ &(sc->tx.txq[WME_AC_BE]),
+ &(sc->tx.txq[WME_AC_BK]),
+ &(sc->tx.txq[WME_AC_VI]),
+ &(sc->tx.txq[WME_AC_VO]));
+ if (len >= size)
+ goto done;
PRX("axq-qnum: ", axq_qnum);
PRX("axq-depth: ", axq_depth);
@@ -661,6 +678,68 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
snprintf(tmp, sizeof(tmp) - 1, "txq_fifo[%i] empty: ", i);
PRQLE(tmp, txq_fifo[i]);
}
+
+done:
+ if (len > size)
+ len = size;
+
+ retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ kfree(buf);
+
+ return retval;
+}
+
+static ssize_t read_file_stations(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath_softc *sc = file->private_data;
+ char *buf;
+ unsigned int len = 0, size = 64000;
+ struct ath_node *an = NULL;
+ ssize_t retval = 0;
+ int q;
+
+ buf = kzalloc(size, GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
+ len += snprintf(buf + len, size - len,
+ "Stations:\n"
+ " tid: addr sched paused buf_q-empty an ac\n"
+ " ac: addr sched tid_q-empty txq\n");
+
+ spin_lock(&sc->nodes_lock);
+ list_for_each_entry(an, &sc->nodes, list) {
+ len += snprintf(buf + len, size - len,
+ "%pM\n", an->sta->addr);
+ if (len >= size)
+ goto done;
+
+ for (q = 0; q < WME_NUM_TID; q++) {
+ struct ath_atx_tid *tid = &(an->tid[q]);
+ len += snprintf(buf + len, size - len,
+ " tid: %p %s %s %i %p %p\n",
+ tid, tid->sched ? "sched" : "idle",
+ tid->paused ? "paused" : "running",
+ list_empty(&tid->buf_q),
+ tid->an, tid->ac);
+ if (len >= size)
+ goto done;
+ }
+
+ for (q = 0; q < WME_NUM_AC; q++) {
+ struct ath_atx_ac *ac = &(an->ac[q]);
+ len += snprintf(buf + len, size - len,
+ " ac: %p %s %i %p\n",
+ ac, ac->sched ? "sched" : "idle",
+ list_empty(&ac->tid_q), ac->txq);
+ if (len >= size)
+ goto done;
+ }
+ }
+
+done:
+ spin_unlock(&sc->nodes_lock);
if (len > size)
len = size;
@@ -708,6 +787,13 @@ static const struct file_operations fops_xmit = {
.llseek = default_llseek,
};
+static const struct file_operations fops_stations = {
+ .read = read_file_stations,
+ .open = ath9k_debugfs_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
static ssize_t read_file_recv(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -945,6 +1031,10 @@ int ath9k_init_debug(struct ath_hw *ah)
sc, &fops_xmit))
goto err;
+ if (!debugfs_create_file("stations", S_IRUSR, sc->debug.debugfs_phy,
+ sc, &fops_stations))
+ goto err;
+
if (!debugfs_create_file("recv", S_IRUSR, sc->debug.debugfs_phy,
sc, &fops_recv))
goto err;
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 23b2998..59c01ca 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -559,6 +559,10 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
spin_lock_init(&sc->sc_serial_rw);
spin_lock_init(&sc->sc_pm_lock);
mutex_init(&sc->mutex);
+#ifdef CONFIG_ATH9K_DEBUGFS
+ spin_lock_init(&sc->nodes_lock);
+ INIT_LIST_HEAD(&sc->nodes);
+#endif
tasklet_init(&sc->intr_tq, ath9k_tasklet, (unsigned long)sc);
tasklet_init(&sc->bcon_tasklet, ath_beacon_tasklet,
(unsigned long)sc);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index b716ffb..8684afa 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -545,6 +545,12 @@ static void ath_node_attach(struct ath_softc *sc, struct ieee80211_sta *sta)
struct ath_hw *ah = sc->sc_ah;
an = (struct ath_node *)sta->drv_priv;
+#ifdef CONFIG_ATH9K_DEBUGFS
+ spin_lock(&sc->nodes_lock);
+ list_add(&an->list, &sc->nodes);
+ spin_unlock(&sc->nodes_lock);
+ an->sta = sta;
+#endif
if ((ah->caps.hw_caps) & ATH9K_HW_CAP_APM)
sc->sc_flags |= SC_OP_ENABLE_APM;
@@ -560,6 +566,13 @@ static void ath_node_detach(struct ath_softc *sc, struct ieee80211_sta *sta)
{
struct ath_node *an = (struct ath_node *)sta->drv_priv;
+#ifdef CONFIG_ATH9K_DEBUGFS
+ spin_lock(&sc->nodes_lock);
+ list_del(&an->list);
+ spin_unlock(&sc->nodes_lock);
+ an->sta = NULL;
+#endif
+
if (sc->sc_flags & SC_OP_TXAGGR)
ath_tx_node_cleanup(sc, an);
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH] mwifiex: remove struct ieee_types_erp_info
From: Bing Zhao @ 2011-01-07 4:59 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Johannes Berg, Amitkumar Karwar, Kiran Divekar,
Frank Huang, Bing Zhao
This structure is not necessary.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
---
drivers/net/wireless/mwifiex/ieee.h | 6 ------
drivers/net/wireless/mwifiex/scan.c | 5 +----
2 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/ieee.h b/drivers/net/wireless/mwifiex/ieee.h
index 70af50c..2282c0c 100644
--- a/drivers/net/wireless/mwifiex/ieee.h
+++ b/drivers/net/wireless/mwifiex/ieee.h
@@ -93,12 +93,6 @@ union ieee_types_phy_param_set {
struct ieee_types_ds_param_set ds_param_set;
} __packed;
-struct ieee_types_erp_info {
- u8 element_id;
- u8 len;
- u8 erp_flags;
-} __packed;
-
struct ieee_types_assoc_rsp {
__le16 cap_info_bitmap;
__le16 status_code;
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index 104589e..83e466e 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -1348,8 +1348,6 @@ mwifiex_interpret_bss_desc_with_ie(struct mwifiex_adapter *adapter,
u16 beacon_size;
u8 found_data_rate_ie;
u32 bytes_left_for_current_beacon;
- struct ieee_types_erp_info *erp_info;
-
struct ieee_types_vendor_specific *vendor_ie;
const u8 wpa_oui[4] = { 0x00, 0x50, 0xf2, 0x01 };
const u8 wmm_oui[4] = { 0x00, 0x50, 0xf2, 0x02 };
@@ -1532,8 +1530,7 @@ mwifiex_interpret_bss_desc_with_ie(struct mwifiex_adapter *adapter,
break;
case WLAN_EID_ERP_INFO:
- erp_info = (struct ieee_types_erp_info *) current_ptr;
- bss_entry->erp_flags = erp_info->erp_flags;
+ bss_entry->erp_flags = *(current_ptr + 2);
break;
case WLAN_EID_EXT_SUPP_RATES:
--
1.7.0.2
^ permalink raw reply related
* [PATCH] cfg80211: Extend channel to frequency mapping for 802.11j
From: Bruno Randolf @ 2011-01-07 5:26 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.
This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
include/net/cfg80211.h | 3 ++-
net/mac80211/ibss.c | 3 ++-
net/mac80211/mesh.c | 2 +-
net/mac80211/mlme.c | 8 +++++---
net/mac80211/scan.c | 3 ++-
net/wireless/reg.c | 6 +++---
net/wireless/util.c | 36 ++++++++++++++++++++++--------------
net/wireless/wext-compat.c | 5 ++++-
8 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bcc9f44..cfaac36 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1788,8 +1788,9 @@ static inline void *wdev_priv(struct wireless_dev *wdev)
/**
* ieee80211_channel_to_frequency - convert channel number to frequency
* @chan: channel number
+ * @band: band, necessary due to channel number overlap
*/
-extern int ieee80211_channel_to_frequency(int chan);
+extern int ieee80211_channel_to_frequency(int chan, enum ieee80211_band band);
/**
* ieee80211_frequency_to_channel - convert frequency to channel number
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 53c7077..775fb63 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -270,7 +270,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
enum ieee80211_band band = rx_status->band;
if (elems->ds_params && elems->ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems->ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems->ds_params[0],
+ band);
else
freq = rx_status->freq;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index ca3af46..1430cdc 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -574,7 +574,7 @@ static void ieee80211_mesh_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
&elems);
if (elems.ds_params && elems.ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems.ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems.ds_params[0], band);
else
freq = rx_status->freq;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 45fbb9e..33bd6d4 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -176,7 +176,7 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
/* check that channel matches the right operating channel */
if (local->hw.conf.channel->center_freq !=
- ieee80211_channel_to_frequency(hti->control_chan))
+ ieee80211_channel_to_frequency(hti->control_chan, sband->band))
enable_ht = false;
if (enable_ht) {
@@ -429,7 +429,8 @@ void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
container_of((void *)bss, struct cfg80211_bss, priv);
struct ieee80211_channel *new_ch;
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- int new_freq = ieee80211_channel_to_frequency(sw_elem->new_ch_num);
+ int new_freq = ieee80211_channel_to_frequency(sw_elem->new_ch_num,
+ cbss->channel->band);
ASSERT_MGD_MTX(ifmgd);
@@ -1519,7 +1520,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
}
if (elems->ds_params && elems->ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems->ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems->ds_params[0],
+ rx_status->band);
else
freq = rx_status->freq;
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index fb274db..1ef73be 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -196,7 +196,8 @@ ieee80211_scan_rx(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
ieee802_11_parse_elems(elements, skb->len - baselen, &elems);
if (elems.ds_params && elems.ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems.ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems.ds_params[0],
+ rx_status->band);
else
freq = rx_status->freq;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 37693b6..c565689 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1801,9 +1801,9 @@ void regulatory_hint_disconnect(void)
static bool freq_is_chan_12_13_14(u16 freq)
{
- if (freq == ieee80211_channel_to_frequency(12) ||
- freq == ieee80211_channel_to_frequency(13) ||
- freq == ieee80211_channel_to_frequency(14))
+ if (freq == ieee80211_channel_to_frequency(12, IEEE80211_BAND_2GHZ) ||
+ freq == ieee80211_channel_to_frequency(13, IEEE80211_BAND_2GHZ) ||
+ freq == ieee80211_channel_to_frequency(14, IEEE80211_BAND_2GHZ))
return true;
return false;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 7620ae2..4ed065d 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -29,29 +29,37 @@ ieee80211_get_response_rate(struct ieee80211_supported_band *sband,
}
EXPORT_SYMBOL(ieee80211_get_response_rate);
-int ieee80211_channel_to_frequency(int chan)
+int ieee80211_channel_to_frequency(int chan, enum ieee80211_band band)
{
- if (chan < 14)
- return 2407 + chan * 5;
-
- if (chan == 14)
- return 2484;
-
- /* FIXME: 802.11j 17.3.8.3.2 */
- return (chan + 1000) * 5;
+ /* see 802.11 17.3.8.3.2 and Annex J
+ * there are overlapping channel numbers in 5GHz and 2GHz bands */
+ if (band == IEEE80211_BAND_5GHZ) {
+ if (chan >= 182 && chan <= 196)
+ return 4000 + chan * 5;
+ else
+ return 5000 + chan * 5;
+ } else { /* IEEE80211_BAND_2GHZ */
+ if (chan == 14)
+ return 2484;
+ else if (chan < 14)
+ return 2407 + chan * 5;
+ else
+ return 0; /* not supported */
+ }
}
EXPORT_SYMBOL(ieee80211_channel_to_frequency);
int ieee80211_frequency_to_channel(int freq)
{
+ /* see 802.11 17.3.8.3.2 and Annex J */
if (freq == 2484)
return 14;
-
- if (freq < 2484)
+ else if (freq < 2484)
return (freq - 2407) / 5;
-
- /* FIXME: 802.11j 17.3.8.3.2 */
- return freq/5 - 1000;
+ else if (freq >= 4910 && freq <= 4980)
+ return (freq - 4000) / 5;
+ else
+ return (freq - 5000) / 5;
}
EXPORT_SYMBOL(ieee80211_frequency_to_channel);
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 3e5dbd4..7f1f4ec 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -267,9 +267,12 @@ int cfg80211_wext_freq(struct wiphy *wiphy, struct iw_freq *freq)
* -EINVAL for impossible things.
*/
if (freq->e == 0) {
+ enum ieee80211_band band = IEEE80211_BAND_2GHZ;
if (freq->m < 0)
return 0;
- return ieee80211_channel_to_frequency(freq->m);
+ if (freq->m > 14)
+ band = IEEE80211_BAND_5GHZ;
+ return ieee80211_channel_to_frequency(freq->m, band);
} else {
int i, div = 1000000;
for (i = 0; i < freq->e; i++)
^ permalink raw reply related
* [PATCH 1/4] iw: survey: Mark frequency in use
From: Bruno Randolf @ 2011-01-07 6:00 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
Survey: Mark frequency in use according to NL80211_SURVEY_INFO_IN_USE.
This patch comes from OpenWRT. Original author: Felix Fietkau
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
survey.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/survey.c b/survey.c
index f9f2508..83c54b3 100644
--- a/survey.c
+++ b/survey.c
@@ -44,8 +44,9 @@ static int print_survey_handler(struct nl_msg *msg, void *arg)
}
if (sinfo[NL80211_SURVEY_INFO_FREQUENCY])
- printf("\tfrequency:\t%u MHz\n",
- nla_get_u32(sinfo[NL80211_SURVEY_INFO_FREQUENCY]));
+ printf("\tfrequency:\t%u MHz%s\n",
+ nla_get_u32(sinfo[NL80211_SURVEY_INFO_FREQUENCY]),
+ sinfo[NL80211_SURVEY_INFO_IN_USE] ? " [in use]" : "");
if (sinfo[NL80211_SURVEY_INFO_NOISE])
printf("\tnoise:\t\t%d dBm\n",
(int8_t)nla_get_u8(sinfo[NL80211_SURVEY_INFO_NOISE]));
^ permalink raw reply related
* [PATCH 2/4] iw: Add channel busy time to survey
From: Bruno Randolf @ 2011-01-07 6:00 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
In-Reply-To: <20110107060025.21507.11061.stgit@localhost6.localdomain6>
Print channel busy time in survey dump.
This patch comes from OpenWRT. Original author: Felix Fietkau.
Fixed up for unsigned values.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
survey.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/survey.c b/survey.c
index 83c54b3..e71d21b 100644
--- a/survey.c
+++ b/survey.c
@@ -44,12 +44,27 @@ static int print_survey_handler(struct nl_msg *msg, void *arg)
}
if (sinfo[NL80211_SURVEY_INFO_FREQUENCY])
- printf("\tfrequency:\t%u MHz%s\n",
+ printf("\tfrequency:\t\t\t%u MHz%s\n",
nla_get_u32(sinfo[NL80211_SURVEY_INFO_FREQUENCY]),
sinfo[NL80211_SURVEY_INFO_IN_USE] ? " [in use]" : "");
if (sinfo[NL80211_SURVEY_INFO_NOISE])
- printf("\tnoise:\t\t%d dBm\n",
+ printf("\tnoise:\t\t\t\t%d dBm\n",
(int8_t)nla_get_u8(sinfo[NL80211_SURVEY_INFO_NOISE]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME])
+ printf("\tchannel active time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_BUSY])
+ printf("\tchannel busy time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_BUSY]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_EXT_BUSY])
+ printf("\textension channel busy time:\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_EXT_BUSY]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_RX])
+ printf("\tchannel receive time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_RX]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_TX])
+ printf("\tchannel transmit time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_TX]));
return NL_SKIP;
}
^ permalink raw reply related
* [PATCH 3/4] iw: add multicast rates to IBSS join
From: Bruno Randolf @ 2011-01-07 6:00 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
In-Reply-To: <20110107060025.21507.11061.stgit@localhost6.localdomain6>
Add multicast rates to IBSS join command.
This patch comes from OpenWRT. Original author: Felix Fietkau.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
ibss.c | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/ibss.c b/ibss.c
index 84ea7f2..ca8a4ec 100644
--- a/ibss.c
+++ b/ibss.c
@@ -95,6 +95,20 @@ static int join_ibss(struct nl80211_state *state,
argc--;
}
+ /* multicast rate */
+ if (argc > 1 && strcmp(argv[0], "mcast-rate") == 0) {
+ argv++;
+ argc--;
+
+ rate = strtod(argv[0], &end);
+ if (*end != '\0')
+ return 1;
+
+ NLA_PUT_U32(msg, NL80211_ATTR_MCAST_RATE, (int) rate * 10);
+ argv++;
+ argc--;
+ }
+
if (!argc)
return 0;
@@ -120,12 +134,13 @@ COMMAND(ibss, leave, NULL,
NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
"Leave the current IBSS cell.");
COMMAND(ibss, join,
- "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [beacon-interval "
- "<TU>] [basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
+ "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [beacon-interval <TU>]"
+ " [basic-rates <rate in Mbps,rate2,...>] [mcast-rate <rate in Mbps>] "
+ "[key d:0:abcde]",
NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
"Join the IBSS cell with the given SSID, if it doesn't exist create\n"
"it on the given frequency. When fixed frequency is requested, don't\n"
"join/create a cell on a different frequency. When a fixed BSSID is\n"
"requested use that BSSID and do not adopt another cell's BSSID even\n"
"if it has higher TSF and the same SSID. If an IBSS is created, create\n"
- "it with the specified basic-rates and beacon-interval (in TU).");
+ "it with the specified basic-rates, multicast-rate and beacon-interval.");
^ permalink raw reply related
* [PATCH 4/4] iw: Add signal average to station dump information
From: Bruno Randolf @ 2011-01-07 6:00 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
In-Reply-To: <20110107060025.21507.11061.stgit@localhost6.localdomain6>
Print station signal average in station dump.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
station.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/station.c b/station.c
index be2301f..6581d50 100644
--- a/station.c
+++ b/station.c
@@ -107,6 +107,9 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
if (sinfo[NL80211_STA_INFO_SIGNAL])
printf("\n\tsignal: \t%d dBm",
(int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_SIGNAL]));
+ if (sinfo[NL80211_STA_INFO_SIGNAL_AVG])
+ printf("\n\tsignal avg:\t%d dBm",
+ (int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_SIGNAL_AVG]));
if (sinfo[NL80211_STA_INFO_TX_BITRATE]) {
if (nla_parse_nested(rinfo, NL80211_RATE_INFO_MAX,
^ permalink raw reply related
* Re: [PATCH 2/3] ath9k: Re-start xmit logic in xmit watchdog timer.
From: Vasanthakumar Thiagarajan @ 2011-01-07 6:51 UTC (permalink / raw)
To: greearb@candelatech.com
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
In-Reply-To: <1294361165-15308-2-git-send-email-greearb@candelatech.com>
On Fri, Jan 07, 2011 at 06:16:04AM +0530, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> We should not get to this state, but we do. What is
> worse, many times the xmit logic still will not start,
> probably due to tids being paused when they shouldn't be.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>
> NOTE: This needs review. It might be too much of a hack
> for upstream code, and at best it works around a small part
> of the problem.
>
> :100644 100644 3aae523... 547fb44... M drivers/net/wireless/ath/ath9k/xmit.c
> drivers/net/wireless/ath/ath9k/xmit.c | 21 +++++++++++++++++++++
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index 3aae523..547fb44 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -2110,6 +2110,27 @@ static void ath_tx_complete_poll_work(struct work_struct *work)
> } else {
> txq->axq_tx_inprogress = true;
> }
> + } else {
> + /* If the queue has pending buffers, then it
> + * should be doing tx work (and have axq_depth).
> + * Shouldn't get to this state I think..but
> + * perhaps we do.
> + */
> + if (!list_empty(&txq->axq_acq)) {
> + ath_err(ath9k_hw_common(sc->sc_ah),
> + "txq: %p axq_qnum: %i,"
> + " axq_link: %p"
> + " pending frames: %i"
> + " axq_acq is not empty, but"
> + " axq_depth is zero. Calling"
> + " ath_txq_schedule to restart"
> + " tx logic.\n",
> + txq, txq->axq_qnum,
> + txq->axq_link,
> + txq->pending_frames);
> + ATH_DBG_WARN_ON_ONCE(1);
> + ath_txq_schedule(sc, txq);
NAK. This complete work monitors the hw q periodically and does a reset if a
hang is detected. This work is no way meant to schedule aggr. This
change really does not make any sense. Scheduling a tid periodically
would introduce reordering issues especially when there are more
retries.
Vasanth
^ permalink raw reply
* Kernel crash on ath9k module unload, wireless-testing-2.6.37
From: Ben Greear @ 2011-01-07 6:59 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
I had 60 station interfaces configured on ath9k, and unloaded
the modules. I got this crash. It may be of interest that 00100100
is the list poison. This seems to be a rare bug, as I've unloaded modules
around 20 times in the last few days and this is the first time I saw it.
I have seen this in the past (around first of December I think) as well,
so it's not a new bug.
The gdb output for the crash site doesn't give me much in
the way of ideas, but maybe the skb is stale memory and something
else has acquired it and started using it?
(gdb) l *(ieee80211_rx+0xf7)
0x14a40 is in ieee80211_rx (/home/greearb/git/linux.wireless-testing/net/mac80211/rx.c:2887).
2882 goto drop;
2883 rate = &sband->bitrates[status->rate_idx];
2884 }
2885 }
2886
2887 status->rx_flags = 0;
2888
2889 /*
2890 * key references and virtual interfaces are protected using RCU
2891 * and this requires that we are in a read-side RCU section during
(gdb) l *(ieee80211_rx+0x7ac)
0x150f5 is in ieee80211_rx (/home/greearb/git/linux.wireless-testing/arch/x86/include/asm/processor.h:837).
832 * It's not worth to care about 3dnow prefetches for the K6
833 * because they are microcoded there and very slow.
834 */
835 static inline void prefetch(const void *x)
836 {
837 alternative_input(BASE_PREFETCH,
838 "prefetchnta (%1)",
839 X86_FEATURE_XMM,
840 "r" (x));
841 }
(gdb) l *(ieee80211_rx+0x853)
0x1519c is in ieee80211_process_measurement_req (/home/greearb/git/linux.wireless-testing/net/mac80211/spectmgmt.c:74).
69 }
70
71 void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
72 struct ieee80211_mgmt *mgmt,
73 size_t len)
74 {
75 /*
76 * Ignoring measurement request is spec violation.
77 * Mandatory measurements must be reported optional
78 * measurements might be refused or reported incapable
BUG: unable to handle kernel paging request at 00100100
IP: [<f952b0d1>] ieee80211_rx+0x7ac/0x853 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/sda1/stat
Modules linked in: michael_mic ath5k arc4 ath9k(-) mac80211 ath9k_common ath9k_hw ath cfg80211 8021q g]
Pid: 25780, comm: ip Tainted: G W 2.6.37-wl+ #62 To be filled by O.E.M./To Be Filled By O.E.M.
EIP: 0060:[<f952b0d1>] EFLAGS: 00010246 CPU: 1
EIP is at ieee80211_rx+0x7ac/0x853 [mac80211]
EAX: 00000001 EBX: de5b35a0 ECX: 00000001 EDX: 78960218
ESI: 00100100 EDI: f58c7e5c EBP: f58c7e6c ESP: f58c7e00
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process ip (pid: 25780, ti=f58c6000 task=a40314e0 task.ti=cfaf6000)
Stack:
00000002 00000001 00000000 f952aa1c 00000020 f58c7e24 7845a85c f5802a80
f58c7e44 f95623c0 e13d8c64 b97b40a0 dfa78d00 b97b40aa e00d4f00 e13d8460
cfebd600 00000000 00000000 00000000 00000010 00000000 00000000 00100100
Call Trace:
[<f952aa1c>] ? ieee80211_rx+0xf7/0x853 [mac80211]
[<7845a85c>] ? trace_hardirqs_on_caller+0xeb/0x125
[<f9553366>] ? ath_rx_send_to_mac80211+0x5a/0x60 [ath9k]
[<f9554ce7>] ? ath_rx_tasklet+0x1318/0x13af [ath9k]
[<7845a405>] ? mark_lock+0x1e/0x1eb
[<7845a619>] ? mark_held_locks+0x47/0x5f
[<7878ebcb>] ? _raw_spin_unlock_irqrestore+0x3c/0x48
[<7845a85c>] ? trace_hardirqs_on_caller+0xeb/0x125
[<7845a8a1>] ? trace_hardirqs_on+0xb/0xd
[<f9552ce1>] ? ath9k_tasklet+0x98/0x12d [ath9k]
[<7845a85c>] ? trace_hardirqs_on_caller+0xeb/0x125
[<7843be09>] ? tasklet_action+0x88/0xe3
[<7843c385>] ? __do_softirq+0x85/0x142
[<7843c300>] ? __do_softirq+0x0/0x142
[<7843c300>] ? __do_softirq+0x0/0x142
<IRQ>
[<7843c1a7>] ? irq_exit+0x35/0x69
[<78404245>] ? do_IRQ+0x8e/0xa2
[<784036ae>] ? common_interrupt+0x2e/0x40
[<7845007b>] ? pm_qos_update_request+0x4b/0x57
[<784b6f41>] ? kmem_cache_alloc+0x81/0xa1
[<784c9aaf>] ? getname+0x1b/0xb8
[<784c9aaf>] ? getname+0x1b/0xb8
[<784b586b>] ? slab_pad_check+0x1e/0xf6
[<784cab08>] ? user_path_at+0x15/0x60
[<784b53f3>] ? check_valid_pointer+0x1c/0x48
[<784b5c34>] ? check_object+0x154/0x185
[<784b6663>] ? free_debug_processing+0x136/0x15b
[<7845a9b8>] ? debug_check_no_locks_freed+0x115/0x12d
[<784c4345>] ? vfs_fstatat+0x2f/0x55
[<7845a8a1>] ? trace_hardirqs_on+0xb/0xd
[<784c444c>] ? vfs_stat+0x1b/0x1d
[<784c4462>] ? sys_stat64+0x14/0x28
[<78478b22>] ? audit_syscall_entry+0x113/0x135
[<7840a3c3>] ? syscall_trace_enter+0xbb/0xcc
[<7878ee55>] ? syscall_call+0x7/0xb
Code: ff 8b 55 c4 31 c9 89 5d d4 89 45 d8 8d 45 cc e8 6a ef ff ff 89 f3 8b 06 89 45 f0 8b 37 e8 38 e5
EIP: [<f952b0d1>] ieee80211_rx+0x7ac/0x853 [mac80211] SS:ESP 0068:f58c7e00
CR2: 0000000000100100
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/3] ath9k: Re-start xmit logic in xmit watchdog timer.
From: Ben Greear @ 2011-01-07 7:16 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
In-Reply-To: <20110107065101.GB13800@vasanth-laptop>
On 01/06/2011 10:51 PM, Vasanthakumar Thiagarajan wrote:
> On Fri, Jan 07, 2011 at 06:16:04AM +0530, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> We should not get to this state, but we do. What is
>> worse, many times the xmit logic still will not start,
>> probably due to tids being paused when they shouldn't be.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>>
>> NOTE: This needs review. It might be too much of a hack
>> for upstream code, and at best it works around a small part
>> of the problem.
>>
>> :100644 100644 3aae523... 547fb44... M drivers/net/wireless/ath/ath9k/xmit.c
>> drivers/net/wireless/ath/ath9k/xmit.c | 21 +++++++++++++++++++++
>> 1 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
>> index 3aae523..547fb44 100644
>> --- a/drivers/net/wireless/ath/ath9k/xmit.c
>> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
>> @@ -2110,6 +2110,27 @@ static void ath_tx_complete_poll_work(struct work_struct *work)
>> } else {
>> txq->axq_tx_inprogress = true;
>> }
>> + } else {
>> + /* If the queue has pending buffers, then it
>> + * should be doing tx work (and have axq_depth).
>> + * Shouldn't get to this state I think..but
>> + * perhaps we do.
>> + */
>> + if (!list_empty(&txq->axq_acq)) {
>> + ath_err(ath9k_hw_common(sc->sc_ah),
>> + "txq: %p axq_qnum: %i,"
>> + " axq_link: %p"
>> + " pending frames: %i"
>> + " axq_acq is not empty, but"
>> + " axq_depth is zero. Calling"
>> + " ath_txq_schedule to restart"
>> + " tx logic.\n",
>> + txq, txq->axq_qnum,
>> + txq->axq_link,
>> + txq->pending_frames);
>> + ATH_DBG_WARN_ON_ONCE(1);
>> + ath_txq_schedule(sc, txq);
>
> NAK. This complete work monitors the hw q periodically and does a reset if a
> hang is detected. This work is no way meant to schedule aggr. This
> change really does not make any sense. Scheduling a tid periodically
> would introduce reordering issues especially when there are more
> retries.
Ok, but if the system is in the state where it hits this code branch, it seems
that no new packets are sent to the chip to be transmitted. I see this,
for instance, in debugfs (with my debugfs patches applied):
axq-qnum: 2 3 1 0
axq-depth: 0 0 0 0
axq-ampdu_depth: 0 0 0 0
axq-stopped 1 0 0 0
tx-in-progress 0 0 0 0
pending-frames 70 0 0 0
txq_headidx: 0 0 0 0
txq_tailidx: 0 0 0 0
axq_q empty: 0 1 1 0
axq_acq empty: 0 1 1 1
txq_fifo_pending: 1 1 1 1
The queue is stopped, axq_acq and axq_q are not empty, there are pending frames,
and no axq-depth. I cannot figure out why the queue is stopped since
it seems it should be running when axq-depth is zero.
Thanks for the review, I'll back this hack out of my testing tree.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Question about ep-n8508
From: Damian Minkov @ 2011-01-07 8:06 UTC (permalink / raw)
To: linux-wireless
Hi,
I recently bought the device EDUP ep-n8508 but I have problems running
it under Ubuntu 10.10, kernel: 2.6.35-24-generic x86_64.
I tried with the drivers provided on the CD coming with the device
(rtl8192CU_linux_v2.0.939.20100726) have no problem compiling and
installing. But after loading the module no network device appears and
a lot of "usb write TimeOut!" in the messages.
Then I tried with latest driver edition from realtek website -
rtl8192CU_linux_v2.0.1212.20101208. Again with same result.
Here is all the output: http://pastebin.com/7xhkzYNC.
I saw there is a similar thread, with similar problems "Question about
Edimax 7811Un", but as I'm new to the list didn't manage to continue
that thread.
Seems a problem with amd64 systems. Is there any workaround? Anything
I can further test to help figuring this out?
Thanks in advance
damencho
^ 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