Re: MWIFIEX still unstable after two years on MS Surface Pro 3

[Belisko Marek]

Hi Rene,

On Tue, Dec 5, 2017 at 1:31 PM, René Rebe <r...@exactcode.com> wrote:
> Hi Marek,
>
> thank you for your blazingly fast reply.
np.
>
> On 12/05/2017 12:41 PM, Belisko Marek wrote:
>>
>> Hi Rene,
>>
>> On Tue, Dec 5, 2017 at 12:06 PM, René Rebe <r...@exactcode.com> wrote:
>>>
>>> Hi all,
>>>
>>> I write to start a discussion about the state of the mwifiex driver.
>>> For over two years many other and me wait that the driver finally becomes
>>> "stable". However, even with kernel 4.14.2 it still fails after some
>>> minutes, or latest after some hours. With various stray errors in the
>>> system
>>> log:
>>>
>>> Dec  5 09:50:50 surface3 kernel: mwifiex_pcie :01:00.0: info: MWIFIEX
>>> VERSION: mwifiex 1.0 (15.68.7.p119)
>>> Dec  5 09:50:50 surface3 kernel: mwifiex_pcie :01:00.0:
>>> driver_version =
>>> mwifiex 1.0 (15.68.7.p119)
>>>
>>> Dec  5 10:38:28 surface3 kernel: mwifiex_pcie :01:00.0: info: trying
>>> to
>>> associate to 'XXX' bssid xx:xx:xx:xx:xx:xx
>>> Dec  5 10:38:28 surface3 kernel: mwifiex_pcie :01:00.0: info:
>>> associated
>>> to bssid xx:xx:xx:xx:xx:xx successfully
>>> ...
>>> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: Firmware
>>> wakeup
>>> failed
>>
>> As workaround you can disable powersave for wifi (using iw command)
>> and test it should resolve an issue (at least it fixes for me).
>
>
>  13:28:18 up  1:52,
>
> Thanks, so far so good. Are you on a Surface, too?
> Does this also make mwifiex survive a suspend/resume cycle?
> (will try later, when I got work done ;-)
We was struggling with this issue also and found out that disable
powersave resolve issue (as you have maybe a bit higher consumption).
Glad that it helps ;), enjoy. There are some small fixes to avoid this
issue but my theory is that issue is in marvell firmware and this one
needs to be addressed and fixed.
>
> Greetings,
> Rene
> --
>   René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
>   https://exactcode.com | https://t2sde.org | https://rene.rebe.de

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: MWIFIEX still unstable after two years on MS Surface Pro 3

[Belisko Marek]

Hi Rene,

On Tue, Dec 5, 2017 at 12:06 PM, René Rebe  wrote:
> Hi all,
>
> I write to start a discussion about the state of the mwifiex driver.
> For over two years many other and me wait that the driver finally becomes
> "stable". However, even with kernel 4.14.2 it still fails after some
> minutes, or latest after some hours. With various stray errors in the system
> log:
>
> Dec  5 09:50:50 surface3 kernel: mwifiex_pcie :01:00.0: info: MWIFIEX
> VERSION: mwifiex 1.0 (15.68.7.p119)
> Dec  5 09:50:50 surface3 kernel: mwifiex_pcie :01:00.0: driver_version =
> mwifiex 1.0 (15.68.7.p119)
>
> Dec  5 10:38:28 surface3 kernel: mwifiex_pcie :01:00.0: info: trying to
> associate to 'XXX' bssid xx:xx:xx:xx:xx:xx
> Dec  5 10:38:28 surface3 kernel: mwifiex_pcie :01:00.0: info: associated
> to bssid xx:xx:xx:xx:xx:xx successfully
> ...
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: Firmware wakeup
> failed
As workaround you can disable powersave for wifi (using iw command)
and test it should resolve an issue (at least it fixes for me).
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: PREP_CMD: FW in
> reset state
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: PREP_CMD: card
> is removed
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: deleting the
> crypto keys
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: PREP_CMD: card
> is removed
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: deleting the
> crypto keys
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: PREP_CMD: card
> is removed
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: deleting the
> crypto keys
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: PREP_CMD: card
> is removed
> Dec  5 10:42:51 surface3 kernel: mwifiex_pcie :01:00.0: deleting the
> crypto keys
>
> Also, rmmod usually then hangs, and even if it eventually force unloads and
> such re-loading the module does not even get it back into some working
> state. Not even with echoing 1 into the pci reset file.
>
> If this firmware and driver is already for years not working very stable,
> can this not at least recover more gracefully?
>
> Any suggestions how to finally address and solve these issues are welcome.
>
> If someone needs more logs and debug fluff let me know to generate it as
> necessary.
>
> For what it is worth, at least the USB attached mwifi chip in the Surface 2
> appears to work more reliable with the Linux driver.
>
> Best regards,
> René Rebe
>
> --
>   René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
>   http://exactcode.com | http://t2-project.org | http://rene.rebe.de

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

mwifiex: Firmware wakeup failed in 4.1 kernel

[Belisko Marek]

Hi,

I'm using 4.1 stock kernel on imx cpu and 8897 wifi chip connected
over pcie to cpu. I did stress test by disabling AP in loop when wifi
card is connected to perform scanning and reconnect. After 25 attempts
I'll get following and after that wifi is unusable:

mwifiex_pcie :01:00.0: Firmware wakeup failed
 mwifiex_pcie :01:00.0: failed to get signal information
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 mwifiex_pcie :01:00.0: failed to get signal information
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 mwifiex_pcie :01:00.0: failed to get signal information
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 mwifiex_pcie :01:00.0: failed to get signal information
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 mwifiex_pcie :01:00.0: failed to get signal information
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 mwifiex_pcie :01:00.0: failed to get signal information
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 ieee80211 phy0: deleting the crypto keys
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 ieee80211 phy0: deleting the crypto keys
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 ieee80211 phy0: deleting the crypto keys
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 ieee80211 phy0: deleting the crypto keys
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 ieee80211 phy0: deleting the crypto keys
 mwifiex_pcie :01:00.0: PREP_CMD: FW in reset state
 ieee80211 phy0: deleting the crypto keys

I did look to some new patches and found following patch [0] but it
didn't help. Is there anything else I can try to fix this issue?
Thanks a lot.

[0] - https://patchwork.kernel.org/patch/9516615/

BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

ad-hoc mode max speed on 8812au wifi card

[Belisko Marek]

Hi,

I'm doing small research on mesh with batman-adv module by using
8812au wifi adapters. I can setup 2 nodes mesh network in 2.4 or 5GHz
bands but max speed (tested with iperf) is only ~2.5MBytes. I read
something about limitation of ad-hoc that speed is restricted to
11Mbits even if it's connected in 5GHz channels. I can assume that
this limitation is due some wifi aliance restriction or is there other
reason (like avoid too many transmissions)? Would be possible to
increase ad-hoc mode speed somehow when using 8812au wifi card. Thanks
a lot for replies and hints.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: ad-hoc in 5GHz

[Belisko Marek]

Hi Stanislaw,

On Wed, Jan 11, 2017 at 11:10 AM, Stanislaw Gruszka <sgrus...@redhat.com> wrote:
> Hi
>
> On Wed, Jan 11, 2017 at 09:36:00AM +0100, Belisko Marek wrote:
>> this should be general question. I'm using [0] ralink driver to setup
>
> It's Realtek not Ralink, right ?
Ah sorry yes it's Realtek.
>
>> ad-hoc mode. It works fine in 2.4GHz band (channel 1) but when I try
>> to setup ad-hoc for 5GHz (channel 50) it seems it's not working at all
>> (I tried to scan with other device but I cannot ad-hoc network). So my
>> question should ad-hoc mode work in 5GHz band also or there are some
>> restrictions? Many thanks.
>
> Depending on regulatory setting IBSS or IR (initialize radiation) can be
> prohibited on some 5GHz channels, check "iw phy" to see which 5GHz channels
> are allowed to use. If HW hardcoded regulatory do not prohibits IBSS on all
> 5GHZ channels it can be matter or setting proper regulatory domain
> (configure timezone properly and then setregdomain will set domain based
> on it).
I did check that and I use 'iw reg set US' (to setup other regulatory
than 00). But despite of that
I still cannot get 5GHz working. Maybe it's driver issue. Thanks.
>
> Regards
> Stanislaw

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

ad-hoc in 5GHz

[Belisko Marek]

Hi,

this should be general question. I'm using [0] ralink driver to setup
ad-hoc mode. It works fine in 2.4GHz band (channel 1) but when I try
to setup ad-hoc for 5GHz (channel 50) it seems it's not working at all
(I tried to scan with other device but I cannot ad-hoc network). So my
question should ad-hoc mode work in 5GHz band also or there are some
restrictions? Many thanks.

[0] - https://github.com/diederikdehaas/rtl8812AU

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: iw reg overwritten after connecting to AP

[Belisko Marek]

Hi Krishna,

On Thu, Jun 2, 2016 at 10:21 PM, Krishna Chaitanya
<chaitanya.m...@gmail.com> wrote:
> On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek <marek.beli...@gmail.com> wrote:
>>
>> Hello,
>>
>> I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB
>> enabled. I have set one country in db.txt which during startup I set
>> via 'iw reg set XX'. When connected to some AP which sends country
>> code (e.g. SK) region is overwritten to 00 (in kernel log there is
>> some timeout message - I suppose it's communication with crda daemon
>> which I'm not using). Is there a way how to override this behavior (to
>> keep my regulatory persistent). Many thanks.
>>
> You need to disable country_ie hints, you driver has to advertise
> REGULATORY_WIPHY_SELF_MANAGED in the wiphy.regualtory_flags
> to disable beacon and country_ie hints.
I would like to keep beacon hinting (maybe disable only country_ie). I
have same setup but with 3.9 kernel and regulatory isn't overwritten.
>
> Which driver are you using?
I'm using mwifiex driver

Thanks,

BR,

marek


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

iw reg overwritten after connecting to AP

[Belisko Marek]

Hello,

I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB
enabled. I have set one country in db.txt which during startup I set
via 'iw reg set XX'. When connected to some AP which sends country
code (e.g. SK) region is overwritten to 00 (in kernel log there is
some timeout message - I suppose it's communication with crda daemon
which I'm not using). Is there a way how to override this behavior (to
keep my regulatory persistent). Many thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex 8897 disable 11ac in sta mode

[Belisko Marek]

Hi,

On Wed, May 4, 2016 at 3:04 PM, Amitkumar Karwar <akar...@marvell.com> wrote:
> Hi Marek,
>
>> From: Belisko Marek [mailto:marek.beli...@gmail.com]
>> Sent: Wednesday, May 04, 2016 5:48 PM
>> To: linux-wireless@vger.kernel.org; Amitkumar Karwar
>> Subject: mwifiex 8897 disable 11ac in sta mode
>>
>> Hi,
>>
>> it is possible somehow to disable 11ac in mwifiex driver for sta mode(I
>> tried in wpa_supplicant by disable_vht without success). Any ideas? Many
>> thanks.
>
> There is not standard way. You can try attached hack.
Thanks. It helps.
>
> Regards,
> Amitkumar

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel log flooded with GET_CMD_NODE: cmd node not available

[Belisko Marek]

On Wed, Sep 16, 2015 at 8:40 AM, Amitkumar Karwar <akar...@marvell.com> wrote:
>> From: Marty Faltesek [mailto:mfalte...@google.com]
>> Sent: Friday, September 04, 2015 3:21 AM
>> To: Belisko Marek
>> Cc: Amitkumar Karwar; linux-wireless@vger.kernel.org
>> Subject: Re: kernel log flooded with GET_CMD_NODE: cmd node not
>> available
>>
>> On Mon, Aug 31, 2015 at 7:54 AM, Belisko Marek <marek.beli...@gmail.com>
>> wrote:
>> > [  182.069146] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not
>> > available [  182.076350] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free
>> > cmd node [  182.085102] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd
>> > node not available [  182.092297] mwifiex_sdio mmc0:0001:1: PREP_CMD:
>> > no free cmd node [  182.103276] mwifiex_sdio mmc0:0001:1:
>> > GET_CMD_NODE: cmd node not available [  182.110478] mwifiex_sdio
>> > mmc0:0001:1: PREP_CMD: no free cmd node [  182.121156] mwifiex_sdio
>> > mmc0:0001:1: GET_CMD_NODE: cmd node not available [  182.128360]
>> > mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node [  182.134750]
>> > mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available [
>> > 182.141927] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
>>
>> We are also seeing these messages after recently switching to more
>> recent drivers.
>
> Marty confirmed that this problem got resolved after backporting below change 
> to his codebase.
Same here. This patch should be marked for stable also. Many thanks.
>
> http://www.spinics.net/lists/linux-wireless/msg137134.html
>
> Regards,
> Amitkumar

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

kernel log flooded with GET_CMD_NODE: cmd node not available

[Belisko Marek]

Hi,

I'm running kernel 4.1 (no code changes in mwifiex) on custom board
with mwrvl sd8787 sdio wifi card. Everything works fine but when I
start hostapd and connect to device from PC  and open device webpage I
can see in log many of such messages (~100 same lines):
GET_CMD_NODE: cmd node not available
PREP_CMD: no free cmd node

I'm using fw: 14.66.35.p25

With 3.19 kernel I cannot see any of such messages. Any ideas? Thanks.

BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel log flooded with GET_CMD_NODE: cmd node not available

[Belisko Marek]

Hi Amitkumar,

find below dmesg

On Mon, Aug 31, 2015 at 1:44 PM, Amitkumar Karwar  wrote:
> Hi Belisko,
>
>> I'm running kernel 4.1 (no code changes in mwifiex) on custom board with
>> mwrvl sd8787 sdio wifi card. Everything works fine but when I start
>> hostapd and connect to device from PC  and open device webpage I can see
>> in log many of such messages (~100 same lines):
>> GET_CMD_NODE: cmd node not available
>> PREP_CMD: no free cmd node
>
> Could you share complete dmesg log?
>
> Regards,
> Amitkumar

[8.014039] udevd[84]: starting version 182
[9.951563] cfg80211: Calling CRDA to update world regulatory domain
[   11.571515] Bluetooth: Vendor=0x2df, Device=0x911a, Class=255, Fn=2
[   13.111987] cfg80211: Calling CRDA to update world regulatory domain
[   16.271552] cfg80211: Calling CRDA to update world regulatory domain
[   17.062728] random: nonblocking pool is initialized
[   17.302971] Bluetooth: FW download over, size 456660 bytes
[   17.953975] mwifiex_sdio mmc0:0001:1: WLAN FW already running! Skip FW dnld
[   17.954011] mwifiex_sdio mmc0:0001:1: WLAN FW is active
[   18.067233] ieee80211 phy0: ignoring F/W country code US
[   18.148485] mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0
(14.66.35.p25)
[   19.432103] cfg80211: Calling CRDA to update world regulatory domain
[   22.594066] cfg80211: Calling CRDA to update world regulatory domain
[   25.751568] cfg80211: Calling CRDA to update world regulatory domain
[   28.911566] cfg80211: Calling CRDA to update world regulatory domain
[   29.533669] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   30.069695] net eth0: initializing cpsw version 1.12 (0)
[   30.170530] net eth0: phy found : id is : 0x4dd076
[   30.170779] libphy: PHY  not found
[   30.175233] net eth0: phy  not found on slave 1
[   30.188658] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   30.658135] net eth0: initializing cpsw version 1.12 (0)
[   30.733308] net eth0: phy found : id is : 0x4dd076
[   30.733523] libphy: PHY  not found
[   30.737088] net eth0: phy  not found on slave 1
[   30.788634] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   32.071633] cfg80211: Calling CRDA to update world regulatory domain
[   35.231609] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
[   44.044608] IPv6: ADDRCONF(NETDEV_UP): uap0: link is not ready
[   44.265485] net eth0: initializing cpsw version 1.12 (0)
[   44.343401] net eth0: phy found : id is : 0x4dd076
[   44.343620] libphy: PHY  not found
[   44.347189] net eth0: phy  not found on slave 1
[   44.391060] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   44.637269] IPv6: ADDRCONF(NETDEV_UP): uap0: link is not ready
[   66.680521] IPv6: ADDRCONF(NETDEV_CHANGE): uap0: link becomes ready
[  181.559447] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.566655] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.577016] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.584219] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.596305] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.603518] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.616659] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.623871] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.630337] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.637520] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.643923] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.651103] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.657904] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.665091] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.671702] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.678887] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.699303] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.706515] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.718104] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.725309] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.734723] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.741922] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.752621] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.759828] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.769583] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.776787] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.784389] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.791585] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.806670] mwifiex_sdio mmc0:0001:1: GET_CMD_NODE: cmd node not available
[  181.813876] mwifiex_sdio mmc0:0001:1: PREP_CMD: no free cmd node
[  181.823657] 

Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[Belisko Marek]

Hi Amitkumar,

On Thu, Oct 23, 2014 at 2:40 PM, Amitkumar Karwar akar...@marvell.com wrote:
 Hi Marek,

 I tried to capture logs but when enable DYNAMIC_DEBUG I cannot
 reproduce issue (running test  30 minutes without allocation
 failure).

 Thanks for the testing. Yes. Sometimes timing issues won't get reproduced 
 with debug messages enabled.

Any update on this? Should I provide some other logs?

 What's the size of Rx data packets? Is the Rx data AMSDU aggregated?(You can 
 check if if (rx_pkt_type == PKT_TYPE_AMSDU) check is passed in mwifiex 
 code) If so, disable AMSDU option in AP and try to reproduce the issue.
Size of Rx data packets are : pkt type == 2, size - 1574bytes + BAR
pkt type, size - 34bytes. AMSDU isn't enabled on AP (verified by
adding debug message in mwifiex_process_sta_rx_packet()).

 As you suspected earlier, we might have missed to free skbs allocated for Rx 
 data which leads to SKB allocation failure. There is very less probability 
 for this. But we can try below experiment.

 1) I observed that debug variable adapter-rx_pending doesn;t get 
 decremented when packet is submitted to kernel. Add below code change(valid 
 only for AMSDU disabled case. Because multiple packets are submitted to 
 kernel when AMSDU is enabled)

 --
 --- a/drivers/net/wireless/mwifiex/util.c
 +++ b/drivers/net/wireless/mwifiex/util.c
 @@ -218,6 +218,7 @@ int mwifiex_recv_packet(struct mwifiex_private *priv, 
 struct sk_buff *skb)

 priv-stats.rx_bytes += skb-len;
 priv-stats.rx_packets++;
 +   atomic_dec(priv-adapter-rx_pending);
 if (in_interrupt())
 netif_rx(skb);
 --
OK, patch applied.

 2) Add BUG_ON when first time SKB allocation is failed and print 
 rx_pending. If it's a huge number, we have missed freeing allocated SKB.
[  167.624452] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb
failed, rx_pending:26893
[  167.632885] [ cut here ]
[  167.637743] Kernel BUG at bf8a22ae [verbose debug info unavailable]
so number seems to be huge and we seems miss free allocated skb.

I did some hacks to code which shows how many packets are received
between 2 BAR packets + I print every 500ms rx_pending packets (when
packet is received) and
also when packet is send to kernel. I also update counter how many
packets after reordering are sent to kernel. Log:
[   71.973800] usb 1-1: rx_pending:11
[   72.077308] usb 1-1: rx_pending kernel:10
[   72.477546] usb 1-1: rx_pending:868
[   72.587877] usb 1-1: rx_pending kernel:1096
[   72.818041] usb 1-1: Received between 2 BAR:6275
[   72.823127] usb 1-1: Networking send size:6271
[   72.987375] usb 1-1: rx_pending:1940
[   73.097504] usb 1-1: rx_pending kernel:2159
[   73.431973] usb 1-1: Received between 2 BAR:1602
[   73.437106] usb 1-1: Networking send size:1608
[   73.497381] usb 1-1: rx_pending:2983
[   73.608315] usb 1-1: rx_pending kernel:3091
[   74.007379] usb 1-1: rx_pending:3767
[   74.117879] usb 1-1: rx_pending kernel:3998
[   74.517375] usb 1-1: rx_pending:4854
[   74.543168] usb 1-1: Received between 2 BAR:3152
[   74.548371] usb 1-1: Networking send size:3152
[   74.627509] usb 1-1: rx_pending kernel:5062
[   74.743362] usb 1-1: Received between 2 BAR:495
[   74.748483] usb 1-1: Networking send size:494
[   75.027523] usb 1-1: rx_pending:5872
[   75.137961] usb 1-1: rx_pending kernel:6106
[   75.537485] usb 1-1: rx_pending:6959
[   75.647934] usb 1-1: rx_pending kernel:7188
[   75.656273] usb 1-1: Received between 2 BAR:2383
[   75.661528] usb 1-1: Networking send size:2382
[   76.047441] usb 1-1: rx_pending:8004
[   76.157712] usb 1-1: rx_pending kernel:8240
[   76.557547] usb 1-1: rx_pending:9095
[   76.667991] usb 1-1: rx_pending kernel:9326
[   76.769662] usb 1-1: Received between 2 BAR:2918
[   76.775047] usb 1-1: Networking send size:2914
[   77.067491] usb 1-1: rx_pending:10155
[   77.177524] usb 1-1: rx_pending kernel:10383
[   77.577547] usb 1-1: rx_pending:11237
[   77.687859] usb 1-1: rx_pending kernel:11461
[   78.087401] usb 1-1: rx_pending:12304
[   78.197992] usb 1-1: rx_pending kernel:12539
[   78.597442] usb 1-1: rx_pending:13391
[   78.707786] usb 1-1: rx_pending kernel:13628
[   79.107487] usb 1-1: rx_pending:14469
[   79.217812] usb 1-1: rx_pending kernel:14704
[   79.617528] usb 1-1: rx_pending:1
[   79.727734] usb 1-1: rx_pending kernel:15781
[   80.127486] usb 1-1: rx_pending:16624
[   80.237756] usb 1-1: rx_pending kernel:16855
[   80.637423] usb 1-1: rx_pending:17699
[   80.747868] usb 1-1: rx_pending kernel:17926
[   81.147446] usb 1-1: rx_pending:18769
[   81.257800] usb 1-1: rx_pending kernel:18995
[   81.657399] usb 1-1: rx_pending:19851
[   81.767785] usb 1-1: rx_pending kernel:20083
[   82.167341] usb 1-1: rx_pending:20938
[   82.278005] usb 1-1: rx_pending kernel:21174
[   82.677527] usb 1-1: rx_pending:22025
[   82.787508] usb 1-1: rx_pending kernel:22246
[   83.187390] usb 1-1: rx_pending:23103
[   83.297690] usb 1-1: 

Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[Belisko Marek]

Dear James Cameron,

On Tue, Oct 14, 2014 at 12:20 PM, James Cameron qu...@laptop.org wrote:
 On Tue, Oct 14, 2014 at 10:25:01AM +0200, Belisko Marek wrote:
 Hi Amitkumar,

 On Tue, Oct 14, 2014 at 9:08 AM, Amitkumar Karwar akar...@marvell.com 
 wrote:
  Hi Marek,
 
   I tried both (slightly modified as we're in 3.9 kernel) but
   issue is still reproducible. My patch against 3.9 sources:
 
  Thanks a lot for the tests.
 
   One thing which is not yet still clear to me why kernel console
   is completely unresponsive when receiving packets in high
   rates. When use iperf (on client) with -b40m it is OK but when
   increase to -b100m then console is completely unresponsive until
   iperf finish.
 
  Does the system recover when -b100M iperf is finished? Can we
  run iperf with -b40M later?  Do you see dev_alloc_skb failed
  messages in dmesg when console is unresponsive?
 When we get dev_alloc_skb failed then interface is dead (cannot
 ping ...) so no recovery is possible only system reboot.

 This symptom was familiar to me, but on sdio.c, which is very
 different code.

 I've had a brief look at usb.c and offer the following comments:

 - a list of six data endpoint urb is allocated in mwifiex_usb_rx_init,
   because MWIFIEX_RX_DATA_URB is 6,

 - when data endpoint urb is submitted, a new skb is allocated, in
   mwifiex_usb_submit_rx_urb, and this is the only source of
   dev_alloc_skb failed message,

 - in normal situation, when data endpoint urb is complete, skb is
   either freed or handed up to mwifiex_usb_recv, and the urb is
   resubmitted, which causes a new skb to be allocated.

 - if dev_alloc_skb failed message appears, one data endpoint urb has
   been lost and is not re-used,

 - if six dev_alloc_skb failed messages appear, the interface should
   be dead for data receive only.

 Amitkumar mentioned this on 9th October; corresponding URB won't get
 submitted.  I think this should be fixed; dev_alloc_skb should be
 harmless failure, please retry.

 I don't see why interface is dead with only one dev_alloc_skb
 failed message.
Maybe my description wasn't  not correct. I see 6 dev_alloc_skb
failed messages and then interface is dead
as you wrote.

 I don't see  dev_alloc_skb failed when console is unresponsive.
 
   Any other ideas
   what to change to check? Thanks.
 
  Could you please share dmesg log with dynamic debug enabled (using
  attached script) captured when the problem occurs?
 I tried to capture logs but when enable DYNAMIC_DEBUG I cannot
 reproduce issue (running test  30 minutes without allocation
 failure).

 Yes, I've seen similar; turn on debugging, and timing critical bug
 goes away.

 Serial console?  If so, try turning it off, and logging to dmesg
 buffer only.
When turning off serial console how then I get kernel messages from
dmesg buffer?

 --
 James Cameron
 http://quozl.linux.org.au/

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[Belisko Marek]

Dear Amitkumar Karwar,

On Wed, Sep 17, 2014 at 12:52 PM, Amitkumar Karwar akar...@marvell.com wrote:
 Hi BR,

 Dear Amitkumar Karwar,

 some additional info.

 On Thu, Sep 11, 2014 at 5:09 PM, Amitkumar Karwar akar...@marvell.com
 wrote:
  Hi BR,
 
 
  I'm using 3.9 mainline mwifiex driver for wireless usb card. Doing
  some throughput testing (with iperf) in 5GHz I got following
 failures:
  [ 221.521799] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb
  failed
 
  This is skb allocation failure returned by kernel. 4k buffer is
 always allocated for Rx packets. This issue doesn't seem to be specific
 to 5Ghz.
 Yes you're right. I can reproduce issue also with 2.4GHz (doing iperf
 testing as mentioned in other email) by pinging device with card.
 
 
  I checked which which size fails to allocate and it's 4096 bytes. I
  was looking to changes in never kernel releases but I cannot find
  anything obvious. When connected to 2.4GHz I cannot reproduce issue
  though. I'm using FW version mwifiex 1.0 (14.68.29.p26).
 
 
  Could you please provide the platform details?
  How often the problem occurs during throughput testing? Are there any
 specific steps?
 One more observation is that when problem occurred complete system is
 unresponsive (console is almost completely dead).

 Thanks for the more information.
 Skb alloc failure should be gracefully handled. We will look into this issue.
I did small investigation (will my limited networking knowledge :))
and to avoid usb issue
I did small hack to free received packet in skb (with specific size
1574 which sends iperf) before sending for
processing to driver workqueue. With this small hack I can run iperf
-b100m on client size without any
allocation issue. Bit more testing shows that 11n rx reordering is in
place when receiving packets send from iperf.
Is there any know issue in this area which could lead to issues
described in my report?

BTW I tested backports driver from 3.17-rc3 and issue is still present.


 I can workaround issue by decreasing iperf bandwidth to ~40m. I think
 in this situation we're running out of memory by exhaustive skb
 allocations.

 Actually 6 4K size buffers are being allocated for Rx and Tx data during 
 traffic.
 Probably your platform runs out of memory after these allocations.

 Could you please try changing this 
 number(MWIFIEX_TX_DATA_URB/MWIFIEX_RX_DATA_URB macros) to 3?

 Regards,
 Amitkumar Karwar

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[Belisko Marek]

Dear Amitkumar Karwar,


On Thu, Oct 9, 2014 at 11:30 AM, Amitkumar Karwar akar...@marvell.com wrote:
 Hi Marek,

 Sorry for late reply. We have tried to simulate dev_alloc_skb() failure on 
 our reference platform after 100th, 200th, 300th etc. packets. Our 
 observation is when the failure occurs, corresponding URB won't get 
 submitted, but traffic continues. Traffic stops when the failure count 
 reaches 6 (mwifiex Rx URB count). We don't see any crash or system 
 unresponsiveness.
No I don't see such behavior. In my case usb still sending packets
over URB (also proven by below hack). My platform is am335x (same chip
as on beaglebone).


 I did small investigation (will my limited networking knowledge :)) and
 to avoid usb issue I did small hack to free received packet in skb
 (with specific size
 1574 which sends iperf) before sending for processing to driver
 workqueue. With this small hack I can run iperf -b100m on client size
 without any allocation issue.

 That's good :) Actually kernel will take care of freeing skb when driver 
 submits received packet using netif_rx(). Could you please share your hack?
Yes it should be freed when netif_rx() is processed but I have feeling
that sometimes (my case) during high load (-b 100m) packets are not
send to kernel (not free skb)
until skb allocation fails. I need to better understand 11n reordering code :).

Hack (it's dirty I know but packets of that size are send only during
iperf session):

diff --git a/drivers/net/wireless/mwifiex/usb.c
b/drivers/net/wireless/mwifiex/usb.c
index f90fe21..cc548a1 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -178,6 +178,12 @@ static void mwifiex_usb_rx_complete(struct urb *urb)
dev_dbg(adapter-dev, info: recv_length=%d, status=%d\n,
recv_length, status);
if (status == -EINPROGRESS) {
+
+   if (skb-len = 1574) {
+   dev_kfree_skb_any(skb);
+   goto setup_for_next;
+   }
+
queue_work(adapter-workqueue, adapter-main_work);

/* urb for data_ep is re-submitted now;

 Regards,
 Amit

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[Belisko Marek]

Hi,

I was too fast when hitting Send :)

On Wed, Sep 17, 2014 at 2:07 PM, Belisko Marek marek.beli...@gmail.com wrote:
 Dear Amitkumar Karwar,

 On Wed, Sep 17, 2014 at 12:52 PM, Amitkumar Karwar akar...@marvell.com 
 wrote:
 Hi BR,

 Dear Amitkumar Karwar,

 some additional info.

 On Thu, Sep 11, 2014 at 5:09 PM, Amitkumar Karwar akar...@marvell.com
 wrote:
  Hi BR,
 
 
  I'm using 3.9 mainline mwifiex driver for wireless usb card. Doing
  some throughput testing (with iperf) in 5GHz I got following
 failures:
  [ 221.521799] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb
  failed
 
  This is skb allocation failure returned by kernel. 4k buffer is
 always allocated for Rx packets. This issue doesn't seem to be specific
 to 5Ghz.
 Yes you're right. I can reproduce issue also with 2.4GHz (doing iperf
 testing as mentioned in other email) by pinging device with card.
 
 
  I checked which which size fails to allocate and it's 4096 bytes. I
  was looking to changes in never kernel releases but I cannot find
  anything obvious. When connected to 2.4GHz I cannot reproduce issue
  though. I'm using FW version mwifiex 1.0 (14.68.29.p26).
 
 
  Could you please provide the platform details?
  How often the problem occurs during throughput testing? Are there any
 specific steps?
 One more observation is that when problem occurred complete system is
 unresponsive (console is almost completely dead).

 Thanks for the more information.
 Skb alloc failure should be gracefully handled. We will look into this issue.
 OK. Thanks. Can you please
Can you please ping me when you will have some patch so I can test it
also on my device.

 I can workaround issue by decreasing iperf bandwidth to ~40m. I think
 in this situation we're running out of memory by exhaustive skb
 allocations.

 Actually 6 4K size buffers are being allocated for Rx and Tx data during 
 traffic.
 Probably your platform runs out of memory after these allocations.
 This could be the issue. I'm running some apps when performing
 throughput test and this could lead
 to out of memory. When I stop all apps and perform the test it behave
 better (I cannot reproduce issue) except of
 fact that whole system is unresponsive for ~ 10 secs as was already mentioned.
This is not fully true. I run loop iperf test (-t 600) and it will
fail after 4 minutes with (there was around 190MB free memory):

[  875.249551] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed
[  875.256645] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed
[  875.263694] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed
[  875.270940] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed
[  875.277993] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed
[  875.285068] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed
[  3]  0.0- 1.0 sec  81.8 KBytes670 Kbits/sec  0.034 ms0/   57 (0%)
[  3]  1.0- 2.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  2.0- 3.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  3.0- 4.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  4.0- 5.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  5.0- 6.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  6.0- 7.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  7.0- 8.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  8.0- 9.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3]  9.0-10.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3] 10.0-11.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3] 11.0-12.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3] 12.0-13.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3] 13.0-14.0 sec  0.00 Bytes  0.00 bits/sec  0.034 ms0/0 (nan%)
[  3] 14.0-15.0 sec  81.8 KBytes670 Kbits/sec  24.506 ms   60/  117 (51%)


[ 1019.644302] usb 1-1: mwifiex_cmd_timeout_func: Timeout cmd id
(1410955919.418091) = 0x6, act = 0x3
[ 1019.653826] usb 1-1: num_data_h2c_failure = 0
[ 1019.658409] usb 1-1: num_cmd_h2c_failure = 0
[ 1019.662907] usb 1-1: num_cmd_timeout = 1
[ 1019.667072] usb 1-1: num_tx_timeout = 0
[ 1019.671117] usb 1-1: last_cmd_index = 4
[ 1019.675186] usb 1-1: last_cmd_id: 28 00 28 00 28 00 5b 00 06 00
[ 1019.681426] usb 1-1: last_cmd_act: 13 01 13 01 13 01 01 00 03 00
[ 1019.687778] usb 1-1: last_cmd_resp_index = 3
[ 1019.692281] usb 1-1: last_cmd_resp_id: 28 80 28 80 28 80 5b 80 28 80
[ 1019.698997] usb 1-1: last_event_index = 2
[ 1019.703223] usb 1-1: last_event: 17 00 33 00 08 00 33 00 08 00
[ 1019.709389] usb 1-1: data_sent=0 cmd_sent=0
[ 1019.713820] usb 1-1: ps_mode=1 ps_state=0
[ 1019.718211] usb 1-1: cmd timeout


 Could you please try changing this 
 number(MWIFIEX_TX_DATA_URB/MWIFIEX_RX_DATA_URB macros) to 3?
I tried but it doesn't help (also sometimes I see odd driver crashes -
NULL pointer access)

 Regards,
 Amitkumar Karwar

 Best

mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[Belisko Marek]

Hello,

I'm using 3.9 mainline mwifiex driver for wireless usb card. Doing
some throughput testing (with iperf) in 5GHz I got following failures:
[ 221.521799] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed

I checked which which size fails to allocate and it's 4096 bytes. I
was looking to changes in never kernel releases but I cannot find
anything obvious. When connected to 2.4GHz I cannot reproduce issue
though. I'm using FW version mwifiex 1.0 (14.68.29.p26).

Thank for any help/hints,

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[Belisko Marek]

Dear Amitkumar Karwar,

On Thu, Sep 11, 2014 at 5:09 PM, Amitkumar Karwar akar...@marvell.com wrote:
 Hi BR,


 I'm using 3.9 mainline mwifiex driver for wireless usb card. Doing some
 throughput testing (with iperf) in 5GHz I got following failures:
 [ 221.521799] usb 1-1: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed

 This is skb allocation failure returned by kernel. 4k buffer is always 
 allocated for Rx packets. This issue doesn't seem to be specific to 5Ghz.
OK. But I cannot reproduce this issue when connected to 2.4GHz (same
steps as described below).
.

 I checked which which size fails to allocate and it's 4096 bytes. I was
 looking to changes in never kernel releases but I cannot find anything
 obvious. When connected to 2.4GHz I cannot reproduce issue though. I'm
 using FW version mwifiex 1.0 (14.68.29.p26).


 Could you please provide the platform details?
 How often the problem occurs during throughput testing? Are there any 
 specific steps?
I can reproduce problem 100% by running iperf as server on board where
wifi is connected to  (iperf -s -u -w1M -i1)
and connecting with iperf client from other PC (iperf -c IPADDR -u -b 100m).
Then immediately I can see allocation failures. If you need more info
please let me know. Thanks.

 Regards,
 Amitkumar Karwar

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html