* [PATCH 09/26] staging: brcm80211: stop using assigned thread priority in fullmac
From: Arend van Spriel @ 2011-10-04 21:18 UTC (permalink / raw)
To: gregkh; +Cc: devel, linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <1317763152-17607-1-git-send-email-arend@broadcom.com>
From: Franky Lin <frankyl@broadcom.com>
Stop assigning priority to watchdog and dpc threads. Remove related
code.
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Reviewed-by: Roland Vossen <rvossen@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c | 60 ++----------------------
1 files changed, 5 insertions(+), 55 deletions(-)
diff --git a/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c b/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c
index 6c2391b..f3e6249 100644
--- a/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c
+++ b/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c
@@ -715,14 +715,6 @@ static int qcount[NUMPRIO];
static int tx_packets[NUMPRIO];
#endif /* BCMDBG */
-/* Watchdog thread priority, -1 to use kernel timer */
-int brcmf_watchdog_prio = 97;
-module_param(brcmf_watchdog_prio, int, 0);
-
-/* DPC thread priority, -1 to use tasklet */
-int brcmf_dpc_prio = 98;
-module_param(brcmf_dpc_prio, int, 0);
-
#define SDIO_DRIVE_STRENGTH 6 /* in milliamps */
#define RETRYCHAN(chan) ((chan) == SDPCM_EVENT_CHANNEL)
@@ -2692,16 +2684,6 @@ static int brcmf_sdbrcm_dpc_thread(void *data)
{
struct brcmf_bus *bus = (struct brcmf_bus *) data;
- /* This thread doesn't need any user-level access,
- * so get rid of all our resources
- */
- if (brcmf_dpc_prio > 0) {
- struct sched_param param;
- param.sched_priority = (brcmf_dpc_prio < MAX_RT_PRIO) ?
- brcmf_dpc_prio : (MAX_RT_PRIO - 1);
- sched_setscheduler(current, SCHED_FIFO, ¶m);
- }
-
allow_signal(SIGTERM);
/* Run until signal received */
while (1) {
@@ -4364,16 +4346,6 @@ brcmf_sdbrcm_watchdog_thread(void *data)
{
struct brcmf_bus *bus = (struct brcmf_bus *)data;
- /* This thread doesn't need any user-level access,
- * so get rid of all our resources
- */
- if (brcmf_watchdog_prio > 0) {
- struct sched_param param;
- param.sched_priority = (brcmf_watchdog_prio < MAX_RT_PRIO) ?
- brcmf_watchdog_prio : (MAX_RT_PRIO - 1);
- sched_setscheduler(current, SCHED_FIFO, ¶m);
- }
-
allow_signal(SIGTERM);
/* Run until signal received */
while (1) {
@@ -4394,7 +4366,7 @@ brcmf_sdbrcm_watchdog(unsigned long data)
{
struct brcmf_bus *bus = (struct brcmf_bus *)data;
- if (brcmf_watchdog_prio >= 0) {
+ if (bus->threads_only) {
if (bus->watchdog_tsk)
complete(&bus->watchdog_wait);
else
@@ -4493,6 +4465,7 @@ void *brcmf_sdbrcm_probe(u16 bus_no, u16 slot, u16 func, uint bustype,
bus->tx_seq = SDPCM_SEQUENCE_WRAP - 1;
bus->usebufpool = false; /* Use bufpool if allocated,
else use locally malloced rxbuf */
+ bus->threads_only = true;
/* attempt to attach to the dongle */
if (!(brcmf_sdbrcm_probe_attach(bus, regsva))) {
@@ -4510,14 +4483,9 @@ void *brcmf_sdbrcm_probe(u16 bus_no, u16 slot, u16 func, uint bustype,
bus->timer.function = brcmf_sdbrcm_watchdog;
/* Initialize thread based operation and lock */
- if ((brcmf_watchdog_prio >= 0) && (brcmf_dpc_prio >= 0)) {
- bus->threads_only = true;
+ if (bus->threads_only) {
sema_init(&bus->sdsem, 1);
- } else {
- bus->threads_only = false;
- }
- if (brcmf_dpc_prio >= 0) {
/* Initialize watchdog thread */
init_completion(&bus->watchdog_wait);
bus->watchdog_tsk = kthread_run(brcmf_sdbrcm_watchdog_thread,
@@ -4527,11 +4495,6 @@ void *brcmf_sdbrcm_probe(u16 bus_no, u16 slot, u16 func, uint bustype,
"brcmf_watchdog thread failed to start\n");
bus->watchdog_tsk = NULL;
}
- } else
- bus->watchdog_tsk = NULL;
-
- /* Set up the bottom half handler */
- if (brcmf_dpc_prio >= 0) {
/* Initialize DPC thread */
init_completion(&bus->dpc_wait);
bus->dpc_tsk = kthread_run(brcmf_sdbrcm_dpc_thread,
@@ -4542,9 +4505,10 @@ void *brcmf_sdbrcm_probe(u16 bus_no, u16 slot, u16 func, uint bustype,
bus->dpc_tsk = NULL;
}
} else {
+ bus->watchdog_tsk = NULL;
+ bus->dpc_tsk = NULL;
tasklet_init(&bus->tasklet, brcmf_sdbrcm_dpc_tasklet,
(unsigned long)bus);
- bus->dpc_tsk = NULL;
}
/* Attach to the brcmf/OS/network interface */
@@ -4613,20 +4577,6 @@ int brcmf_bus_register(void)
{
brcmf_dbg(TRACE, "Enter\n");
- /* Sanity check on the module parameters */
- do {
- /* Both watchdog and DPC as tasklets are ok */
- if ((brcmf_watchdog_prio < 0) && (brcmf_dpc_prio < 0))
- break;
-
- /* If both watchdog and DPC are threads, TX must be deferred */
- if (brcmf_watchdog_prio >= 0 && brcmf_dpc_prio >= 0)
- break;
-
- brcmf_dbg(ERROR, "Invalid module parameters.\n");
- return -EINVAL;
- } while (0);
-
return brcmf_sdio_register();
}
--
1.7.4.1
^ permalink raw reply related
* Re: ath9k: irq storm after suspend/resume
From: Adrian Chadd @ 2011-10-04 21:11 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Mohammed Shafi, linux-wireless
In-Reply-To: <20111004181534.GA1502@ecki>
On 5 October 2011 02:15, Clemens Buchacher <drizzd@aon.at> wrote:
>> Would you mind also printing the contents of AR_IER there? I wonder if
>> AR_IER is incorrectly being enabled.
>
> Not much more helpful, I'm afraid:
>
> AR_IMR: 0x00000000, AR_ISR: 0x00000000, AR_IER: 0x00000000
> AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
> (repeated 109 times)
>
> It seems that at this point the device is in a bad state.
Well, the question now is whether the device itself is actually firing
off interrupts.
>From what you've shown there, the device _isn't_ firing off interrupts
the normal way.
So I wonder if it's the card or whether it's something else (eg the
PCI bus glue.)
Here, you could try inserting this in the SC_OP_INVALID bit, right
after you do some logging. I'm still assuming your AR9285 is somehow
firing off interrupts.
At this point however I'm all just guessing here. It'd be nice to know
whether the device is _really_ sending interrupts or not.
/* Mark _all_ async interrupts as serviced */
REG_WRITE(ah, AR_INTR_ASYNC_CAUSE, 0xffffffff);
REG_READ(ah, AR_INTR_ASYNC_CAUSE);
/* Disable sync interrupt sources */
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, 0);
/* Mark _all_ sync interrupts as serviced */
REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0xffffffff);
REG_READ(ah, AR_INTR_SYNC_CAUSE);
/* Do a reset of the AHB and host interface */
REG_WRITE(ah, AR_RC, AR_RC_AHB | AR_RC_HOSTIF);
DELAY(100);
REG_WRITE(ah, AR_RC, 0);
^ permalink raw reply
* Re: BUG: Soft lockup CPU#0 stuck for 22s! [wpa_supplicant:756]
From: Jamie Kitson @ 2011-10-04 20:59 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <4E8B5886.3010103@lwfinger.net>
> Which variant of the RTL8188CE do you have? Use 'lspci -nn' to tell.
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd.
RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
> Does ARCH have an updated kernel later than 3.0?
Looks like I am using the latest core of 3.0.4, there's 3.0.6 in testing:
http://www.archlinux.org/packages/testing/x86_64/linux/
Might that help?
> What version of wpa-supplicant?
wpa_supplicant v0.7.3
> Are you using NetworkManager? If so, what version? Is your desktop KDE,
> Gnome, or something else? If NM, what applet and version?
>
> If not NM, how do you connect?
I use dwm and wpa_supplicant, no manager.
Thanks, Jamie
^ permalink raw reply
* Re: ath9k: irq storm after suspend/resume
From: Clemens Buchacher @ 2011-10-04 18:36 UTC (permalink / raw)
To: Adrian Chadd; +Cc: Mohammed Shafi, linux-wireless
In-Reply-To: <CAJ-Vmo=sE4KeOp1CKAR5v+Rzm1bm0R=ZvtMvJaE_8Sjn1dOdsw@mail.gmail.com>
On Tue, Oct 04, 2011 at 03:58:09PM +0800, Adrian Chadd wrote:
>
> There's a function further down in the isr routine which checks
> whether the NIC itself posted the interrupt (it checks
> SYNC_CAUSE/ASYNC_CAUSE.) That should cut down the spam quite a
> bit and only log the relevant entries for ath9k.
If I do this no interrupts are logged at all.
In previous traces SYNC_CAUSE became non-zero only because the
debugging output delayed the interrupt handler enough to give the
initialization code a chance to run.
Clemens
^ permalink raw reply
* Re: iwlagn master-2011-10-03 warning on iwl_trans_pcie_tx()
From: Luis R. Rodriguez @ 2011-10-04 19:31 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAB=NE6VjmEhmKqdwWqHz_YxD_iKu9msqDSih3OKh4SYVQXAvjg@mail.gmail.com>
On Tue, Oct 4, 2011 at 12:23 PM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> My iwlagn is pretty useless with my WRT610n
Sorry my AP is actually a E3000 which I think is the next generation
followup of the WRT610n.
Luis
^ permalink raw reply
* iwlagn master-2011-10-03 warning on iwl_trans_pcie_tx()
From: Luis R. Rodriguez @ 2011-10-04 19:23 UTC (permalink / raw)
To: linux-wireless
My iwlagn is pretty useless with my WRT610n when the AP gets busy with
TX/RX. I end up getting this below. I connect to my AP on 2 GHz and
then give up as it stalls there as I try to fire up gmail (while my
home page did load), when I give up I move to 5 GHz and I get similar
stalls and now am just on Ethernet. Behind the scenes I just had
Pandora on Ethernet downloading music as usual and my Galaxy S 4G
phone uploading video/pictures to G+ automatically. I reset my AP two
days ago, same as the broadband modem device.
Oct 4 12:04:03 tux kernel: [ 17.527446] Intel(R) Wireless WiFi Link
AGN driver for Linux, in-tree:
Oct 4 12:04:03 tux kernel: [ 17.527450] Copyright(c) 2003-2011
Intel Corporation
Oct 4 12:04:03 tux kernel: [ 17.527583] iwlwifi 0000:03:00.0: PCI
INT A -> GSI 17 (level, low) -> IRQ 17
Oct 4 12:04:03 tux kernel: [ 17.527592] iwlwifi 0000:03:00.0:
setting latency timer to 64
Oct 4 12:04:03 tux kernel: [ 17.527679] iwlwifi 0000:03:00.0:
pci_resource_len = 0x00002000
Oct 4 12:04:03 tux kernel: [ 17.527681] iwlwifi 0000:03:00.0:
pci_resource_base = ffffc900110b8000
Oct 4 12:04:03 tux kernel: [ 17.527684] iwlwifi 0000:03:00.0: HW
Revision ID = 0x35
Oct 4 12:04:03 tux kernel: [ 17.527784] iwlwifi 0000:03:00.0: irq
43 for MSI/MSI-X
Oct 4 12:04:03 tux kernel: [ 17.527843] iwlwifi 0000:03:00.0:
Detected Intel(R) Centrino(R) Advanced-N 6200 AGN, REV=0x74
Oct 4 12:04:03 tux kernel: [ 17.528112] iwlwifi 0000:03:00.0: L1
Disabled; Enabling L0S
Oct 4 12:04:03 tux kernel: [ 17.549374] iwlwifi 0000:03:00.0:
device EEPROM VER=0x436, CALIB=0x6
Oct 4 12:04:03 tux kernel: [ 17.549378] iwlwifi 0000:03:00.0:
Device SKU: 0X1f0
Oct 4 12:04:03 tux kernel: [ 17.553797] thinkpad_acpi: detected a
8-level brightness capable ThinkPad
Oct 4 12:04:03 tux kernel: [ 17.554661] iwlwifi 0000:03:00.0:
Tunable channels: 13 802.11bg, 24 802.11a channels
Oct 4 12:04:03 tux kernel: [ 17.558683] thinkpad_acpi: radio switch
found; radios are enabled
Oct 4 12:04:03 tux kernel: [ 17.561864] Linux video capture interface: v2.00
Oct 4 12:04:03 tux kernel: [ 17.572663] cfg80211: World regulatory
domain updated:
Oct 4 12:04:03 tux kernel: [ 17.572667] cfg80211: (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Oct 4 12:04:03 tux kernel: [ 17.572670] cfg80211: (2402000 KHz
- 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:04:03 tux kernel: [ 17.572673] cfg80211: (2457000 KHz
- 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:04:03 tux kernel: [ 17.572676] cfg80211: (2474000 KHz
- 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:04:03 tux kernel: [ 17.572678] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:04:03 tux kernel: [ 17.572681] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:04:03 tux kernel: [ 17.584274] iwlwifi 0000:03:00.0:
loaded firmware version 9.221.4.1 build 25532
Oct 4 12:04:06 tux kernel: [ 20.871100] cfg80211: Found new beacon
on frequency: 5745 MHz (Ch 149) on phy0
Oct 4 12:04:07 tux kernel: [ 21.353306] ieee80211 phy0: device now idle
Oct 4 12:04:10 tux kernel: [ 24.127356] IBM TrackPoint firmware:
0x0e, buttons: 3/3
Oct 4 12:04:10 tux kernel: [ 24.386849] input: TPPS/2 IBM
TrackPoint as /devices/platform/i8042/serio1/serio2/input/input11
Oct 4 12:04:20 tux kernel: [ 34.446261] hda-intel: Invalid position
buffer, using LPIB read method instead.
Oct 4 12:04:20 tux kernel: [ 34.460741] hda-intel: Invalid position
buffer, using LPIB read method instead.
Oct 4 12:04:20 tux kernel: [ 34.630865] hda-intel: IRQ timing
workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
Oct 4 12:04:24 tux kernel: [ 38.186368] ieee80211 phy0: device no
longer idle - scanning
Oct 4 12:04:25 tux kernel: [ 39.065708] EXT4-fs (sda1): re-mounted.
Opts: errors=remount-ro,user_xattr,commit=0
Oct 4 12:04:27 tux kernel: [ 41.412585] ieee80211 phy0: device now idle
Oct 4 12:06:44 tux kernel: [ 178.626667] ieee80211 phy0: device no
longer idle - scanning
Oct 4 12:06:47 tux kernel: [ 181.932274] ieee80211 phy0: device now idle
Oct 4 12:06:47 tux kernel: [ 181.965028] ieee80211 phy0: device no
longer idle - working
Oct 4 12:06:48 tux kernel: [ 181.975874] wlan8: authenticate with
68:7f:74:3b:b1:0f (try 1)
Oct 4 12:06:48 tux kernel: [ 181.984961] wlan8: authenticated
Oct 4 12:06:48 tux kernel: [ 181.985029] ieee80211 phy0: Allocated
STA 68:7f:74:3b:b1:0f
Oct 4 12:06:48 tux kernel: [ 181.985033] ieee80211 phy0: Inserted
dummy STA 68:7f:74:3b:b1:0f
Oct 4 12:06:48 tux kernel: [ 181.985857] wlan8: associate with
68:7f:74:3b:b1:0f (try 1)
Oct 4 12:06:48 tux kernel: [ 181.992390] wlan8: RX AssocResp from
68:7f:74:3b:b1:0f (capab=0x411 status=0 aid=2)
Oct 4 12:06:48 tux kernel: [ 181.992395] wlan8: associated
Oct 4 12:06:48 tux kernel: [ 181.994496] ieee80211 phy0: Inserted
STA 68:7f:74:3b:b1:0f
Oct 4 12:06:48 tux kernel: [ 181.994501] ieee80211 phy0: WMM queue=2
aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0 uapsd=0
Oct 4 12:06:48 tux kernel: [ 181.994506] ieee80211 phy0: WMM queue=3
aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0
Oct 4 12:06:48 tux kernel: [ 181.994509] ieee80211 phy0: WMM queue=1
aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0
Oct 4 12:06:48 tux kernel: [ 181.994513] ieee80211 phy0: WMM queue=0
aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0
Oct 4 12:06:48 tux kernel: [ 181.998981] ADDRCONF(NETDEV_CHANGE):
wlan8: link becomes ready
Oct 4 12:06:48 tux kernel: [ 181.999889] Rx A-MPDU request on tid 0 result 0
Oct 4 12:06:54 tux kernel: [ 188.067434] Open BA session requested
for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:06:54 tux kernel: [ 188.101476] activated addBA response
timer on tid 0
Oct 4 12:06:55 tux kernel: [ 189.100782] addBA response timer expired on tid 0
Then I decide to switch to 5 GHz.
Oct 4 12:06:55 tux kernel: [ 189.100806] Tx BA session stop
requested for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:06:59 tux kernel: [ 193.416483] switched off addBA timer for tid 0
Oct 4 12:06:59 tux kernel: [ 193.416488] Aggregation is on for tid 0
Oct 4 12:06:59 tux kernel: [ 193.416635] iwlwifi 0000:03:00.0: Tx
aggregation enabled on ra = 68:7f:74:3b:b1:0f tid = 0
Oct 4 12:06:59 tux kernel: [ 193.416676] ------------[ cut here ]------------
Oct 4 12:06:59 tux kernel: [ 193.416700] WARNING: at
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c:1098
iwl_trans_pcie_tx+0x798/0x7c0 [iwlwifi]()
Oct 4 12:06:59 tux kernel: [ 193.416707] Hardware name: 2518F4U
Oct 4 12:06:59 tux kernel: [ 193.416710] Modules linked in: ppdev
snd_hda_codec_hdmi snd_hda_codec_conexant binfmt_misc joydev
snd_hda_intel uvcvideo snd_hda_codec snd_hwdep videodev
v4l2_compat_ioctl32 snd_pcm iwlwifi btusb thinkpad_acpi mxm_wmi
bluetooth snd_seq_midi snd_rawmidi i915 mac80211 snd_seq_midi_event
snd_seq snd_timer snd_seq_device drm_kms_helper psmouse snd serio_raw
drm cfg80211 snd_page_alloc soundcore nvram i2c_algo_bit intel_agp
intel_gtt tpm_tis tpm tpm_bios video lp parport ahci libahci e1000e
Oct 4 12:06:59 tux kernel: [ 193.416782] Pid: 253, comm: kworker/u:3
Not tainted 3.1.0-rc8-wl+ #23
Oct 4 12:06:59 tux kernel: [ 193.416787] Call Trace:
Oct 4 12:06:59 tux kernel: [ 193.416791] <IRQ>
[<ffffffff8106368f>] warn_slowpath_common+0x7f/0xc0
Oct 4 12:06:59 tux kernel: [ 193.416809] [<ffffffff810636ea>]
warn_slowpath_null+0x1a/0x20
Oct 4 12:06:59 tux kernel: [ 193.416826] [<ffffffffa02cedf8>]
iwl_trans_pcie_tx+0x798/0x7c0 [iwlwifi]
Oct 4 12:06:59 tux kernel: [ 193.416835] [<ffffffff8105b788>] ?
try_to_wake_up+0x248/0x2b0
Oct 4 12:06:59 tux kernel: [ 193.416846] [<ffffffff8115178f>] ?
kmem_cache_alloc+0x11f/0x170
Oct 4 12:06:59 tux kernel: [ 193.416860] [<ffffffffa02bbd07>]
iwlagn_tx_skb+0x467/0x7f0 [iwlwifi]
Oct 4 12:06:59 tux kernel: [ 193.416872] [<ffffffffa02b264a>]
iwlagn_mac_tx+0x1a/0x30 [iwlwifi]
Oct 4 12:06:59 tux kernel: [ 193.416905] [<ffffffffa01a7e56>]
__ieee80211_tx+0x76/0x260 [mac80211]
Oct 4 12:06:59 tux kernel: [ 193.416931] [<ffffffffa01a972c>]
ieee80211_tx+0x8c/0xb0 [mac80211]
Oct 4 12:06:59 tux kernel: [ 193.416941] [<ffffffff8103be19>] ?
default_spin_lock_flags+0x9/0x10
Oct 4 12:06:59 tux kernel: [ 193.416966] [<ffffffffa01aa5dd>]
ieee80211_tx_pending+0x8d/0x250 [mac80211]
Oct 4 12:06:59 tux kernel: [ 193.416974] [<ffffffff8106a39c>]
tasklet_action+0x6c/0x120
Oct 4 12:06:59 tux kernel: [ 193.416981] [<ffffffff8106aaed>]
__do_softirq+0xad/0x1d0
Oct 4 12:06:59 tux kernel: [ 193.416991] [<ffffffff815ba76c>]
call_softirq+0x1c/0x30
Oct 4 12:06:59 tux kernel: [ 193.416995] <EOI>
[<ffffffff810152b5>] do_softirq+0x65/0xa0
Oct 4 12:06:59 tux kernel: [ 193.417007] [<ffffffff8106a6c5>]
local_bh_enable_ip+0x85/0xb0
Oct 4 12:06:59 tux kernel: [ 193.417016] [<ffffffff815b03c9>]
_raw_spin_unlock_bh+0x19/0x20
Oct 4 12:06:59 tux kernel: [ 193.417037] [<ffffffffa018fc8a>]
ieee80211_agg_tx_operational+0xea/0x1b0 [mac80211]
Oct 4 12:06:59 tux kernel: [ 193.417045] [<ffffffff815ad4c9>] ?
printk+0x6c/0x73
Oct 4 12:06:59 tux kernel: [ 193.417066] [<ffffffffa0190844>]
ieee80211_process_addba_resp+0x114/0x150 [mac80211]
Oct 4 12:06:59 tux kernel: [ 193.417090] [<ffffffffa019a6bd>]
ieee80211_iface_work+0x2ed/0x340 [mac80211]
Oct 4 12:06:59 tux kernel: [ 193.417113] [<ffffffffa019a3d0>] ?
ieee80211_teardown_sdata+0xf0/0xf0 [mac80211]
Oct 4 12:06:59 tux kernel: [ 193.417121] [<ffffffff810800a6>]
process_one_work+0x126/0x430
Oct 4 12:06:59 tux kernel: [ 193.417129] [<ffffffff81080e43>]
worker_thread+0x163/0x360
Oct 4 12:06:59 tux kernel: [ 193.417136] [<ffffffff81080ce0>] ?
manage_workers.clone.21+0x240/0x240
Oct 4 12:06:59 tux kernel: [ 193.417144] [<ffffffff81085e16>]
kthread+0x96/0xa0
Oct 4 12:06:59 tux kernel: [ 193.417152] [<ffffffff815ba674>]
kernel_thread_helper+0x4/0x10
Oct 4 12:06:59 tux kernel: [ 193.417161] [<ffffffff81085d80>] ?
flush_kthread_worker+0xb0/0xb0
Oct 4 12:06:59 tux kernel: [ 193.417168] [<ffffffff815ba670>] ?
gs_change+0x13/0x13
Oct 4 12:06:59 tux kernel: [ 193.417174] ---[ end trace 4191e5f5f2031e03 ]---
Oct 4 12:06:59 tux kernel: [ 193.417219] ------------[ cut here ]------------
This repeats itself many many many times. Eventually it manages to associate:
Oct 4 12:06:59 tux kernel: [ 193.450637] Stopping Tx BA session for
68:7f:74:3b:b1:0f tid 0
Oct 4 12:07:00 tux kernel: [ 194.411542] Open BA session requested
for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:07:00 tux kernel: [ 194.467889] activated addBA response
timer on tid 0
Oct 4 12:07:00 tux kernel: [ 194.469733] switched off addBA timer for tid 0
Oct 4 12:07:01 tux kernel: [ 195.907026] iwlwifi 0000:03:00.0: Queue
11 stuck for 2000 ms.
Oct 4 12:07:01 tux kernel: [ 195.907032] iwlwifi 0000:03:00.0:
Current read_ptr 140 write_ptr 208
Oct 4 12:07:01 tux kernel: [ 195.907034] iwlwifi 0000:03:00.0: On
demand firmware reload
Oct 4 12:07:01 tux kernel: [ 195.908336] ieee80211 phy0: Hardware
restart was requested
Oct 4 12:07:01 tux kernel: [ 195.908387] iwlwifi 0000:03:00.0: L1
Disabled; Enabling L0S
Oct 4 12:07:01 tux kernel: [ 195.915015] iwlwifi 0000:03:00.0: Radio
type=0x1-0x3-0x1
Oct 4 12:07:02 tux kernel: [ 196.015278] Tx BA session stop
requested for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:07:02 tux kernel: [ 196.015387] Rx BA session stop
requested for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:07:02 tux kernel: [ 196.015467] Stopping Tx BA session for
68:7f:74:3b:b1:0f tid 0
Oct 4 12:07:02 tux kernel: [ 196.149958] Rx A-MPDU request on tid 0 result 0
Oct 4 12:07:02 tux kernel: [ 196.844265] Open BA session requested
for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:07:02 tux kernel: [ 196.937226] activated addBA response
timer on tid 0
Oct 4 12:07:02 tux kernel: [ 196.939294] switched off addBA timer for tid 0
Oct 4 12:08:31 tux kernel: [ 285.324708] Tx BA session stop
requested for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:08:31 tux kernel: [ 285.324849] Rx BA session stop
requested for 68:7f:74:3b:b1:0f tid 0
Oct 4 12:08:31 tux kernel: [ 285.324857] Stopping Tx BA session for
68:7f:74:3b:b1:0f tid 0
Oct 4 12:08:31 tux kernel: [ 285.346298] wlan8: deauthenticating
from 68:7f:74:3b:b1:0f by local choice (reason=3)
Oct 4 12:08:31 tux kernel: [ 285.612105] iwlwifi 0000:03:00.0:
Unknown encode cipher 6b6b6b6b
Oct 4 12:08:31 tux kernel: [ 285.612122] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612156] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612188] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612220] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612252] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612288] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612325] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612363] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612401] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612470] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612503] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612536] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612574] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612614] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612654] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612693] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612730] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.612768] wlan8: dropped data frame
to not associated station 68:7f:74:3b:b1:0f
a lot more of these...
And then:
Oct 4 12:08:31 tux kernel: [ 285.614430] wlan8: dropped frame to
00:00:00:00:00:00 (unauthorized port)
Oct 4 12:08:31 tux kernel: [ 285.614477] wlan8: dropped frame to
00:00:00:00:00:00 (unauthorized port)
Oct 4 12:08:31 tux kernel: [ 285.706894] ieee80211 phy0: Removed STA
68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.707041] ieee80211 phy0: Destroyed
STA 68:7f:74:3b:b1:0f
Oct 4 12:08:31 tux kernel: [ 285.707073] ieee80211 phy0: device now idle
Oct 4 12:08:31 tux kernel: [ 285.707435] cfg80211: All devices are
disconnected, going to restore regulatory settings
Oct 4 12:08:31 tux kernel: [ 285.707460] cfg80211: Restoring
regulatory settings
Oct 4 12:08:31 tux kernel: [ 285.707513] cfg80211: Calling CRDA to
update world regulatory domain
Oct 4 12:08:31 tux kernel: [ 285.734559] cfg80211: Ignoring
regulatory request Set by core since the driver uses its own custom
regulatory domain
Oct 4 12:08:31 tux kernel: [ 285.734564] cfg80211: World regulatory
domain updated:
Oct 4 12:08:31 tux kernel: [ 285.734566] cfg80211: (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Oct 4 12:08:31 tux kernel: [ 285.734569] cfg80211: (2402000 KHz
- 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:08:31 tux kernel: [ 285.734572] cfg80211: (2457000 KHz
- 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:08:31 tux kernel: [ 285.734575] cfg80211: (2474000 KHz
- 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:08:31 tux kernel: [ 285.734578] cfg80211: (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:08:31 tux kernel: [ 285.734581] cfg80211: (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 4 12:08:31 tux kernel: [ 285.814415] ieee80211 phy0: device no
longer idle - scanning
Oct 4 12:08:35 tux kernel: [ 289.084075] ieee80211 phy0: device now idle
Oct 4 12:08:35 tux kernel: [ 289.117726] ieee80211 phy0: device no
longer idle - working
Oct 4 12:08:35 tux kernel: [ 289.127296] wlan8: authenticate with
68:7f:74:3b:b1:10 (try 1)
Oct 4 12:08:35 tux kernel: [ 289.321657] wlan8: authenticate with
68:7f:74:3b:b1:10 (try 2)
Oct 4 12:08:35 tux kernel: [ 289.322338] wlan8: authenticated
Oct 4 12:08:35 tux kernel: [ 289.322501] ieee80211 phy0: Allocated
STA 68:7f:74:3b:b1:10
Oct 4 12:08:35 tux kernel: [ 289.322510] ieee80211 phy0: Inserted
dummy STA 68:7f:74:3b:b1:10
Oct 4 12:08:35 tux kernel: [ 289.323565] wlan8: associate with
68:7f:74:3b:b1:10 (try 1)
Oct 4 12:08:35 tux kernel: [ 289.324948] wlan8: RX AssocResp from
68:7f:74:3b:b1:10 (capab=0x11 status=0 aid=1)
Oct 4 12:08:35 tux kernel: [ 289.324953] wlan8: associated
Oct 4 12:08:35 tux kernel: [ 289.326652] ieee80211 phy0: Inserted
STA 68:7f:74:3b:b1:10
Oct 4 12:08:35 tux kernel: [ 289.326662] ieee80211 phy0: WMM queue=2
aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0 uapsd=0
Oct 4 12:08:35 tux kernel: [ 289.326671] ieee80211 phy0: WMM queue=3
aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0
Oct 4 12:08:35 tux kernel: [ 289.326680] ieee80211 phy0: WMM queue=1
aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0
Oct 4 12:08:35 tux kernel: [ 289.326688] ieee80211 phy0: WMM queue=0
aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0
Oct 4 12:08:35 tux kernel: [ 289.333572] Rx A-MPDU request on tid 0 result 0
Oct 4 12:08:40 tux kernel: [ 294.005617] Open BA session requested
for 68:7f:74:3b:b1:10 tid 0
Oct 4 12:08:40 tux kernel: [ 294.041539] activated addBA response
timer on tid 0
My 802.11 is useless, so I'm using Ethernet now.
Luis
^ permalink raw reply
* Re: ath9k: irq storm after suspend/resume
From: Clemens Buchacher @ 2011-10-04 18:15 UTC (permalink / raw)
To: Adrian Chadd; +Cc: Mohammed Shafi, linux-wireless
In-Reply-To: <CAJ-Vmo=sE4KeOp1CKAR5v+Rzm1bm0R=ZvtMvJaE_8Sjn1dOdsw@mail.gmail.com>
On Tue, Oct 04, 2011 at 03:58:09PM +0800, Adrian Chadd wrote:
>
> On 3 October 2011 16:48, Clemens Buchacher <drizzd@aon.at> wrote:
>
> > for 1, 2, ..., 99, 128, 256:
> > AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
> > AR_IMR: 0xdeadbeef, AR_ISR: 0xdeadbeef
>
> .. that says some part of the MAC is very asleep. But no interrupt
> cause bits are set. So I bet it's a shared interrupt.
Unfortunately, that's not it. From /proc/interrupts:
CPU0 CPU1 CPU2 CPU3
17: 24958 25047 25012 24984 IO-APIC-fasteoi ath9k
This is right after the IRQ is disabled because of too many
unhandled interrupts.
> > If I suspend/resume first, then load the module, then wait for 500
> > ms after request_irq I get only zeroes, repeated 109 times:
> >
> > for 1, 2, ..., 99, 2^7, 2^8, ..., 2^16:
> > AR_IMR: 0x00000000, AR_ISR: 0x00000000
> > AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
>
> Would you mind also printing the contents of AR_IER there? I wonder if
> AR_IER is incorrectly being enabled.
Not much more helpful, I'm afraid:
AR_IMR: 0x00000000, AR_ISR: 0x00000000, AR_IER: 0x00000000
AR_INTR_SYNC_CAUSE: 0x00000000, AR_INTR_ASYNC_CAUSE: 0x00000000
(repeated 109 times)
It seems that at this point the device is in a bad state.
Clemens
^ permalink raw reply
* Compat-wireless release for 2011-10-04 is baked
From: Compat-wireless cronjob account @ 2011-10-04 19:05 UTC (permalink / raw)
To: linux-wireless
>From git://github.com/mcgrof/compat-wireless
68e98c2..ed03ef8 master -> origin/master
>From git://github.com/mcgrof/compat
f7d5a0c..2239769 master -> origin/master
>From git://github.com/sfrothwell/linux-next
+ 8de4587...8f37235 akpm-end -> origin/akpm-end (forced update)
d5767c5..0f86267 akpm-start -> origin/akpm-start
+ a33a912...db5dbd6 master -> origin/master (forced update)
d5767c5..0f86267 stable -> origin/stable
* [new tag] next-20111004 -> next-20111004
/usr/bin/sha1sum: *.tar.bz2: No such file or directory
compat-wireless code metrics
812940 - Total upstream lines of code being pulled
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
^ permalink raw reply
* Re: BUG: Soft lockup CPU#0 stuck for 22s! [wpa_supplicant:756]
From: Larry Finger @ 2011-10-04 19:03 UTC (permalink / raw)
To: Jamie Kitson; +Cc: linux-wireless
In-Reply-To: <CA+z-pWFvBfvqY9_km8t3Xbmt=2Pw7eJo8T+SyFp=Lv=d1+ZOPw@mail.gmail.com>
On 10/04/2011 01:03 PM, Jamie Kitson wrote:
> Hi,
>
> I get the following error when cold booting, it doesn't seem to happen
> after a restart:
>
> http://www.flickr.com/photos/jamiekitson/6211329161/
>
> I have just moved my installation to a new machine with a:
>
> 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE
> 802.11b/g/n WiFi Adapter (rev 01)
> Subsystem: Realtek Semiconductor Co., Ltd. Device 8195
> Kernel driver in use: rtl8192ce
> Kernel modules: rtl8192ce
>
> Linux jamie-laptop 3.0-ARCH #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST
> 2011 x86_64 Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GenuineIntel
> GNU/Linux
>
> I am reporting it here as I assume it's a rtl8192ce bug, but if not I
> can report it to the wpa_supplicant guys.
The bug is not necessarily caused by rtl8192ce. I have never seen this problem
on my system. I would also expect a stack dump. Anyone know what is needed to
get one here?
I do have some further questions.
Which variant of the RTL8188CE do you have? Use 'lspci -nn' to tell.
Does ARCH have an updated kernel later than 3.0?
What version of wpa-supplicant?
Are you using NetworkManager? If so, what version? Is your desktop KDE, Gnome,
or something else? If NM, what applet and version?
If not NM, how do you connect?
Larry
^ permalink raw reply
* RE: [PATCH] mwifiex: use separate wait queue for each command node
From: Bing Zhao @ 2011-10-04 18:50 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, John W. Linville,
Amitkumar Karwar, Kiran Divekar, Yogesh Powar, Frank Huang
In-Reply-To: <1317709788.3986.0.camel@jlt3.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9o
YW5uZXMgQmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdDQo+IFNlbnQ6IE1v
bmRheSwgT2N0b2JlciAwMywgMjAxMSAxMTozMCBQTQ0KPiBUbzogQmluZyBaaGFvDQo+IENjOiBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IEpvaG4gVy4gTGludmlsbGU7IEFtaXRrdW1h
ciBLYXJ3YXI7IEtpcmFuIERpdmVrYXI7IFlvZ2VzaCBQb3dhcjsNCj4gRnJhbmsgSHVhbmcNCj4g
U3ViamVjdDogUmU6IFtQQVRDSF0gbXdpZmlleDogdXNlIHNlcGFyYXRlIHdhaXQgcXVldWUgZm9y
IGVhY2ggY29tbWFuZCBub2RlDQo+IA0KPiBPbiBNb24sIDIwMTEtMTAtMDMgYXQgMjE6MDggLTA3
MDAsIEJpbmcgWmhhbyB3cm90ZToNCj4gPiBGcm9tOiBBbWl0a3VtYXIgS2Fyd2FyIDxha2Fyd2Fy
QG1hcnZlbGwuY29tPg0KPiA+DQo+ID4gQ3VycmVudGx5IGdsb2JhbCB3YWl0IHF1ZXVlIChhZGFw
dGVyLT5jbWRfd2FpdF9xKSBpcyB1c2VkIGZvcg0KPiA+IHNlbmRpbmcgc3luY2hyb25vdXMgY29t
bWFuZHMgdG8gRlcuIFdoZW4gdHdvIHRocmVhZHMgZW50ZXIgaW4NCj4gPiBtd2lmaWV4X3NlbmRf
Y21kX3N5bmMoKSByb3V0aW5lIGF0IHRoZSBzYW1lIHRpbWUsIGJvdGggdGhlDQo+ID4gdGhyZWFk
cyB3YWl0IGZvciB0aGVpciBjb21tYW5kIHJlc3BvbnNlcy4gVGhleSB3YWtlIHVwDQo+ID4gc2lt
dWx0YW5lb3VzbHkgYWZ0ZXIgZ2V0dGluZyByZXNwb25zZSBvZiAxc3QgY29tbWFuZC4gQWZ0ZXIN
Cj4gPiB0aGlzIHdoZW4gYSB0aHJlYWQgaXMgd2FpdGluZyBmb3IgY29tbWFuZCByZXNwb25zZSBv
ZiAzcmQNCj4gPiBjb21tYW5kLCBpdCB3YWtlcyB1cCBhZnRlciBnZXR0aW5nIHJlc3BvbnNlIG9m
IDJuZCBjb21tYW5kDQo+ID4gYW5kIHNvIG9uLiBUaGVyZWZvcmUgd2UgZG9uJ3Qgd2FpdCBmb3Ig
dGhlIHJlc3BvbnNlIG9mIGxhc3QNCj4gPiBjb21tYW5kKDB4YWEpIGR1cmluZyB1bmxvYWQuIEhl
bmNlIHdoaWxlIG5leHQgdGltZSBsb2FkaW5nIHRoZQ0KPiA+IGRyaXZlciBjb21tYW5kIHRpbWUg
b3V0IGlzIHNlZW4gZm9yIElOSVQgY29tbWFuZC4NCj4gPg0KPiA+IFRoaXMgcHJvYmxlbSBpcyBy
ZXNvbHZlZCBieSBoYXZpbmcgc2VwYXJhdGUgd2FpdCBxdWV1ZSBmb3IgZWFjaA0KPiA+IGNvbW1h
bmQuIFNpbmNlIGRyaXZlciBzZW5kcyBtdWx0aXBsZSBzY2FuIGNvbW1hbmRzIGFzeW5jaHJvbm91
c2x5DQo+ID4gdG8gRlcgZm9yIHNjYW5uaW5nIHRoZSBuZXR3b3JrLCB3ZSB3aWxsIG5lZWQgc2Vw
YXJhdGUgd2FpdCBxdWV1ZQ0KPiA+IGZvciB0aGUgd2hvbGUgc2NhbiBvcGVyYXRpb24uIEVhcmxp
ZXIgdGhlIGdsb2JhbCB3YWl0IHF1ZXVlIHdhcw0KPiA+IGJlaW5nIHVzZWQgZm9yIHNjYW4uDQo+
IA0KPiBJIGNhbid0IHNheSBJIHJlYWxseSBjYXJlIGFib3V0IHRoaXMsIGJ1dCB0aGlzIHNlZW1z
IGNvbXBsZXRlbHkNCj4gcG9pbnRsZXNzLiBBIHdhaXRxdWV1ZSBkb2Vzbid0IGltcGx5IHRoYXQg
anVzdCBhIHNpbmdsZSB0aGluZyBjYW4gYmUNCj4gd2FpdGluZyBvbiBpdCwgc2luY2UgeW91IHNo
b3VsZCBiZSB1c2luZyB3YWl0X2ZvcigpIG1hY3Jvcy4gVGh1cywgYWxsDQo+IHlvdSAqcmVhbGx5
KiBuZWVkIGlzIGEgYml0IGluIHRoZSBjb21tYW5kIHRoYXQgbWFya3MgaXQgYXMgY29tcGxldGVk
LA0KPiBhbmQgdGhlbiB5b3UgdXNlIHRoZSB3YWl0cXVldWUgdG8gd2FpdCBmb3IgdGhhdCBiaXQg
dG8gYmUgc2V0Lg0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudC4NCldpbGwgd29yayBvbiB2MiBw
YXRjaCBhbmQgcmVzdWJtaXQuDQoNClRoYW5rcywNCkJpbmcNCg0KPiANCj4gam9oYW5uZXMNCj4g
DQoNCg==
^ permalink raw reply
* BUG: Soft lockup CPU#0 stuck for 22s! [wpa_supplicant:756]
From: Jamie Kitson @ 2011-10-04 18:03 UTC (permalink / raw)
To: linux-wireless
Hi,
I get the following error when cold booting, it doesn't seem to happen
after a restart:
http://www.flickr.com/photos/jamiekitson/6211329161/
I have just moved my installation to a new machine with a:
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE
802.11b/g/n WiFi Adapter (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. Device 8195
Kernel driver in use: rtl8192ce
Kernel modules: rtl8192ce
Linux jamie-laptop 3.0-ARCH #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST
2011 x86_64 Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GenuineIntel
GNU/Linux
I am reporting it here as I assume it's a rtl8192ce bug, but if not I
can report it to the wpa_supplicant guys.
Thanks, Jamie
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Christian Lamparter @ 2011-10-04 17:49 UTC (permalink / raw)
To: Adrian Chadd
Cc: Zefir Kurtisi, Luis R. Rodriguez, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <CAJ-Vmo=1riCHbC56_UR+EXUrB6T_=_FjTdNKFm6-XuSq2UOTzg@mail.gmail.com>
On Tuesday, October 04, 2011 07:03:10 PM Adrian Chadd wrote:
> Nope, what I'm saying is that someone's likely just copy/paste'd the
> "we support x and y!" from some marketing material and then suggested
> people use linux/openwrt/ath9k without really looking at it.
I'm still curious how they got the Apple access point through the FCC
testing back then. Well, I guess we'll never know for sure.
> There were plenty of people advertising the AR9160 as a "3x3 MIMO"
> when it's a 2x2 stream device with 3 antennas. I know this confused me
> when I started tinkering with wifi stuff.
AFAIK the 3x3 really just stands for the amount of tx X rx chains [and
not antennas]. So if the hardware has 3 tx and rx chains it can be sold
as a "3x3" device even if does not support 3 streams.
> Anyway, we're getting off-track here.
we can stop anytime.
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Adrian Chadd @ 2011-10-04 17:03 UTC (permalink / raw)
To: Christian Lamparter
Cc: Zefir Kurtisi, Luis R. Rodriguez, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <201110041842.05218.chunkeey@googlemail.com>
Nope, what I'm saying is that someone's likely just copy/paste'd the
"we support x and y!" from some marketing material and then suggested
people use linux/openwrt/ath9k without really looking at it.
There were plenty of people advertising the AR9160 as a "3x3 MIMO"
when it's a 2x2 stream device with 3 antennas. I know this confused me
when I started tinkering with wifi stuff.
Anyway, we're getting off-track here.
Adrian
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Christian Lamparter @ 2011-10-04 16:42 UTC (permalink / raw)
To: Adrian Chadd
Cc: Zefir Kurtisi, Luis R. Rodriguez, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <CAJ-Vmom44ZDo7CqrnNgo+MQ=otOB=+WyQYAyAZAt2ko=STkSsA@mail.gmail.com>
On Tuesday, October 04, 2011 05:57:32 PM Adrian Chadd wrote:
> On 4 October 2011 23:26, Christian Lamparter <chunkeey@googlemail.com> wrote:
> > On Tuesday, October 04, 2011 04:50:42 PM Adrian Chadd wrote:
> >> Also whilst I'm at it, "SPECTRUM_MANAGEMENT" is a very broad flag to set.
> >
> > Hm, 802.11-2007 5.4.4 "Spectrum management services" explicitly
> > mentions that both services TPC and DFS are required in some
> > regulatory domains for operation in the 5 GHz band.
>
> Right, but just for hostap mode, correct? I'm also thinking about
> non-hostap mode support.
I don't think it's just hostap mode. More like hostap, IBSS and MESH.
In fact, with P2P/Wifi-Direct, the station mode might becoming a
thing of the past, right?
> > [ Just for fun: Do you know how the AR5418 handled radars in
> > the proprietary turbo mode in the 5 GHz band? And how does
> > Atheros own driver/stack/etc. deals with this limitation?
> > After all Unex sold/sells the DNBA-81 on their product page
> > as: <http://www.unex.com.tw/product/dnba-81>
> >
> > "DNBA-81 is a 802.11n 2x3 2-stream a/b/g dual band wifi
> > Cardbus designed specifically for laptops and *access points*/
> > home gateways/consumer electronics/multimedia entertainment
> > devices/peripherals with standard Cardbus slot." ]
>
> Besides, you realise that vendors say the darnest things at times? :)
> For example, one well-known vendor lists their AR9160 NICs as DFS
> ready (and thus people who buy them think they're DFS ready), but if
> you buy some of their MIPS SOC hardware, they only support
> OpenWRT+ath9k on it. I'm sure more than a few people fell into that
> trap. :)
Well, ok. I found a better example:
http://www.wikidevi.com/wiki/Apple_AirPort_Extreme_Base_Station_A1143_%28MA073LL/A%29
You see, they put an AR5418(or 6?) with an AR5133 into the first draft-n
Apple Airport Base Station. If this much money was involved, do you
think that an American Company would "lie" to another American Company?
Regards,
Chr
^ permalink raw reply
* [PATCH] mac80211: fix offchannel TX cookie matching
From: Johannes Berg @ 2011-10-04 16:27 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Jouni Malinen
From: Johannes Berg <johannes.berg@intel.com>
When I introduced in-kernel off-channel TX I
introduced a bug -- the work can't be canceled
again because the code clear the skb pointer.
Fix this by keeping track separately of whether
TX status has already been reported.
Cc: stable@kernel.org [2.6.38+]
Reported-by: Jouni Malinen <j@w1.fi>
Tested-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/cfg.c | 2 +-
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/status.c | 2 +-
net/mac80211/work.c | 2 +-
4 files changed, 4 insertions(+), 3 deletions(-)
--- a/net/mac80211/cfg.c 2011-10-04 10:49:07.000000000 +0200
+++ b/net/mac80211/cfg.c 2011-10-04 18:12:34.000000000 +0200
@@ -1886,7 +1886,7 @@ ieee80211_offchan_tx_done(struct ieee802
* so in that case userspace will have to deal with it.
*/
- if (wk->offchan_tx.wait && wk->offchan_tx.frame)
+ if (wk->offchan_tx.wait && !wk->offchan_tx.status)
cfg80211_mgmt_tx_status(wk->sdata->dev,
(unsigned long) wk->offchan_tx.frame,
wk->ie, wk->ie_len, false, GFP_KERNEL);
--- a/net/mac80211/ieee80211_i.h 2011-10-04 10:49:07.000000000 +0200
+++ b/net/mac80211/ieee80211_i.h 2011-10-04 18:11:45.000000000 +0200
@@ -346,6 +346,7 @@ struct ieee80211_work {
struct {
struct sk_buff *frame;
u32 wait;
+ bool status;
} offchan_tx;
};
--- a/net/mac80211/status.c 2011-10-04 10:55:26.000000000 +0200
+++ b/net/mac80211/status.c 2011-10-04 18:12:46.000000000 +0200
@@ -429,7 +429,7 @@ void ieee80211_tx_status(struct ieee8021
continue;
if (wk->offchan_tx.frame != skb)
continue;
- wk->offchan_tx.frame = NULL;
+ wk->offchan_tx.status = true;
break;
}
rcu_read_unlock();
--- a/net/mac80211/work.c 2011-10-04 18:15:17.000000000 +0200
+++ b/net/mac80211/work.c 2011-10-04 18:15:26.000000000 +0200
@@ -577,7 +577,7 @@ ieee80211_offchannel_tx(struct ieee80211
/*
* After this, offchan_tx.frame remains but now is no
* longer a valid pointer -- we still need it as the
- * cookie for canceling this work.
+ * cookie for canceling this work/status matching.
*/
ieee80211_tx_skb(wk->sdata, wk->offchan_tx.frame);
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Zefir Kurtisi @ 2011-10-04 16:26 UTC (permalink / raw)
To: Christian Lamparter
Cc: Luis R. Rodriguez, linux-wireless, ath9k-devel, kgiori, nbd
In-Reply-To: <201110041642.54453.chunkeey@googlemail.com>
On 10/04/2011 04:42 PM, Christian Lamparter wrote:
> On Tuesday, October 04, 2011 04:17:35 PM Zefir Kurtisi wrote:
>> On 10/04/2011 03:38 PM, Christian Lamparter wrote:
>>> On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
>>>> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
>>>> <chunkeey@googlemail.com> wrote:
>>>>> On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
>>>>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>>>>>>>
>>>>>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>>>>>>> ---
>>>>>>> drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>>>>>>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>>>>>>> index e8aeb98..5defebe 100644
>>>>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>>>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>>>>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>>>>>>> "Unable to reset channel, reset status %d\n", r);
>>>>>>> goto out;
>>>>>>> }
>>>>>>> +#ifdef CONFIG_ATH9K_DFS
>>>>>>
>>>>>> Please spare the #ifdef and just call something within dfs.c, then
>>>>>> dfs.h would wrap it to nothing if DFS is disabled.
>>>>> Why would anyone want to disable DFS driver support?
>>>>> I would say: drop the ifdefs altogether since DFS
>>>>> is and will be "required".
>>>>
>>>> Because DFS requires to be properly tested before being enabled.
>>> Testing if a driver detects a pulse is "trivial" compared to the
>>> stuff mac80211/cfg80211 and hostapd will have to do to make a
>>> channel-change as smooth as possible. I think if there's a DFS
>>> "OFF" switch, it should be in hostapd and I hope more people
>>> agree on this one.
>>>
>> Yes on both. Work on the management part of the DFS module has just
>> been started by TI guys. When this is in, hostapd will be able to
>> query the driver's DFS detection capabilities and leave DFS channels
>> disabled for those devices with no (or insufficient) support
>> (like it is generally done today for DFS channels).
>>
>> The proper way for a driver's OFF switch would then be to just
>> announce missing DFS capabilities.
> Actually, I think we already have a flag for such a
> purpose:
> * @IEEE80211_HW_SPECTRUM_MGMT:
> * Hardware supports spectrum management defined in 802.11h
> AFAIK 802.11h[now integrated in 802.11-2007] included DFS, right?
>
Yes, 802.11h includes DFS and TPC.
But this flag is already used (i.e. is set by ath9k) without having DFS support so far. Either it is having some different interpretation, or it is just set wrong. This was irrelevant so far, since there is no DFS support in mac80211 yet and might require to clarify the specs for this flag.
>>>> You may also want to simply disable DFS if you do not want to
>>>> deal with the regulatory test implications of having it enabled.
>>> AFAIK you can't "simply" disable the DFS requirement: hostapd
>>> (hw_features.c), [cfg80211] (checks if tx on secondary channel
>>> is possible) and mac80211 (tx.c) all have checks. Indeed, the
>>> easiest way is to modify crda's database. So there's no need
>>> for an extra compile-time option.
>>>
>> There might be a demand for conditional compiling in addition to
>> DFS capabilities announcements to reduce memory footprint, since
>> (especially) pattern matching algorithms will increase it significantly.
> I don't think memory footprint is such a big problem. After all ath9k
> has around 170 kb [please correct me if I'm wrong here] of initvals
> for all supported solutions since AR5008.
>
It might be even more. But this does not imply that it is not worth to save some bytes, IMHO.
> Regards,
> Chr
Zefir
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Adrian Chadd @ 2011-10-04 15:57 UTC (permalink / raw)
To: Christian Lamparter
Cc: Zefir Kurtisi, Luis R. Rodriguez, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <201110041726.40722.chunkeey@googlemail.com>
On 4 October 2011 23:26, Christian Lamparter <chunkeey@googlemail.com> wrote:
> On Tuesday, October 04, 2011 04:50:42 PM Adrian Chadd wrote:
>> Also whilst I'm at it, "SPECTRUM_MANAGEMENT" is a very broad flag to set.
>
> Hm, 802.11-2007 5.4.4 "Spectrum management services" explicitly
> mentions that both services TPC and DFS are required in some
> regulatory domains for operation in the 5 GHz band.
Right, but just for hostap mode, correct? I'm also thinking about
non-hostap mode support.
> [ Just for fun: Do you know how the AR5418 handled radars in
> the proprietary turbo mode in the 5 GHz band? And how does
> Atheros own driver/stack/etc. deals with this limitation?
> After all Unex sold/sells the DNBA-81 on their product page
> as: <http://www.unex.com.tw/product/dnba-81>
>
> "DNBA-81 is a 802.11n 2x3 2-stream a/b/g dual band wifi
> Cardbus designed specifically for laptops and *access points*/
> home gateways/consumer electronics/multimedia entertainment
> devices/peripherals with standard Cardbus slot." ]
I haven't sat down and looked at exactly what the AR5416/AR5418
support is like save what I've seen when digging into the meaning
behind the extended EEPROM bits. In any case, the easiest solution is
to just disable HT40 for those (which, incidentally, is exactly what
FreeBSD's ath and net80211 regulatory code did until recently.)
And as I said, that isn't needed for station mode operation, so you
can just use HT/40 channels. :)
Besides, you realise that vendors say the darnest things at times? :)
For example, one well-known vendor lists their AR9160 NICs as DFS
ready (and thus people who buy them think they're DFS ready), but if
you buy some of their MIPS SOC hardware, they only support
OpenWRT+ath9k on it. I'm sure more than a few people fell into that
trap. :)
Adrian
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Christian Lamparter @ 2011-10-04 15:26 UTC (permalink / raw)
To: Adrian Chadd
Cc: Zefir Kurtisi, Luis R. Rodriguez, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <CAJ-VmomWYUtd84APvEg7mKC-sevT3UVaX2qKBn3KiVriPZybgQ@mail.gmail.com>
On Tuesday, October 04, 2011 04:50:42 PM Adrian Chadd wrote:
> Also whilst I'm at it, "SPECTRUM_MANAGEMENT" is a very broad flag to set.
Hm, 802.11-2007 5.4.4 "Spectrum management services" explicitly
mentions that both services TPC and DFS are required in some
regulatory domains for operation in the 5 GHz band.
> For example: you may not want to do DFS on the AR5416 NICs because
> (as documented in the open hal and earlier ath9k bits) there isn't
> support for radar pulses on the ext channel. So even if you had a
> successful DFS algorithm for this NIC, you'd have to somehow tell
> the DFS machinery that HT40+DFS channels aren't supported but
> HT20+DFS channels are.
well, that's a pity. We do have seperated HT feature sets for each
band but they are not seperated by operation mode...
[ Just for fun: Do you know how the AR5418 handled radars in
the proprietary turbo mode in the 5 GHz band? And how does
Atheros own driver/stack/etc. deals with this limitation?
After all Unex sold/sells the DNBA-81 on their product page
as: <http://www.unex.com.tw/product/dnba-81>
"DNBA-81 is a 802.11n 2x3 2-stream a/b/g dual band wifi
Cardbus designed specifically for laptops and *access points*/
home gateways/consumer electronics/multimedia entertainment
devices/peripherals with standard Cardbus slot." ]
Regards,
Chr
^ permalink raw reply
* Re: linux-next: build failure after merge of the moduleh tree
From: Larry Finger @ 2011-10-04 15:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kalle Valo, Paul Gortmaker, linux-next, linux-kernel,
John W. Linville, linux-wireless
In-Reply-To: <20111004191408.8f211d359d9e5d7b65129c4c@canb.auug.org.au>
On 10/04/2011 03:14 AM, Stephen Rothwell wrote:
>
> Since it adds an include of export.h (which only exists in Paul's tree),
> it goes into Paul's post merge patch series.
Sounds good. ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
^ permalink raw reply
* Re: [RFC] mac80211: remove per band sta supported rates
From: Johannes Berg @ 2011-10-04 15:07 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Ben Greear
In-Reply-To: <20110929150018.GA4554@redhat.com>
On Thu, 2011-09-29 at 17:00 +0200, Stanislaw Gruszka wrote:
> On Tue, Sep 27, 2011 at 01:34:49PM +0200, Johannes Berg wrote:
> > On Tue, 2011-09-27 at 13:12 +0200, Stanislaw Gruszka wrote:
> > > It is not possible to connect to remote station on two bands
> > > at once, or I'm wrong?
> >
> > I don't think it is, but there could be channel switches maybe?
>
> If AP would like to change to different band, it will need provide new
> Supported Rates element, or operate on older one.
>
> So this could be simplified, but from other hand this helps to catch
> bugs, so maybe would be better to keep it. As long some other warning
> would be added to check that we send on proper channel.
Yeah I was going to say ... the main purpose of this these days seems to
be catching this tx-on-wrong-band (which should be channel) ...
> > > Which may happen when we are just after disassociation and changed
> > > channel/band, but still want send some frames (namely delBA) to old
> > > sta. Right fix should prevent to change channel before we fully
> > > dissassocate, or prevent to send frames after connection is lost,
> > > or both, but I don't know how to correctly do this so far.
> >
> > Well, either we should simply not send the frame, or send it before
> > disassoc, no?
>
> I think I can fix this that way, but I'm not sure if that would be right
> fix either. We have few instances of warning:
I think that would be the right fix. In some cases, we may want to
reorder things instead of just not sending frames.
> 1) started at ieee80211_sta_connection_lost()
> https://bugzilla.redhat.com/show_bug.cgi?id=731365#c0
> could be fixed by:
> ieee80211_set_disassoc(..., false);
> ieee80211_send_deauth_disassoc(, false);
Why would this trigger the problem? Can we somehow lose connection while
already trying to connect to a new AP?
> 2) started at ieee80211_tx_status()
> https://bugzilla.redhat.com/show_bug.cgi?id=731365#c11
> could be fixed by adding association check before
> ieee80211_send_bar()
That seems reasonable. No use in trying to tear down BA sessions when
we're already disconnected.
> 3) started at ieee80211_offchannel_return()
> https://bugzilla.redhat.com/show_bug.cgi?id=737993#c0
> no idea how to fix
Hm, seems like maybe offchannel return is telling the AP that we woke
up, but maybe the offchannel work disconnected or something?
> All these problems looks like channel switching issue -
> - we changed channel, whereas we should still operate on old one.
> Fedora 15 users start to report that WARNING after update to 3.0
> from 2.6.38, so this could be related to Ben offchannel work.
That's very well possible.
Thanks for looking into all this!
johannes
^ permalink raw reply
* [PATCH 3.2] iwlagn: separate init calib and rt calib
From: Wey-Yi Guy @ 2011-10-04 14:10 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Wey-Yi Guy
My previous patch for init calib cfg disable a set of calibration for both
init and runtime which cause performance issue, Fix it
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
hese patches will be also available later from wireless branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi.git
drivers/net/wireless/iwlwifi/iwl-agn.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 90ca2d0..afd4b4c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -1222,7 +1222,7 @@ static int iwlagn_send_calib_cfg_rt(struct iwl_priv *priv, u32 cfg)
};
memset(&calib_cfg_cmd, 0, sizeof(calib_cfg_cmd));
- calib_cfg_cmd.ucd_calib_cfg.once.is_enable = IWL_CALIB_INIT_CFG_ALL;
+ calib_cfg_cmd.ucd_calib_cfg.once.is_enable = IWL_CALIB_RT_CFG_ALL;
calib_cfg_cmd.ucd_calib_cfg.once.start = cpu_to_le32(cfg);
return iwl_trans_send_cmd(trans(priv), &cmd);
diff --git a/drivers/net/wireless/iwlwifi/iwl-commands.h b/drivers/net/wireless/iwlwifi/iwl-commands.h
index 9a5d993..69d5f85 100644
--- a/drivers/net/wireless/iwlwifi/iwl-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-commands.h
@@ -3216,6 +3216,16 @@ enum iwl_ucode_calib_cfg {
IWL_CALIB_CFG_RX_IQ_IDX | \
IWL_CALIB_CFG_CRYSTAL_IDX)
+#define IWL_CALIB_RT_CFG_ALL cpu_to_le32(IWL_CALIB_CFG_RX_BB_IDX | \
+ IWL_CALIB_CFG_DC_IDX | \
+ IWL_CALIB_CFG_LO_IDX | \
+ IWL_CALIB_CFG_TX_IQ_IDX | \
+ IWL_CALIB_CFG_RX_IQ_IDX | \
+ IWL_CALIB_CFG_TEMPERATURE_IDX | \
+ IWL_CALIB_CFG_PAPD_IDX | \
+ IWL_CALIB_CFG_TX_PWR_IDX | \
+ IWL_CALIB_CFG_CRYSTAL_IDX)
+
#define IWL_CALIB_CFG_FLAG_SEND_COMPLETE_NTFY_MSK cpu_to_le32(BIT(0))
struct iwl_calib_cfg_elmnt_s {
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Adrian Chadd @ 2011-10-04 14:50 UTC (permalink / raw)
To: Christian Lamparter
Cc: Zefir Kurtisi, Luis R. Rodriguez, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <201110041642.54453.chunkeey@googlemail.com>
Also whilst I'm at it, "SPECTRUM_MANAGEMENT" is a very broad flag to set.
For example: you may not want to do DFS on the AR5416 NICs because (as
documented in the open hal and earlier ath9k bits) there isn't support
for radar pulses on the ext channel. So even if you had a successful
DFS algorithm for this NIC, you'd have to somehow tell the DFS
machinery that HT40+DFS channels aren't supported but HT20+DFS
channels are.
But then, the AR5416 supports per-packet TPC, so you could use it in
STA mode perfectly fine and it'd support that part of spectrum
management. Since you get per-frame RSSI of RX'ed frames, you can
support the spectrum power histogram IE.
And since it supports quiet time stuff, you can use it in STA and
hostap mode for supporting the quiet time IE.
(Yes, I'm looking at how to make all of this work in FreeBSD net80211,
as some patches have been supplied to start fleshing out these
functions. :)
I'm not saying this needs to be solved now, but I think it's worth
thinking about how to encapsulate exactly what it is that NICs
support, rather than simply saying "yup, 11h is here, all good mate."
Adrian
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Christian Lamparter @ 2011-10-04 14:42 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: Luis R. Rodriguez, linux-wireless, ath9k-devel, kgiori, nbd
In-Reply-To: <4E8B157F.2080203@neratec.com>
On Tuesday, October 04, 2011 04:17:35 PM Zefir Kurtisi wrote:
> On 10/04/2011 03:38 PM, Christian Lamparter wrote:
> > On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
> >> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
> >> <chunkeey@googlemail.com> wrote:
> >>> On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
> >>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> >>>>>
> >>>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
> >>>>> ---
> >>>>> drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
> >>>>> 1 files changed, 12 insertions(+), 0 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> >>>>> index e8aeb98..5defebe 100644
> >>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
> >>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
> >>>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
> >>>>> "Unable to reset channel, reset status %d\n", r);
> >>>>> goto out;
> >>>>> }
> >>>>> +#ifdef CONFIG_ATH9K_DFS
> >>>>
> >>>> Please spare the #ifdef and just call something within dfs.c, then
> >>>> dfs.h would wrap it to nothing if DFS is disabled.
> >>> Why would anyone want to disable DFS driver support?
> >>> I would say: drop the ifdefs altogether since DFS
> >>> is and will be "required".
> >>
> >> Because DFS requires to be properly tested before being enabled.
> > Testing if a driver detects a pulse is "trivial" compared to the
> > stuff mac80211/cfg80211 and hostapd will have to do to make a
> > channel-change as smooth as possible. I think if there's a DFS
> > "OFF" switch, it should be in hostapd and I hope more people
> > agree on this one.
> >
> Yes on both. Work on the management part of the DFS module has just
> been started by TI guys. When this is in, hostapd will be able to
> query the driver's DFS detection capabilities and leave DFS channels
> disabled for those devices with no (or insufficient) support
> (like it is generally done today for DFS channels).
>
> The proper way for a driver's OFF switch would then be to just
> announce missing DFS capabilities.
Actually, I think we already have a flag for such a
purpose:
* @IEEE80211_HW_SPECTRUM_MGMT:
* Hardware supports spectrum management defined in 802.11h
AFAIK 802.11h[now integrated in 802.11-2007] included DFS, right?
> >> You may also want to simply disable DFS if you do not want to
> >> deal with the regulatory test implications of having it enabled.
> > AFAIK you can't "simply" disable the DFS requirement: hostapd
> > (hw_features.c), [cfg80211] (checks if tx on secondary channel
> > is possible) and mac80211 (tx.c) all have checks. Indeed, the
> > easiest way is to modify crda's database. So there's no need
> > for an extra compile-time option.
> >
> There might be a demand for conditional compiling in addition to
> DFS capabilities announcements to reduce memory footprint, since
> (especially) pattern matching algorithms will increase it significantly.
I don't think memory footprint is such a big problem. After all ath9k
has around 170 kb [please correct me if I'm wrong here] of initvals
for all supported solutions since AR5008.
Regards,
Chr
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Adrian Chadd @ 2011-10-04 14:34 UTC (permalink / raw)
To: Zefir Kurtisi
Cc: Christian Lamparter, Luis R. Rodriguez, linux-wireless,
ath9k-devel, kgiori, nbd
In-Reply-To: <4E8B157F.2080203@neratec.com>
.. erm, how complicated is the pattern matching code when it's compiled?
The port of the fusion radar detection module didn't end up being all that big.
Adrian
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Zefir Kurtisi @ 2011-10-04 14:17 UTC (permalink / raw)
To: Christian Lamparter
Cc: Luis R. Rodriguez, linux-wireless, ath9k-devel, kgiori, nbd
In-Reply-To: <201110041538.12885.chunkeey@googlemail.com>
On 10/04/2011 03:38 PM, Christian Lamparter wrote:
> On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
>> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>>> On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
>>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>>>>>
>>>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>>>>> ---
>>>>> drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>>>>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>>>>> index e8aeb98..5defebe 100644
>>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>>>>> "Unable to reset channel, reset status %d\n", r);
>>>>> goto out;
>>>>> }
>>>>> +#ifdef CONFIG_ATH9K_DFS
>>>>
>>>> Please spare the #ifdef and just call something within dfs.c, then
>>>> dfs.h would wrap it to nothing if DFS is disabled.
>>> Why would anyone want to disable DFS driver support?
>>> I would say: drop the ifdefs altogether since DFS
>>> is and will be "required".
>>
>> Because DFS requires to be properly tested before being enabled.
> Testing if a driver detects a pulse is "trivial" compared to the
> stuff mac80211/cfg80211 and hostapd will have to do to make a
> channel-change as smooth as possible. I think if there's a DFS
> "OFF" switch, it should be in hostapd and I hope more people
> agree on this one.
>
Yes on both. Work on the management part of the DFS module has just been started by TI guys. When this is in, hostapd will be able to query the driver's DFS detection capabilities and leave DFS channels disabled for those devices with no (or insufficient) support (like it is generally done today for DFS channels).
The proper way for a driver's OFF switch would then be to just announce missing DFS capabilities.
>> You may also want to simply disable DFS if you do not want to
>> deal with the regulatory test implications of having it enabled.
> AFAIK you can't "simply" disable the DFS requirement: hostapd
> (hw_features.c), [cfg80211] (checks if tx on secondary channel
> is possible) and mac80211 (tx.c) all have checks. Indeed, the
> easiest way is to modify crda's database. So there's no need
> for an extra compile-time option.
>
There might be a demand for conditional compiling in addition to DFS capabilities announcements to reduce memory footprint, since (especially) pattern matching algorithms will increase it significantly.
> Regards,
> Chr
Zefir
^ 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