* AR9002 data sheet
From: Prabhunath G @ 2013-09-12 6:00 UTC (permalink / raw)
To: linux-wireless
Dear All,
I am interested to analyse the ath9k drivers having an agenda
of contributing in near future.
Can I get the datasheet of AR9002 so that I can start analysing the driver.
Regards,
Prabhunath G
Linux Trainer
Bangalore
^ permalink raw reply
* Re: AR9002 data sheet
From: Prabhunath G @ 2013-09-12 6:08 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CACPKTAP1EkW8_Ljs4oAY-gp_CmeD-nMkohKy-8RFP__BOcOTAA@mail.gmail.com>
Or any datasheet of 802.11 b/g/n device for which there is a
development of linux driver
Thanks,
Prabhu
On Thu, Sep 12, 2013 at 11:30 AM, Prabhunath G <gprabhunath@gmail.com> wrote:
> Dear All,
>
> I am interested to analyse the ath9k drivers having an agenda
> of contributing in near future.
> Can I get the datasheet of AR9002 so that I can start analysing the driver.
>
> Regards,
> Prabhunath G
> Linux Trainer
> Bangalore
--
Regards,
Prabhunath G
Linux Trainer
Bangalore
^ permalink raw reply
* Re: No connection with TP-Link TL-WN823N (rtl8192cu)
From: Larry Finger @ 2013-09-12 6:24 UTC (permalink / raw)
To: Vincent Thiele; +Cc: Dan Williams, linux-wireless, Mark Cave-Ayland
In-Reply-To: <CAEZsi7F-RxaZJNaYi53kTtsQbxL4TU6DhTPo5v-O5ry=pawb_Q@mail.gmail.com>
On 09/12/2013 12:57 AM, Vincent Thiele wrote:
> No i tried your "ping-solution" with kernel 3.11 but it dosen't work.
I just discovered that your device is a 300 Mbps unit, which implies a 2x2
configuration. The only one of them that I have does not work with any Linux
driver; however, some of the postings that I have read suggest that this one
will work with the vendor driver.
I just bought a TL-WN823N on E-Bay. I think the expected delivery is Sept. 16.
Once I get it, I will try to see what I can learn.
Larry
^ permalink raw reply
* Re: No connection with TP-Link TL-WN823N (rtl8192cu)
From: Vincent Thiele @ 2013-09-12 7:41 UTC (permalink / raw)
To: Larry Finger; +Cc: Dan Williams, linux-wireless, Mark Cave-Ayland
In-Reply-To: <52315E0C.9010806@lwfinger.net>
Thank you very much. The vendor driver doesn't work with 3.8 or 3.9.
Therefore i use the patched vendor driver but with 3.10 or 3.11 even
the patched dkms driver doesn't work.
2013/9/12 Larry Finger <Larry.Finger@lwfinger.net>:
> On 09/12/2013 12:57 AM, Vincent Thiele wrote:
>>
>> No i tried your "ping-solution" with kernel 3.11 but it dosen't work.
>
>
> I just discovered that your device is a 300 Mbps unit, which implies a 2x2
> configuration. The only one of them that I have does not work with any Linux
> driver; however, some of the postings that I have read suggest that this one
> will work with the vendor driver.
>
> I just bought a TL-WN823N on E-Bay. I think the expected delivery is Sept.
> 16. Once I get it, I will try to see what I can learn.
>
> Larry
>
>
^ permalink raw reply
* Re: pull request: wireless 2013-09-10
From: David Miller @ 2013-09-12 7:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130910193845.GD1960@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 10 Sep 2013 15:38:45 -0400
> This is a pull request for a few early fixes for the 3.12 stream.
Looks good, pulled, thanks John.
^ permalink raw reply
* Broadcom PCI ID 14e4:4313 reuse?
From: Hauke Mehrtens @ 2013-09-12 10:49 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Arend van Spriel
Hi Arend,
In OpenWrt someone reported that he has a BCM4313 with the PCI id
14e4:4313 [0]. The b43 wiki [1] says this was used for a BCM4311 with
just ieee80211a support.
Is it correct that BCM4313 also uses this PCI id, this chip was was
directly soldered onto a router? Is the b43 wiki wrong and 14e4:4313 was
not used for the BCM4311 or was this PCI id reused for a different device?
I am planing to prepare a patch adding support for a BCM4313 with the
PCI ID of 14e4:4313 and I will ignore that there could be some BCM4311
with this PCI id.
Log of BCM4313:
[ 0.316000] pci 0000:01:00.0: [14e4:4313] type 00 class 0x028000
(...)
[ 10.616000] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
[ 10.624000] bcma: bus0: Found chip with id 0x4313, rev 0x01 and
package 0x08
[ 10.628000] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id
0x800, rev 0x24, class 0x0)
[ 10.640000] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id
0x812, rev 0x18, class 0x0)
[ 10.648000] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820,
rev 0x11, class 0x0)
[ 10.656000] bcma: bus0: Using fallback SPROM failed (err -2)
[ 10.660000] bcma: bus0: No SPROM available
[ 10.676000] bcma: bus0: Bus registered
[ 11.040000] b43-phy0: Broadcom 4313 WLAN found (core revision 24)
[ 11.048000] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 10, Type 8
(LCN), Revision 1)
[0]: https://dev.openwrt.org/ticket/13551
[1]: http://wireless.kernel.org/en/users/Drivers/b43
Hauke
^ permalink raw reply
* Re: Broadcom PCI ID 14e4:4313 reuse?
From: Arend van Spriel @ 2013-09-12 12:24 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <52319C4D.6030803@hauke-m.de>
On 09/12/2013 12:49 PM, Hauke Mehrtens wrote:
> Hi Arend,
>
> In OpenWrt someone reported that he has a BCM4313 with the PCI id
> 14e4:4313 [0]. The b43 wiki [1] says this was used for a BCM4311 with
> just ieee80211a support.
That is what I found over here as well.
> Is it correct that BCM4313 also uses this PCI id, this chip was was
> directly soldered onto a router? Is the b43 wiki wrong and 14e4:4313 was
> not used for the BCM4311 or was this PCI id reused for a different device?
It is weird that this comes up with PCI id 0x4313. The chip id is read
from chipcommon and indeed returns 0x4313. The core revisions that bcma
finds indicate also that this is indeed a bcm4313.
> I am planing to prepare a patch adding support for a BCM4313 with the
> PCI ID of 14e4:4313 and I will ignore that there could be some BCM4311
> with this PCI id.
You mean a patch in brcmsmac? Maybe brcms_c_chipmatch_pci() should check
the chip id as well (like brcms_c_chipmatch_soc()).
Regards,
Arend
> Log of BCM4313:
>
> [ 0.316000] pci 0000:01:00.0: [14e4:4313] type 00 class 0x028000
> (...)
> [ 10.616000] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
> [ 10.624000] bcma: bus0: Found chip with id 0x4313, rev 0x01 and
> package 0x08
> [ 10.628000] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id
> 0x800, rev 0x24, class 0x0)
> [ 10.640000] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id
> 0x812, rev 0x18, class 0x0)
> [ 10.648000] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820,
> rev 0x11, class 0x0)
> [ 10.656000] bcma: bus0: Using fallback SPROM failed (err -2)
> [ 10.660000] bcma: bus0: No SPROM available
> [ 10.676000] bcma: bus0: Bus registered
> [ 11.040000] b43-phy0: Broadcom 4313 WLAN found (core revision 24)
> [ 11.048000] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 10, Type 8
> (LCN), Revision 1)
>
>
> [0]: https://dev.openwrt.org/ticket/13551
> [1]: http://wireless.kernel.org/en/users/Drivers/b43
>
> Hauke
>
^ permalink raw reply
* Re: Broadcom PCI ID 14e4:4313 reuse?
From: Hauke Mehrtens @ 2013-09-12 12:50 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <5231B269.5060404@broadcom.com>
On 09/12/2013 02:24 PM, Arend van Spriel wrote:
> On 09/12/2013 12:49 PM, Hauke Mehrtens wrote:
>> Hi Arend,
>>
>> In OpenWrt someone reported that he has a BCM4313 with the PCI id
>> 14e4:4313 [0]. The b43 wiki [1] says this was used for a BCM4311 with
>> just ieee80211a support.
>
> That is what I found over here as well.
>
>> Is it correct that BCM4313 also uses this PCI id, this chip was was
>> directly soldered onto a router? Is the b43 wiki wrong and 14e4:4313 was
>> not used for the BCM4311 or was this PCI id reused for a different
>> device?
>
> It is weird that this comes up with PCI id 0x4313. The chip id is read
> from chipcommon and indeed returns 0x4313. The core revisions that bcma
> finds indicate also that this is indeed a bcm4313.
Could it be that this is some default PCI id which is normally changed
by a vendor to something else? I have seen the BCM43224 with the PCI id
14e4:a8d8 only on routers expect after I introduced a error in bcma and
all the BCM43224 turned to have this PCI id. ;-)
>> I am planing to prepare a patch adding support for a BCM4313 with the
>> PCI ID of 14e4:4313 and I will ignore that there could be some BCM4311
>> with this PCI id.
>
> You mean a patch in brcmsmac? Maybe brcms_c_chipmatch_pci() should check
> the chip id as well (like brcms_c_chipmatch_soc()).
Yes I want to add this to the pci ids of bcma and to brcmsmacs
brcms_c_chipmatch_pci() function.
>
> Regards,
> Arend
>
>> Log of BCM4313:
>>
>> [ 0.316000] pci 0000:01:00.0: [14e4:4313] type 00 class 0x028000
>> (...)
>> [ 10.616000] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
>> [ 10.624000] bcma: bus0: Found chip with id 0x4313, rev 0x01 and
>> package 0x08
>> [ 10.628000] bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id
>> 0x800, rev 0x24, class 0x0)
>> [ 10.640000] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id
>> 0x812, rev 0x18, class 0x0)
>> [ 10.648000] bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820,
>> rev 0x11, class 0x0)
>> [ 10.656000] bcma: bus0: Using fallback SPROM failed (err -2)
>> [ 10.660000] bcma: bus0: No SPROM available
>> [ 10.676000] bcma: bus0: Bus registered
>> [ 11.040000] b43-phy0: Broadcom 4313 WLAN found (core revision 24)
>> [ 11.048000] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 10, Type 8
>> (LCN), Revision 1)
>>
>>
>> [0]: https://dev.openwrt.org/ticket/13551
>> [1]: http://wireless.kernel.org/en/users/Drivers/b43
>>
>> Hauke
>>
>
>
^ permalink raw reply
* Huge value read when requesting NL80211_SURVEY_INFO_CHANNEL_TIME_BUSY
From: Adrien Decostre @ 2013-09-12 13:59 UTC (permalink / raw)
To: linux-wireless; +Cc: sarah.rumpel
Dear all,
We are currently doing some tests to retrieve the channel busy time,
Rx time and Tx time from the ath9k driver. For this purpose, we
started our implementation from the initial ACS algorithm
implementation provided at https://github.com/mcgrof/acs.
The data are read in the following way:
channel_time_busy = nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_BUSY]);
channel_time_rx = nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_RX]);
channel_time_tx = nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_TX]);
In most of the cases, the received data are OK but when generating
heavy interferences (actually when saturating the channel), very huge
values are read. For example, the
NL80211_SURVEY_INFO_CHANNEL_TIME_BUSY for 3 consecutive measurements
was 439270ms, 439411ms and 439555ms while the interface should not
have listened to this channel for more than 60ms.
Would anyone have already encountered a similar issue with the ath9k driver?
Does the driver do some accumulation over time and should a reset be
needed before doing any measurement?
I thank you in advance for any help.
Best regards
Adrien
^ permalink raw reply
* small PAGE_SIZE related fixes for wl{12,18}xx drivers
From: Vladimir Murzin @ 2013-09-12 15:32 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: coelho, linville
This small series is considering PAGE_SIZE usage into the wl drivers. I have
no real HW to test it tightly, probably these drivers will never run on arches
with PAGE_SIZE different to 4K. Nevertheless, I hope this mini-series (or some
part of it) will be useful for you.
Thanks.
Vladimir
^ permalink raw reply
* [PATCH 1/3] wlcore: fix frame size overflow warning in wl12xx_spi_raw_write
From: Vladimir Murzin @ 2013-09-12 15:32 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: coelho, linville, Vladimir Murzin
In-Reply-To: <1378999943-1968-1-git-send-email-murzin.v@gmail.com>
While cross-building for PPC64 I've got
drivers/net/wireless/ti/wlcore/spi.c: In function
'wl12xx_spi_raw_write': drivers/net/wireless/ti/wlcore/spi.c:317:1:
warning: the frame size of 9712 bytes is larger than 2048 bytes
[-Wframe-larger-than=]
WSPI_MAX_NUM_OF_CHUNKS depends on SPI_AGGR_BUFFER_SIZE which in turn
is based on PAGE_SIZE. For most systems PAGE_SIZE is stands for 4K,
but it may vary - in my case PAGE_SIZE is 64K.
Fix calculation by using 4K explicitly.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
drivers/net/wireless/ti/wlcore/spi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index 1b0cd98..8dce028 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,7 +70,8 @@
* only support SPI for 12xx - this code should be reworked when 18xx
* support is introduced
*/
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_PAGE_SIZE 4096
+#define SPI_AGGR_BUFFER_SIZE (4 * SPI_PAGE_SIZE)
#define WSPI_MAX_NUM_OF_CHUNKS (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] wl12xx/wl18xx: limit base for aggregate buffer size to 4K
From: Vladimir Murzin @ 2013-09-12 15:32 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: coelho, linville, Vladimir Murzin
In-Reply-To: <1378999943-1968-1-git-send-email-murzin.v@gmail.com>
WL{12,18}XX_AGGR_BUFFER_SIZE is depends on PAGE_SIZE which may be more
than 4K. In this case memory might be aggressively wasted.
Use 4K size base for buffer explicitly.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
drivers/net/wireless/ti/wl12xx/wl12xx.h | 3 ++-
drivers/net/wireless/ti/wl18xx/wl18xx.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wl12xx/wl12xx.h b/drivers/net/wireless/ti/wl12xx/wl12xx.h
index 9e5484a..3649d40 100644
--- a/drivers/net/wireless/ti/wl12xx/wl12xx.h
+++ b/drivers/net/wireless/ti/wl12xx/wl12xx.h
@@ -56,7 +56,8 @@
#define WL128X_SUBTYPE_MR_VER WLCORE_FW_VER_IGNORE
#define WL128X_MINOR_MR_VER 42
-#define WL12XX_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define WL12XX_PAGE_SIZE 4096
+#define WL12XX_AGGR_BUFFER_SIZE (4 * WL12XX_PAGE_SIZE)
#define WL12XX_NUM_TX_DESCRIPTORS 16
#define WL12XX_NUM_RX_DESCRIPTORS 8
diff --git a/drivers/net/wireless/ti/wl18xx/wl18xx.h b/drivers/net/wireless/ti/wl18xx/wl18xx.h
index 9204e07..a3214b4 100644
--- a/drivers/net/wireless/ti/wl18xx/wl18xx.h
+++ b/drivers/net/wireless/ti/wl18xx/wl18xx.h
@@ -33,7 +33,8 @@
#define WL18XX_CMD_MAX_SIZE 740
-#define WL18XX_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
+#define WL18XX_PAGE_SIZE 4096
+#define WL18XX_AGGR_BUFFER_SIZE (13 * WL18XX_PAGE_SIZE)
#define WL18XX_NUM_TX_DESCRIPTORS 32
#define WL18XX_NUM_RX_DESCRIPTORS 32
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] wlcore: limit base for output buffer in dev_mem_read
From: Vladimir Murzin @ 2013-09-12 15:32 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: coelho, linville, Vladimir Murzin
In-Reply-To: <1378999943-1968-1-git-send-email-murzin.v@gmail.com>
dev_mem_read tries to speed up things a bit by limiting output
buffer which can not exceed WLCORE_MAX_BLOCK_SIZE. However,
WLCORE_MAX_BLOCK_SIZE is based on PAGE_SIZE which may vary.
Use 4K size base for buffer explicitly.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
drivers/net/wireless/ti/wlcore/debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c b/drivers/net/wireless/ti/wlcore/debugfs.c
index e17630c..6b413a7 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -38,7 +38,8 @@
/* ms */
#define WL1271_DEBUGFS_STATS_LIFETIME 1000
-#define WLCORE_MAX_BLOCK_SIZE ((size_t)(4*PAGE_SIZE))
+#define WLCORE_PAGE_SIZE 4096
+#define WLCORE_MAX_BLOCK_SIZE ((size_t)(4*WLCORE_PAGE_SIZE))
/* debugfs macros idea from mac80211 */
int wl1271_format_buffer(char __user *userbuf, size_t count,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/8] ath10k: boot, bmi and mac debug message cleanup
From: Kalle Valo @ 2013-09-12 16:12 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130908145435.3136.49168.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Simple message log cleanup. Please review.
>
> ---
>
> Kalle Valo (8):
> ath10k: add BMI log level
> ath10k: rename ATH10K_DBG_CORE to BOOT
> ath10k: cleanup debug messages in core.c
> ath10k: add boot debug messages to pci.c and ce.c
> ath10k: add boot debug messages to htc.c
> ath10k: add boot messages to htt.c
> ath10k: clean mac.c debug messages
> ath10k: print phymode as a string
Applied.
Kalle
^ permalink raw reply
* Re: [PATCH] ath10k: Calculate correct peer PHY mode for VHT
From: Kalle Valo @ 2013-09-12 16:13 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130908151955.9228.15022.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> The peer PHY mode for 11ac operation needs to be determined
> properly based on the channel bandwidth being used. Fix
> this so that the proper mode is given to the firmware.
>
> kvalo: earlier we used 11na-ht20 in STA mode for 11ac AP peer, this
> patch changes that to 11ac-vht80. I didn't notice any change in
> throughput in my tests, but nevertheless it's the right thing
> to do.
>
> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Applied. Thanks Sujith.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: delete struct ce_sendlist
From: Kalle Valo @ 2013-09-12 16:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130908153611.4572.43965.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> struct ce_sendlist is useless as we always add just one buffer onto it.
> And most importantly, it's ugly as it doesn't use skb properly.
>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 06/12] wireless: ath10k: remove unnecessary pci_set_drvdata()
From: Kalle Valo @ 2013-09-12 16:23 UTC (permalink / raw)
To: Jingoo Han; +Cc: 'John W. Linville', linux-wireless, ath10k
In-Reply-To: <00b701ceae18$69cd1860$3d674920$%han@samsung.com>
Jingoo Han <jg1.han@samsung.com> writes:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/7] ath10k: improve TX path
From: Kalle Valo @ 2013-09-12 16:48 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1378821003-22925-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> This patchset addresses two issues:
>
> * system/userspace starvation on heavy briding
> UDP TX
> * unstable/inconsistent UDP TX throughput
>
> In short the patchset simplifies TX path by
> removing HTC TX workers, makes WMI commands block
> and makes ath10k more responsive to queues
> becoming full. This contributes to both improved
> throughput and makes the system more responsive
> under heavy UDP TX load.
This looks very good, it's great that we can get rid of the TX workers.
Please submit v2 and I'll apply these.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 5/7] ath10k: improve beacon submission latency
From: Kalle Valo @ 2013-09-12 16:47 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1378821003-22925-6-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> The patch prevents beacon misses in some case of
> heavy load on a system.
>
> If a beacon can't be transmitted directly from an
> SWBA event it will be left in arvif->beacon and
> transmission will be retried once TX credits
> become available.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> static void ath10k_wmi_op_ep_tx_credits(struct ath10k *ar)
> {
> + ath10k_wmi_tx_beacons_nowait(ar);
> wake_up(&ar->wmi.tx_credits_wq);
> }
>
> @@ -131,6 +174,7 @@ static int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb,
> int ret = -EINVAL;
>
> wait_event_timeout(ar->wmi.tx_credits_wq, ({
> + ath10k_wmi_tx_beacons_nowait(ar);
> ret = ath10k_wmi_cmd_send_nowait(ar, skb, cmd_id);
> (ret != -EAGAIN);
Please add a short comment to both calls of
ath10k_wmi_tx_beacons_nowait(). Something like "first transmit all
pending beacons" or similar.
--
Kalle Valo
^ permalink raw reply
* iee80211_scan_work crash in 3.11.0+ kernel.
From: Ben Greear @ 2013-09-12 18:32 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
This kernel has our standard set of patches, but nothing much beyond
what we ran in the 3.9 kernel for some time without seeing this particular
crash, so I am thinking it might be something new in 3.11. I do have my
scan-one-channel patch in this tree, so it's possible it is somehow
to blame.
This happened on restart of our user-space app, which would have been
restarting supplicant/hostapd and re-configuring interfaces. It should
not have been actually creating or deleting any network devices as they
were already created.
This crash was in a kernel w/out debugging symbols, but after re-building with
debugging, it decodes to here:
(gdb) l *(ieee80211_scan_work+0x321)
0x8e11 is in ieee80211_scan_work (/home/greearb/git/linux-3.11.dev.y/net/mac80211/scan.c:608).
603 {
604 /*
605 * TODO: channel switching also consumes quite some time,
606 * add that delay as well to get a better estimation
607 */
608 if (chan->flags & IEEE80211_CHAN_PASSIVE_SCAN)
609 return IEEE80211_PASSIVE_CHANNEL_TIME;
610 return IEEE80211_PROBE_DELAY + IEEE80211_CHANNEL_TIME;
611 }
612
(gdb)
Maybe scan_channel_idx is out of bounds somehow?
My 3.11 tree is at:
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.11.dev.y/.git;a=summary
[518743.539126] BUG: unable to handle kernel paging request at 00003b43
[518743.540019] IP: [<f861be11>] ieee80211_scan_work+0x321/0x3e0 [mac80211]
[518743.540019] *pdpt = 0000000016113001 *pde = 0000000000000000
[518743.540019] Oops: 0000 [#1] PREEMPT SMP
[518743.540019] Modules linked in: ipt_MASQUERADE iptable_nat iptable_raw xt_CT veth nfnetlink_log nfnetlink nf_conntrack]
[518743.540019] CPU: 0 PID: 565 Comm: kworker/u4:0 Tainted: G C O 3.11.0+ #20
[518743.645757] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 05/31/20
[518743.645757] Workqueue: phy0 ieee80211_scan_work [mac80211]
[518743.645757] task: f1f54d40 ti: effd8000 task.ti: effd8000
[518743.645757] EIP: 0060:[<f861be11>] EFLAGS: 00010202 CPU: 0
[518743.645757] EIP is at ieee80211_scan_work+0x321/0x3e0 [mac80211]
[518743.645757] EAX: 00003b3b EBX: f463c360 ECX: 1ee6d214 EDX: f465b400
[518743.645757] ESI: 00000000 EDI: 00000001 EBP: effd9ef8 ESP: effd9ec8
[518743.645757] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[518743.645757] CR0: 8005003b CR2: 00003b43 CR3: 2ff88000 CR4: 000007e0
[518743.645757] Stack:
[518743.645757] 0001d7cb f79db400 f463cf2c f463ceb0 f463ce78 f463ce80 1ee6d110 f536eaec
[518743.645757] 00000000 f463cf2c f1ff1a80 00000080 effd9f30 c0471d1a c0487f9d f79db400
[518743.645757] f1f54d40 c0c3e980 efc7eb2a f496f695 f496f600 00001000 f5004400 f1ff1a80
[518743.645757] Call Trace:
[518743.645757] [<c0471d1a>] process_one_work+0x11a/0x400
[518743.645757] [<c0487f9d>] ? try_to_wake_up+0x1bd/0x220
[518743.645757] [<c0472f5f>] worker_thread+0xff/0x3c0
[518743.645757] [<c0477ff4>] kthread+0xa4/0xb0
[518743.645757] [<c0472e60>] ? manage_workers+0x2a0/0x2a0
[518743.645757] [<c0480000>] ? SyS_setgroups+0xb0/0xf0
[518743.645757] [<c09d35b7>] ret_from_kernel_thread+0x1b/0x28
[518743.645757] [<c0477f50>] ? kthread_freezable_should_stop+0x50/0x50
[518743.645757] Code: 01 00 00 00 8b 45 e4 e8 8e cf 3a c8 8b 8b c4 0b 00 00 8b 93 94 0b 00 00 89 4d e8 8b 83 a4 0b 00 00 0
[518743.645757] EIP: [<f861be11>] ieee80211_scan_work+0x321/0x3e0 [mac80211] SS:ESP 0068:effd9ec8
[518743.645757] CR2: 0000000000003b43
[518743.963077] ---[ end trace 7b4bcf9767616f77 ]---
[518743.971245] BUG: unable to handle kernel paging request at ffffffec
[518743.972018] IP: [<c0477a3f>] kthread_data+0xf/0x20
[518743.972018] *pdpt = 0000000000d85001 *pde = 00000000379fd067 *pte = 0000000000000000
[518743.972018] Oops: 0000 [#2] PREEMPT SMP
[518743.972018] Modules linked in: ipt_MASQUERADE iptable_nat iptable_raw xt_CT veth nfnetlink_log nfnetlink nf_conntrack]
[518743.972018] CPU: 0 PID: 565 Comm: kworker/u4:0 Tainted: G D C O 3.11.0+ #20
[518743.972018] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 05/31/20
[518743.972018] task: f1f54d40 ti: effd8000 task.ti: effd8000
[518743.972018] EIP: 0060:[<c0477a3f>] EFLAGS: 00010002 CPU: 0
[518743.972018] EIP is at kthread_data+0xf/0x20
[518743.972018] EAX: 00000000 EBX: 00000000 ECX: f79db400 EDX: 00000000
[518743.972018] ESI: 00000000 EDI: f1f54d40 EBP: effd9c90 ESP: effd9c88
[518743.972018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[518743.972018] CR0: 8005003b CR2: 00000014 CR3: 36fee000 CR4: 000007e0
[518743.972018] Stack:
[518743.972018] c04704e0 f1f54d40 effd9d20 c09cac99 c0c937d4 00000086 00000086 effd9cc4
[518743.972018] f1f54d40 c0d7e400 c0d7e400 c0d7e400 c0d7e400 f5b10b80 00000235 f79db400
[518743.972018] f1f54d40 effd9cec 00000246 c0457098 00000246 0035df80 f1f54d40 f1f54d40
[518743.972018] Call Trace:
[518743.972018] [<c04704e0>] ? wq_worker_sleeping+0x10/0x80
[518743.972018] [<c09cac99>] __schedule+0x5c9/0x7d0
[518743.972018] [<c0457098>] ? __cleanup_sighand+0x28/0x30
[518743.972018] [<c04de8bc>] ? call_rcu+0x1c/0x20
[518743.972018] [<c045a87f>] ? release_task+0x2bf/0x410
[518743.972018] [<c04c2901>] ? cgroup_exit+0x31/0xf0
[518743.972018] [<c09cb043>] schedule+0x23/0x60
[518743.972018] [<c045bb77>] do_exit+0x5f7/0x980
[518743.972018] [<c09c86f3>] ? printk+0x3d/0x3f
[518743.972018] [<c09cdf16>] oops_end+0x96/0xd0
[518743.972018] [<c044bb38>] no_context+0xd8/0x1f0
[518743.972018] [<c044bd08>] __bad_area_nosemaphore+0xb8/0x160
[518743.972018] [<c044bdc7>] bad_area_nosemaphore+0x17/0x20
[518743.972018] [<c09d017d>] __do_page_fault+0x33d/0x4a0
[518743.972018] [<c0490f05>] ? dequeue_task_fair+0x65/0x590
[518743.972018] [<c048c0b6>] ? __dequeue_entity+0x26/0x50
[518743.972018] [<c0410b0e>] ? __switch_to+0xee/0x3b0
[518743.972018] [<c09d02e0>] ? __do_page_fault+0x4a0/0x4a0
[518743.972018] [<c09d02ed>] do_page_fault+0xd/0x10
[518743.972018] [<c09cd6bf>] error_code+0x67/0x6c
[518743.972018] [<f861be11>] ? ieee80211_scan_work+0x321/0x3e0 [mac80211]
[518743.972018] [<c0471d1a>] process_one_work+0x11a/0x400
[518743.972018] [<c0487f9d>] ? try_to_wake_up+0x1bd/0x220
[518743.972018] [<c0472f5f>] worker_thread+0xff/0x3c0
[518743.972018] [<c0477ff4>] kthread+0xa4/0xb0
[518743.972018] [<c0472e60>] ? manage_workers+0x2a0/0x2a0
[518743.972018] [<c0480000>] ? SyS_setgroups+0xb0/0xf0
[518743.972018] [<c09d35b7>] ret_from_kernel_thread+0x1b/0x28
[518743.972018] [<c0477f50>] ? kthread_freezable_should_stop+0x50/0x50
[518743.972018] Code: 8d 74 26 00 64 a1 ac 7f d7 c0 8b 80 9c 02 00 00 5d 8b 40 e4 c1 e8 02 83 e0 01 c3 90 55 89 e5 3e 8d e
[518743.972018] EIP: [<c0477a3f>] kthread_data+0xf/0x20 SS:ESP 0068:effd9c88
[518743.972018] CR2: 00000000ffffffec
[518743.972018] ---[ end trace 7b4bcf9767616f78 ]---
[518743.972018] Fixing recursive fault but reboot is needed!
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Daniel Wagner @ 2013-09-12 18:38 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
Hi John,
On 09/09/2013 09:23 PM, John W. Linville wrote:
> On Thu, Sep 05, 2013 at 11:04:52AM -0500, Dan Williams wrote:
>> On Thu, 2013-09-05 at 09:39 -0400, John W. Linville wrote:
>>> On Thu, Aug 08, 2013 at 03:04:29PM -0400, John W. Linville wrote:
>>>> Sorry, forgot to copy linux-bluetooth and linux-nfc...
>>>>
>>>> On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
>>>>> Greetings!
>>>>>
>>>>> This is a reminder that we will have a Linux Wireless Mini-Summit in
>>>>> New Orleans this year on 19-20 September. This will immediately follow
>>>>> LinuxCon and will run concurrently with Linux Plumber's Conference.
>>>>> This event includes Linux developers for wireless LAN (802.11),
>>>>> Bluetooth, and NFC technologies. Both kernel and userland developers
>>>>> are welcomed and heartily encouraged to attend!
>>>>>
>>>>> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>>>>>
>>>>> The link above is a Wiki. We are using it to collect discussion
>>>>> topics and to negotiate agenda/scheduling options for the event.
>>>>> Please go there to record your intent to attend the event and to
>>>>> propopse topics for discussion.
>>>>>
>>>>> Please be aware that in order to attend the event above one must
>>>>> register for either LinuxCon or for Linux Plumbers Conference.
>>>>> Act now, before those events fill-up and close their registrations!
>>>>>
>>>>> We are allotted one "large" room (up to ~80 people "theater style"), and
>>>>> two "small" rooms (up to ~25 people) for this event. Based on history
>>>>> and the numbers of contributors, the larger room will primarily be
>>>>> for the 802.11 discussions and any "plenary" topics while the smaller
>>>>> rooms will be for Bluetooth, NFC, and any "breakout" topics.
>>>>>
>>>>> So...thoughts? Topics to discuss?
>>>
>>> Ping? We're now just 2 weeks away!
>>>
>>> Is our topic list complete? It looks a bit light...
>>>
>>> Anyone have any input on scheduling the topics? Are there any
>>> overlapping LPC sessions that it would make sense to work around?
>>
>> I'm attending though I haven't put my name on the wiki yet.
>>
>> Random thoughts; it doesn't look like any of these are covered in the
>> regular LinuxConf or LPC sessions.
>>
>> 1) State of the Union (maybe by multiple people in the same session per
>> their expertise), since perhaps not everyone doing eg 802.11 stuff knows
>> what's happening in BT or NFC land, or not everyone working on a
>> specific driver may know what new stuff their driver might need to be
>> fixed up for. Maybe 5 minutes or less for things like:
>>
>> * what's under the most active development right now?
>> * upcoming new driver, hardware, and new capabilities
>> * new 802.11 standards
>> * and what's coming up in the next year from the standards orgs
>> * what people will start working on soon
>> * what will 3.13 or 3.14 look like from a wireless perspective?
>> * 11s mesh status?
>> * anything interesting in wpa_supplicant land?
>> * anything new/interesting on the Android front?
>>
>> 2) Bluetooth - update about what's new and what's coming up in Bluez
>> land, and interaction with kernel 802.11 if any,
>>
>> 3) NFC - update about what's new and what's coming up in NFC land, where
>> it's getting used, what the stack looks like
>>
>> 4) What are users having the most problems with and how these problems
>> be fixed better/more quickly? Are they driver bugs? Are they stack
>> bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
>> development processes that's not working as smoothly as it could be?
>
> Thanks, Dan -- those all look like decent discussion points.
> I've added most of the points above to the topic list:
>
> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>
> Now, we need a few volunteers...
>
> Gustavo, can you do a session on Bluetooth developments?
>
> Samuel, can you cover NFC?
>
> Jouni, would you mind doing your usual update on the standards
> activities? Also, is there anything new/interesting to report on
> wpa_suppliant and/or hostapd?
>
> Johannes, would you cover your vision for mac80211 for the next year
> or so? Anything in progress now that needs to be discussed?
>
> Who should cover any Android topics?
>
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
>
> Seth, Stanislaw, etc -- anyone want to cover issues dealing with
> supporting wireless in distributions?
>
> Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> to share?
Not much news from the user front, though I could give a short
update what's happening on ConnMan if you like.
cheers,
daniel
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: John W. Linville @ 2013-09-12 18:48 UTC (permalink / raw)
To: Daniel Wagner
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <52320A22.1040609@monom.org>
On Thu, Sep 12, 2013 at 08:38:26PM +0200, Daniel Wagner wrote:
> Hi John,
>
> On 09/09/2013 09:23 PM, John W. Linville wrote:
> >Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> >to share?
>
> Not much news from the user front, though I could give a short
> update what's happening on ConnMan if you like.
I think that Patrik Flykt is going to handle that...
Surely there is some infotainment angle to be discussed?? :-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Dan Williams @ 2013-09-12 19:26 UTC (permalink / raw)
To: John W. Linville
Cc: Daniel Wagner, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130912184835.GC14253@tuxdriver.com>
On Thu, 2013-09-12 at 14:48 -0400, John W. Linville wrote:
> On Thu, Sep 12, 2013 at 08:38:26PM +0200, Daniel Wagner wrote:
> > Hi John,
> >
> > On 09/09/2013 09:23 PM, John W. Linville wrote:
>
> > >Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> > >to share?
> >
> > Not much news from the user front, though I could give a short
> > update what's happening on ConnMan if you like.
>
> I think that Patrik Flykt is going to handle that...
>
> Surely there is some infotainment angle to be discussed?? :-)
I can do a short update on NetworkManager too, but there's no
infotainment angle to it at all :)
Dan
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Daniel Wagner @ 2013-09-12 19:31 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130912184835.GC14253@tuxdriver.com>
On 09/12/2013 08:48 PM, John W. Linville wrote:
>> On 09/09/2013 09:23 PM, John W. Linville wrote:
>>> Dan Williams, Daniel Wagner, etc -- anyone got some user stories
>>> to share?
>>
>> Not much news from the user front, though I could give a short
>> update what's happening on ConnMan if you like.
>
> I think that Patrik Flykt is going to handle that...
Great.
> Surely there is some infotainment angle to be discussed?? :-)
Sure, if that is of any interest. There is also the automotive
uconf during the LPC which wireless (BT and Wifi) is shortly
discussed. Repeating/summarizing wouldn't be a problem, I guess.
cheers,
daniel
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Timothy Rundle @ 2013-09-12 23:02 UTC (permalink / raw)
Cc: linux-wireless
In-Reply-To: <5230CDF1.1040905@lwfinger.net>
I finally got some free time to go through all the patches. My results
were similar to Mark's, but I do not get the watchdog messages, though
I am pretty sure watchdog is disabled on my PC. I did even try
installing openSUSE 12.3, but did not have any success. It didn't
even find my wireless network. I manually configured the network via
network-manager, but still no luck.
Let me know if you need anything else from me.
On Wed, Sep 11, 2013 at 4:09 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 09/10/2013 03:04 PM, Mark Cave-Ayland wrote:
>
>> Interesting. Perhaps there is something different in the initial
>> programming of
>> the radio that causes it to crash on my particular hardware revision? As
>> before,
>> please let me know if there is anything else you require.
>
>
> From the log data, you have the same revision as I do.
>
> I am now running a kernel built with your configuration. I needed to make a
> couple of changes as it did not have one of the modules my disk system
> needs, and nouveau caused kernel panics, but we are now operational. Outside
> of the whole system being slow due to only one 2.0 GHz CPU, the wireless
> connection seems to be stable. At least, there have been no disconnects in
> the first half hour.
>
> Larry
>
>
^ 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