* iwlwifi + wpa2-leap + multiple AP's = call trace
From: Ismael Farfán @ 2016-07-13 0:29 UTC (permalink / raw)
To: linux-wireless
Hello list
I searched this error around and didn't find anything, so here it goes.
Today I tried to connect to an enterprise network, which means,
literally, tens of AP's sharing the same name... the network requieres
user/password authentication (wpa2-leap).
I'm using Arch
$ uname -a
Linux 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 GNU/Linux
Since the thing just didn't connect, I checked dmesg and found this:
Any ideas?
[ 83.030072] wifi0: aborting authentication with xx:xx:xx:xx:xx:xx
by local choice (Reason: 3=DEAUTH_LEAVING)
[ 83.030073] ------------[ cut here ]------------
[ 83.030082] WARNING: CPU: 2 PID: 1087 at
drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:507 iwl_mvm_tim
e_event_send_add+0x1c6/0x200 [iwlmvm]
[ 83.030157] CPU: 2 PID: 1087 Comm: wpa_supplicant Tainted: G
O 4.6.3-1-ARCH #1
[ 83.030158] Hardware name: Notebook
P65_P67SA /P65_P67SA
, BIOS 1.03.01 07/22/2015
[ 83.030160] 0000000000000286 0000000009e998bc ffff880403a5b940
ffffffff812e54c2
[ 83.030162] 0000000000000000 0000000000000000 ffff880403a5b980
ffffffff8107a6bb
[ 83.030164] 000001fb81a8a180 ffff88041b443580 ffff88041c329548
00000000fffffffb
[ 83.030167] Call Trace:
[ 83.030172] [<ffffffff812e54c2>] dump_stack+0x63/0x81
[ 83.030174] [<ffffffff8107a6bb>] __warn+0xcb/0xf0
[ 83.030176] [<ffffffff8107a7ed>] warn_slowpath_null+0x1d/0x20
[ 83.030181] [<ffffffffa0b068d6>]
iwl_mvm_time_event_send_add+0x1c6/0x200 [iwlmvm]
[ 83.030184] [<ffffffff810c4772>] ? up+0x32/0x50
[ 83.030187] [<ffffffff810d371b>] ? wake_up_klogd+0x3b/0x50
[ 83.030189] [<ffffffff810d3c19>] ? console_unlock+0x4e9/0x590
[ 83.030193] [<ffffffffa0b07520>]
iwl_mvm_protect_session+0x220/0x280 [iwlmvm]
[ 83.030196] [<ffffffffa0af100e>] ? iwl_mvm_ref_sync+0x2e/0x140 [iwlmvm]
[ 83.030199] [<ffffffff810d423f>] ? vprintk_default+0x1f/0x30
[ 83.030202] [<ffffffffa0af154a>]
iwl_mvm_mac_mgd_prepare_tx+0x5a/0xa0 [iwlmvm]
[ 83.030216] [<ffffffffa0c8e198>] ieee80211_mgd_deauth+0x338/0x4d0 [mac80211]
[ 83.030219] [<ffffffff810b2333>] ? enqueue_entity+0x323/0xd70
[ 83.030228] [<ffffffffa0c579b8>] ieee80211_deauth+0x18/0x20 [mac80211]
[ 83.030237] [<ffffffffa05a1b8f>] cfg80211_mlme_deauth+0x9f/0x1a0 [cfg80211]
[ 83.030242] [<ffffffffa05a62da>] cfg80211_disconnect+0x9a/0x200 [cfg80211]
[ 83.030248] [<ffffffffa05c4529>]
cfg80211_mgd_wext_siwessid+0xa9/0x170 [cfg80211]
[ 83.030255] [<ffffffffa05c3512>] cfg80211_wext_siwessid+0x22/0x40 [cfg80211]
[ 83.030258] [<ffffffff815af803>] ioctl_standard_iw_point+0x133/0x350
[ 83.030264] [<ffffffffa05c34f0>] ?
cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
[ 83.030266] [<ffffffff810a4a82>] ? wake_up_q+0x32/0x70
[ 83.030268] [<ffffffff815b0930>] ? iw_handler_get_private+0x60/0x60
[ 83.030271] [<ffffffff815afd07>] ioctl_standard_call+0x87/0xd0
[ 83.030273] [<ffffffff815afc80>] ? call_commit_handler.part.4+0x30/0x30
[ 83.030275] [<ffffffff815afc10>] wireless_process_ioctl+0x1f0/0x230
[ 83.030278] [<ffffffff814b52fe>] ? dev_get_by_name_rcu+0x5e/0x80
[ 83.030280] [<ffffffff815aff58>] wext_handle_ioctl+0x78/0xd0
[ 83.030283] [<ffffffff814d7777>] dev_ioctl+0x2a7/0x5a0
[ 83.030285] [<ffffffff8149dc86>] sock_ioctl+0x126/0x290
[ 83.030287] [<ffffffff81209be3>] do_vfs_ioctl+0xa3/0x5d0
[ 83.030290] [<ffffffff811f7362>] ? vfs_write+0x142/0x190
[ 83.030292] [<ffffffff8120a189>] SyS_ioctl+0x79/0x90
[ 83.030294] [<ffffffff815c71b2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
[ 83.030296] ---[ end trace 8247b235a66a1a21 ]---
--
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.
^ permalink raw reply
* Re: building brcmfmac driver for iMX6 Ultralite platform
From: Arend Van Spriel @ 2016-07-12 21:32 UTC (permalink / raw)
To: Rafał Miłecki, Michael Eskowitz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CACna6rzU91CRGmgPtAgEhdqwpSGSs0i-C3qL7OiB8soHk8vq8Q@mail.gmail.com>
On 12-7-2016 23:10, Rafał Miłecki wrote:
> On 12 July 2016 at 21:17, Michael Eskowitz <MichaelE@inventeksys.com> wrote:
>> Arend,
>
> What about my reply? ;)
>
>
>> That is news to me. I was under the impression that bcmdhd was Broadcom's
>> proprietary (closed source) Linux driver and brcmfmac was the open source
>> Linux driver.
>
> Don't top post. It's hard to say what you're replying to. bcmdhd is
> also open source (not sure what license), just not mainline.
>
>
>> Either way, I am now running
>>
>> insmod brcmutil.ko
>> insmod brcmfmac.ko
>>
>> I receive no errors and no kernel messages.
>>
>> When I insert the 43341 module into the SDIO slot nothing happens. I'm
>> guessing that the version of the brcmfmac driver that I built does not
>> support that chip.
>
> Is is detected by the system? If so, what ID does it use?
>
>
>> When I insert the 43362 module into the SDIO slot I receive the following
>> errors
>>
>> mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>> mmc0: new high speed SDIO card at address 0001
>> brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun 7 2012
>> 18:27:16 version 5.90.225 FWID 01-d8fe14bd
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
>> brcmfmac: brcmf_add_if: ignore IF event
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_construct_reginfo: channel 1: f=2412 bw=0
>> sb=-1998840228
>> brcmfmac: brcmf_construct_reginfo: channel 2: f=2417 bw=0
>> sb=-1998840228
>>
>> and suddenly ifconfig shows the interface wlan0. The interface looks to be
>> valid as it is displaying a MAC from our address range.
>>
>> Although the interface wlan0 is present I am not able to use wl commands to
>> scan for networks. wl reports "wl driver adapter not found" for all command
>> arguments. If I run the command
>>
>> iwlist wlan0 scan
>>
>> I'm told that the interface does not support scanning. If I run wpa_cli and
>> then the commands scan and scanresults I don't see any networks.
>
> "wl" user space tool uses wlioctl, proprietary protocol, brcmfmac
> doesn't support it.
Well, not quite these days. The wl tool can be built to use nl80211
vendor commands to transport wl commands to firmware. However, my bet is
you have the "classic" wl tool using ioctl() api, which we removed from
brcmfmac years ago.
> iwlist uses wext protocol, legacy one.
iwlist is indeed using wext protocol, but cfg80211 should provide
compatibility layer so cfg80211-based drivers like brcmfmac can work
with it. However, there seem to be issues and not everything runs
smoothly. Apparently no one cares enough about wext.
> Please use nl80211 based tools, e.g. "iw".
So indeed use "iw":
$ sudo ifconfig wlan0 up
$ sudo iw wlan0 scan
Regards,
Arend
^ permalink raw reply
* Re: building brcmfmac driver for iMX6 Ultralite platform
From: Rafał Miłecki @ 2016-07-12 21:10 UTC (permalink / raw)
To: Michael Eskowitz; +Cc: Arend Van Spriel, linux-wireless@vger.kernel.org
In-Reply-To: <001201d1dc72$0675f030$1361d090$@inventeksys.com>
On 12 July 2016 at 21:17, Michael Eskowitz <MichaelE@inventeksys.com> wrote:
> Arend,
What about my reply? ;)
> That is news to me. I was under the impression that bcmdhd was Broadcom's
> proprietary (closed source) Linux driver and brcmfmac was the open source
> Linux driver.
Don't top post. It's hard to say what you're replying to. bcmdhd is
also open source (not sure what license), just not mainline.
> Either way, I am now running
>
> insmod brcmutil.ko
> insmod brcmfmac.ko
>
> I receive no errors and no kernel messages.
>
> When I insert the 43341 module into the SDIO slot nothing happens. I'm
> guessing that the version of the brcmfmac driver that I built does not
> support that chip.
Is is detected by the system? If so, what ID does it use?
> When I insert the 43362 module into the SDIO slot I receive the following
> errors
>
> mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> mmc0: new high speed SDIO card at address 0001
> brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun 7 2012
> 18:27:16 version 5.90.225 FWID 01-d8fe14bd
> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
> brcmfmac: brcmf_add_if: ignore IF event
> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> brcmfmac: brcmf_construct_reginfo: channel 1: f=2412 bw=0
> sb=-1998840228
> brcmfmac: brcmf_construct_reginfo: channel 2: f=2417 bw=0
> sb=-1998840228
>
> and suddenly ifconfig shows the interface wlan0. The interface looks to be
> valid as it is displaying a MAC from our address range.
>
> Although the interface wlan0 is present I am not able to use wl commands to
> scan for networks. wl reports "wl driver adapter not found" for all command
> arguments. If I run the command
>
> iwlist wlan0 scan
>
> I'm told that the interface does not support scanning. If I run wpa_cli and
> then the commands scan and scanresults I don't see any networks.
"wl" user space tool uses wlioctl, proprietary protocol, brcmfmac
doesn't support it.
iwlist uses wext protocol, legacy one.
Please use nl80211 based tools, e.g. "iw".
^ permalink raw reply
* RE: building brcmfmac driver for iMX6 Ultralite platform
From: Michael Eskowitz @ 2016-07-12 19:17 UTC (permalink / raw)
To: 'Arend Van Spriel', linux-wireless
In-Reply-To: <6d12bb3e-a01d-34c7-c1a9-b1952a84f99e@broadcom.com>
Arend,
That is news to me. I was under the impression that bcmdhd was Broadcom's
proprietary (closed source) Linux driver and brcmfmac was the open source
Linux driver.
Either way, I am now running
insmod brcmutil.ko
insmod brcmfmac.ko
I receive no errors and no kernel messages.
When I insert the 43341 module into the SDIO slot nothing happens. I'm
guessing that the version of the brcmfmac driver that I built does not
support that chip.
When I insert the 43362 module into the SDIO slot I receive the following
errors
mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
mmc0: new high speed SDIO card at address 0001
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun 7 2012
18:27:16 version 5.90.225 FWID 01-d8fe14bd
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
brcmfmac: brcmf_add_if: ignore IF event
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_construct_reginfo: channel 1: f=2412 bw=0
sb=-1998840228
brcmfmac: brcmf_construct_reginfo: channel 2: f=2417 bw=0
sb=-1998840228
and suddenly ifconfig shows the interface wlan0. The interface looks to be
valid as it is displaying a MAC from our address range.
Although the interface wlan0 is present I am not able to use wl commands to
scan for networks. wl reports "wl driver adapter not found" for all command
arguments. If I run the command
iwlist wlan0 scan
I'm told that the interface does not support scanning. If I run wpa_cli and
then the commands scan and scanresults I don't see any networks.
I'm thinking that the interface has not come up successfully. Are any of
the error messages above meaningful to you?
Thanks,
-Mike
-----Original Message-----
From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
Sent: Friday, July 1, 2016 3:49 AM
To: Michael Eskowitz <MichaelE@inventeksys.com>;
linux-wireless@vger.kernel.org
Subject: Re: building brcmfmac driver for iMX6 Ultralite platform
On 30-6-2016 21:24, Michael Eskowitz wrote:
> I am trying to bring up the brcmfmac driver on an iMX6 Ultralite
> board. I have both a 43341 and 43362 Wi-Fi SDIO module up and running
> on this platform already using the standard bcmdhd. I am told by some
> Broadcom folks that the brcmfmac driver should support concurrent
> connections which is something the bcmdhd does not do and that is my
> primary motivation for getting the fmac driver up and running.
bcmdhd is the standard *android* driver as provided in AOSP. So do you
intend to productize your platform with android. The brcmfmac is our
upstream driver so it will not have android specific functionality.
> The brcmfmac driver is included in NXP's kernel git and I have
> successfully built it and have it on the Ultralite platform running
> kernel 3.14.38. When I attempt to insert the module using the command
>
> insmod brcmfmac.ko
> firmware_path=ISM4334X_Wifi_FW_6.10.190.49_P.bin
> nvram_path=ISM4334X_NVRAM_C1.txt
>
> I receive the following errors:
>
> brcmfmac: Unknown symbol brcmu_pktq_mlen (err 0)
> brcmfmac: Unknown symbol brcmu_pkt_buf_free_skb (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_init (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_penq_head (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_pdeq (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_peek_tail (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_flush (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_pdeq_match (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_mdeq (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_penq (err 0)
> brcmfmac: Unknown symbol brcmu_pktq_pdeq_tail (err 0)
> brcmfmac: Unknown symbol brcmu_pkt_buf_get_skb (err 0)
> brcmfmac: Unknown symbol brcmu_d11_attach (err 0)
> insmod: ERROR: could not insert module brcmfmac.ko: Unknown symbol
in
> module
>
> I'm not sure that the firmware_path and nvram_path should be specified
> in this manner, but I doubt that is what is causing these errors.
The brcmfmac driver does not have module parameters firmware_path and
nvram_path. The filenaming is determined by the driver and it must be in a
location that firmware api provider looks for:
drivers/base/firmware_class.c:277:
/* direct firmware loading support */
static char fw_path_para[256];
static const char * const fw_path[] = {
fw_path_para,
"/lib/firmware/updates/" UTS_RELEASE,
"/lib/firmware/updates",
"/lib/firmware/" UTS_RELEASE,
"/lib/firmware"
};
/*
* Typical usage is that passing 'firmware_class.path=$CUSTOMIZED_PATH'
* from kernel command line because firmware_class is generally built in
* kernel instead of module.
*/
module_param_string(path, fw_path_para, sizeof(fw_path_para), 0644);
MODULE_PARM_DESC(path, "customized firmware image search path with a higher
priority than default path");
However, this is indeed not the reason for the errors. The brcmfmac needs
functions exported by brcmutil.ko which should be created in the build you
executed.
Regards,
Arend
> The module compiled and built just fine so I am assuming that there
> are some dependencies that aren't being met. Is there another module
> that I need to load before attempting to load the fmac driver?
>
> Thanks,
> -Mike
^ permalink raw reply
* Re: [PATCH FIX 4.6+] bcma: add PCI ID for Foxconn's BCM43142 device
From: Igor Mammedov @ 2016-07-12 18:48 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Stable,
open list:BROADCOM SPECIFIC AMBA DRIVER (BCMA), open list
In-Reply-To: <1468270896-2988-1-git-send-email-zajec5@gmail.com>
On Mon, 11 Jul 2016 23:01:36 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> After discovering there are 2 very different 14e4:4365 PCI devices we
> made ID tables less generic. Back then we believed there are only 2
> such devices:
> 1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset
> 2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset
>
> From the recent report it appears there is also 14e4:4365 105b:e092
> which should be claimed by bcma. Add back support for it.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=121881
> Fixes: 515b399c9a20 ("bcma: claim only 14e4:4365 PCI Dell card with
> SoftMAC BCM43142") Reported-by: Igor Mammedov <imammedo@redhat.com>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> Cc: Stable <stable@vger.kernel.org> [4.6+]
Tested-by: Igor Mammedov <imammedo@redhat.com>
> ---
> drivers/bcma/host_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
> index cae5385..bd46569 100644
> --- a/drivers/bcma/host_pci.c
> +++ b/drivers/bcma/host_pci.c
> @@ -295,6 +295,7 @@ static const struct pci_device_id
> bcma_pci_bridge_tbl[] = { { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM,
> 0x4359) }, { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4360) },
> { PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365,
> PCI_VENDOR_ID_DELL, 0x0016) },
> + { PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365,
> PCI_VENDOR_ID_FOXCONN, 0xe092) },
> { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a0) },
> { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a9) },
> { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43aa) },
^ permalink raw reply
* [PATCH -next] rtl8xxxu: gen1: Fix non static symbol warning
From: weiyj_lk @ 2016-07-12 14:33 UTC (permalink / raw)
To: Jes Sorensen, Kalle Valo; +Cc: Wei Yongjun, linux-wireless
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fixes the following sparse warning:
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1: warning:
symbol 'rtl8xxxu_gen1_h2c_cmd' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 77048db..95b54b8 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -894,7 +894,7 @@ int rtl8xxxu_write_rfreg(struct rtl8xxxu_priv *priv,
return retval;
}
-int
+static int
rtl8xxxu_gen1_h2c_cmd(struct rtl8xxxu_priv *priv, struct h2c_cmd *h2c, int len)
{
struct device *dev = &priv->udev->dev;
^ permalink raw reply related
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Dave Taht @ 2016-07-12 14:02 UTC (permalink / raw)
To: Felix Fietkau
Cc: make-wifi-fast, linux-wireless, Michal Kazior,
Toke Høiland-Jørgensen
In-Reply-To: <097af8e4-5393-8e1b-1748-36233e605867@nbd.name>
On Tue, Jul 12, 2016 at 3:21 PM, Felix Fietkau <nbd@nbd.name> wrote:
> On 2016-07-12 14:13, Dave Taht wrote:
>> On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau <nbd@nbd.name> wrote:
>>> Hi,
>>>
>>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>>> regression when running local iperf on an AP (running the txq stuff) to
>>> a wireless client.
>>
>> Your kernel? cpu architecture?
> QCA9558, 720 MHz, running Linux 4.4.14
>
>> What happens when going through the AP to a server from the wireless client?
> Will test that next.
>
>> Which direction?
> AP->STA, iperf running on the AP. Client is a regular MacBook Pro
> (Broadcom).
There are always 2 wifi chips in play. Like the Sith.
>>> Here's some things that I found:
>>> - when I use only one TCP stream I get around 90-110 Mbit/s
>>
>> with how much cpu left over?
> ~20%
>
>>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>> with how much cpu left over?
> ~30%
Hmm.
Care to try netperf?
>
>> context switch difference between the two tests?
> What's the easiest way to track that?
if you have gnu "time" time -v the_process
or:
perf record -e context-switches -ag
or: process /proc/$PID/status for cntx
>> tcp_limit_output_bytes is?
> 262144
I keep hoping to be able to reduce this to something saner like 4096
one day. It got bumped to 64k based on bad wifi performance once, and
then to it's current size to make the Xen folk happier.
The other param I'd like to see fiddled with is tcp_notsent_lowat.
In both cases reductions will increase your context switches but
reduce memory pressure and lead to a more reactive tcp.
And in neither case I think this is the real cause of this problem.
>> got perf?
> Need to make a new build for that.
>
>>> - fairness between TCP streams looks completely fine
>>
>> A codel will get to long term fairness pretty fast. Packet captures
>> from a fq will show much more regular interleaving of packets,
>> regardless.
>>
>>> - there's no big queue buildup, the code never actually drops any packets
>>
>> A "trick" I have been using to observe codel behavior has been to
>> enable ecn on server and client, then checking in wireshark for ect(3)
>> marked packets.
> I verified this with printk. The same issue already appears if I have
> just the fq patch (with the codel patch reverted).
OK. A four flow test "should" trigger codel....
Running out of cpu (or hitting some other bottleneck), without
loss/marking "should" result in a tcptrace -G and xplot.org of the
packet capture showing the window continuing to increase....
>>> - if I put a hack in the fq code to force the hash to a constant value
>>
>> You could also set "flows" to 1 to keep the hash being generated, but
>> not actually use it.
>>
>>> (effectively disabling fq without disabling codel), the problem
>>> disappears and even multiple streams get proper performance.
>>
>> Meaning you get 90-110Mbits ?
> Right.
>
>> Do you have a "before toke" figure for this platform?
> It's quite similar.
>
>>> Please let me know if you have any ideas.
>>
>> I am in berlin, packing hardware...
> Nice!
>
> - Felix
>
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Felix Fietkau @ 2016-07-12 13:23 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <87shvfujl4.fsf@toke.dk>
On 2016-07-12 14:28, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> Hi,
>>
>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>> regression when running local iperf on an AP (running the txq stuff) to
>> a wireless client.
>>
>> Here's some things that I found:
>> - when I use only one TCP stream I get around 90-110 Mbit/s
>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>> - fairness between TCP streams looks completely fine
>> - there's no big queue buildup, the code never actually drops any packets
>> - if I put a hack in the fq code to force the hash to a constant value
>> (effectively disabling fq without disabling codel), the problem
>> disappears and even multiple streams get proper performance.
>>
>> Please let me know if you have any ideas.
>
> Hmm, I see two TCP streams get about the same aggregate throughput as
> one, both when started from the AP and when started one hop away.
> However, do see TCP flows take a while to ramp up when started from the
> AP - a short test gets ~70Mbps when run from one hop away and ~50Mbps
> when run from the AP. how long are you running the tests for?
Long enough to see that it's not ramping up.
> (I seem to recall the ramp-up issue to be there pre-patch as well,
> though).
>
> As for why this would happen... There could be a bug in the dequeue code
> somewhere, but since you get better performance from sticking everything
> into one queue, my best guess would be that the client is choking on the
> interleaved packets? I.e. expending more CPU when it can't stick
> subsequent packets into the same TCP flow?
Could be. I'll see what the tests show when I push traffic through the
AP instead of from the AP.
- Felix
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Felix Fietkau @ 2016-07-12 13:22 UTC (permalink / raw)
To: Dave Taht, Toke Høiland-Jørgensen; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <CAA93jw6z53P+JCPsjYD-vaY+9vq9ZO-Ob_cXm0AE76uVcM=F9g@mail.gmail.com>
On 2016-07-12 14:44, Dave Taht wrote:
> On Tue, Jul 12, 2016 at 2:28 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>>
>>> Hi,
>>>
>>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>>> regression when running local iperf on an AP (running the txq stuff) to
>>> a wireless client.
>>>
>>> Here's some things that I found:
>>> - when I use only one TCP stream I get around 90-110 Mbit/s
>>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>>> - fairness between TCP streams looks completely fine
>>> - there's no big queue buildup, the code never actually drops any packets
>>> - if I put a hack in the fq code to force the hash to a constant value
>>> (effectively disabling fq without disabling codel), the problem
>>> disappears and even multiple streams get proper performance.
>>>
>>> Please let me know if you have any ideas.
>>
>> Hmm, I see two TCP streams get about the same aggregate throughput as
>> one, both when started from the AP and when started one hop away.
>> However, do see TCP flows take a while to ramp up when started from the
>> AP - a short test gets ~70Mbps when run from one hop away and ~50Mbps
>> when run from the AP. how long are you running the tests for?
>>
>> (I seem to recall the ramp-up issue to be there pre-patch as well,
>> though).
>
> The original ath10k code had a "swag" at hooking in an estimator from
> rate control.
> With minstrel in play that can be done better in the ath9k.
>
>> As for why this would happen... There could be a bug in the dequeue code
>> somewhere, but since you get better performance from sticking everything
>> into one queue, my best guess would be that the client is choking on the
>> interleaved packets? I.e. expending more CPU when it can't stick
>> subsequent packets into the same TCP flow?
>
> I share this concern.
>
> The quantum is? I am not opposed to a larger quantum (2 full size
> packets = 3028 in this case?).
I also agree with increasing quantum, however that did not make any
difference in my tests.
- Felix
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Felix Fietkau @ 2016-07-12 13:21 UTC (permalink / raw)
To: Dave Taht, make-wifi-fast
Cc: linux-wireless, Michal Kazior, Toke Høiland-Jørgensen
In-Reply-To: <CAA93jw6=_pemSUjk3dje1GmnTzrs+=pEdza4j1Wjtrw+VKNdNg@mail.gmail.com>
On 2016-07-12 14:13, Dave Taht wrote:
> On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau <nbd@nbd.name> wrote:
>> Hi,
>>
>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>> regression when running local iperf on an AP (running the txq stuff) to
>> a wireless client.
>
> Your kernel? cpu architecture?
QCA9558, 720 MHz, running Linux 4.4.14
> What happens when going through the AP to a server from the wireless client?
Will test that next.
> Which direction?
AP->STA, iperf running on the AP. Client is a regular MacBook Pro
(Broadcom).
>> Here's some things that I found:
>> - when I use only one TCP stream I get around 90-110 Mbit/s
>
> with how much cpu left over?
~20%
>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
> with how much cpu left over?
~30%
> context switch difference between the two tests?
What's the easiest way to track that?
> tcp_limit_output_bytes is?
262144
> got perf?
Need to make a new build for that.
>> - fairness between TCP streams looks completely fine
>
> A codel will get to long term fairness pretty fast. Packet captures
> from a fq will show much more regular interleaving of packets,
> regardless.
>
>> - there's no big queue buildup, the code never actually drops any packets
>
> A "trick" I have been using to observe codel behavior has been to
> enable ecn on server and client, then checking in wireshark for ect(3)
> marked packets.
I verified this with printk. The same issue already appears if I have
just the fq patch (with the codel patch reverted).
>> - if I put a hack in the fq code to force the hash to a constant value
>
> You could also set "flows" to 1 to keep the hash being generated, but
> not actually use it.
>
>> (effectively disabling fq without disabling codel), the problem
>> disappears and even multiple streams get proper performance.
>
> Meaning you get 90-110Mbits ?
Right.
> Do you have a "before toke" figure for this platform?
It's quite similar.
>> Please let me know if you have any ideas.
>
> I am in berlin, packing hardware...
Nice!
- Felix
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Dave Taht @ 2016-07-12 13:03 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Felix Fietkau, linux-wireless, Michal Kazior, make-wifi-fast
In-Reply-To: <87bn23ui87.fsf@toke.dk>
On Tue, Jul 12, 2016 at 2:57 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>>> As for why this would happen... There could be a bug in the dequeue code
>>> somewhere, but since you get better performance from sticking everything
>>> into one queue, my best guess would be that the client is choking on the
>>> interleaved packets? I.e. expending more CPU when it can't stick
>>> subsequent packets into the same TCP flow?
>>
>> I share this concern.
>>
>> The quantum is? I am not opposed to a larger quantum (2 full size
>> packets = 3028 in this case?).
>
> The quantum is hard-coded to 300 bytes in the current implementation
> (see net/fq_impl.h).
don't do that. :)
A single full size packet is preferable, and saves going around the
main dequeue loop 5-6 times per flow on this workload.
My tests on the prior patch set were mostly at the larger quantum.
> -Toke
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Toke Høiland-Jørgensen @ 2016-07-12 12:57 UTC (permalink / raw)
To: Dave Taht; +Cc: Felix Fietkau, linux-wireless, Michal Kazior
In-Reply-To: <CAA93jw6z53P+JCPsjYD-vaY+9vq9ZO-Ob_cXm0AE76uVcM=F9g@mail.gmail.com>
Dave Taht <dave.taht@gmail.com> writes:
>> As for why this would happen... There could be a bug in the dequeue code
>> somewhere, but since you get better performance from sticking everything
>> into one queue, my best guess would be that the client is choking on the
>> interleaved packets? I.e. expending more CPU when it can't stick
>> subsequent packets into the same TCP flow?
>
> I share this concern.
>
> The quantum is? I am not opposed to a larger quantum (2 full size
> packets = 3028 in this case?).
The quantum is hard-coded to 300 bytes in the current implementation
(see net/fq_impl.h).
-Toke
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Dave Taht @ 2016-07-12 12:44 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Felix Fietkau, linux-wireless, Michal Kazior
In-Reply-To: <87shvfujl4.fsf@toke.dk>
On Tue, Jul 12, 2016 at 2:28 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> Hi,
>>
>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>> regression when running local iperf on an AP (running the txq stuff) to
>> a wireless client.
>>
>> Here's some things that I found:
>> - when I use only one TCP stream I get around 90-110 Mbit/s
>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>> - fairness between TCP streams looks completely fine
>> - there's no big queue buildup, the code never actually drops any packets
>> - if I put a hack in the fq code to force the hash to a constant value
>> (effectively disabling fq without disabling codel), the problem
>> disappears and even multiple streams get proper performance.
>>
>> Please let me know if you have any ideas.
>
> Hmm, I see two TCP streams get about the same aggregate throughput as
> one, both when started from the AP and when started one hop away.
> However, do see TCP flows take a while to ramp up when started from the
> AP - a short test gets ~70Mbps when run from one hop away and ~50Mbps
> when run from the AP. how long are you running the tests for?
>
> (I seem to recall the ramp-up issue to be there pre-patch as well,
> though).
The original ath10k code had a "swag" at hooking in an estimator from
rate control.
With minstrel in play that can be done better in the ath9k.
> As for why this would happen... There could be a bug in the dequeue code
> somewhere, but since you get better performance from sticking everything
> into one queue, my best guess would be that the client is choking on the
> interleaved packets? I.e. expending more CPU when it can't stick
> subsequent packets into the same TCP flow?
I share this concern.
The quantum is? I am not opposed to a larger quantum (2 full size
packets = 3028 in this case?).
> -Toke
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Toke Høiland-Jørgensen @ 2016-07-12 12:28 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <11fa6d16-21e2-2169-8d18-940f6dc11dca@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> Hi,
>
> With Toke's ath9k txq patch I've noticed a pretty nasty performance
> regression when running local iperf on an AP (running the txq stuff) to
> a wireless client.
>
> Here's some things that I found:
> - when I use only one TCP stream I get around 90-110 Mbit/s
> - when running multiple TCP streams, I get only 35-40 Mbit/s total
> - fairness between TCP streams looks completely fine
> - there's no big queue buildup, the code never actually drops any packets
> - if I put a hack in the fq code to force the hash to a constant value
> (effectively disabling fq without disabling codel), the problem
> disappears and even multiple streams get proper performance.
>
> Please let me know if you have any ideas.
Hmm, I see two TCP streams get about the same aggregate throughput as
one, both when started from the AP and when started one hop away.
However, do see TCP flows take a while to ramp up when started from the
AP - a short test gets ~70Mbps when run from one hop away and ~50Mbps
when run from the AP. how long are you running the tests for?
(I seem to recall the ramp-up issue to be there pre-patch as well,
though).
As for why this would happen... There could be a bug in the dequeue code
somewhere, but since you get better performance from sticking everything
into one queue, my best guess would be that the client is choking on the
interleaved packets? I.e. expending more CPU when it can't stick
subsequent packets into the same TCP flow?
-Toke
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Dave Taht @ 2016-07-12 12:13 UTC (permalink / raw)
To: Felix Fietkau, make-wifi-fast
Cc: linux-wireless, Michal Kazior, Toke Høiland-Jørgensen
In-Reply-To: <11fa6d16-21e2-2169-8d18-940f6dc11dca@nbd.name>
On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau <nbd@nbd.name> wrote:
> Hi,
>
> With Toke's ath9k txq patch I've noticed a pretty nasty performance
> regression when running local iperf on an AP (running the txq stuff) to
> a wireless client.
Your kernel? cpu architecture?
What happens when going through the AP to a server from the wireless client?
Which direction?
> Here's some things that I found:
> - when I use only one TCP stream I get around 90-110 Mbit/s
with how much cpu left over?
> - when running multiple TCP streams, I get only 35-40 Mbit/s total
with how much cpu left over?
context switch difference between the two tests?
tcp_limit_output_bytes is?
got perf?
> - fairness between TCP streams looks completely fine
A codel will get to long term fairness pretty fast. Packet captures
from a fq will show much more regular interleaving of packets,
regardless.
> - there's no big queue buildup, the code never actually drops any packets
A "trick" I have been using to observe codel behavior has been to
enable ecn on server and client, then checking in wireshark for ect(3)
marked packets.
> - if I put a hack in the fq code to force the hash to a constant value
You could also set "flows" to 1 to keep the hash being generated, but
not actually use it.
> (effectively disabling fq without disabling codel), the problem
> disappears and even multiple streams get proper performance.
Meaning you get 90-110Mbits ?
Do you have a "before toke" figure for this platform?
> Please let me know if you have any ideas.
I am in berlin, packing hardware...
>
> - Felix
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: iwlwifi: add missing type declaration
From: Kalle Valo @ 2016-07-12 11:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Johannes Berg, Arnd Bergmann, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Eliad Peller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20160711205020.1587254-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The iwl-debug.h header relies in implicit inclusion of linux/device.h and
> we get a lot of warnings without that:
>
> drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:23: error: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
> void __iwl_err(struct device *dev, bool rfkill_prefix, bool only_trace,
> ^~~~~~
> In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.h:66:0,
> from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:68:
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h: In function 'iwl_trans_tx':
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1030:348: error: passing argument 1 of '__iwl_err' from incompatible pointer type [-Werror=incompatible-pointer-types]
> IWL_ERR(trans, "%s bad state = %d\n", __func__, trans->state);
> ^
> In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:67:0:
> drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:6: note: expected 'struct device *' but argument is of type 'struct device *'
> void __iwl_err(struct device *dev, bool rfkill_prefix, bool only_trace,
> ^~~~~~~~~
>
> The easiest workaround is to just declare 'struct device' before its first use,
> rather than including the entire header file.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 21cb3222fe56 ("iwlwifi: decouple PCIe transport from mac80211")
> Acked-by: Luca Coelho <luciano.coelho@intel.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
25f700ef0653 iwlwifi: add missing type declaration
--
Sent by pwcli
https://patchwork.kernel.org/patch/9224105/
^ permalink raw reply
* Re: [PATCH -next] iwlwifi: mvm: use setup_timer instead of init_timer and data fields
From: Grumbach, Emmanuel @ 2016-07-12 11:43 UTC (permalink / raw)
To: Coelho, Luciano, linuxwifi, kvalo@codeaurora.org, Sharon, Sara,
weiyj_lk@163.com, Berg, Johannes
Cc: linux-wireless@vger.kernel.org, yongjun_wei@trendmicro.com.cn
In-Reply-To: <1468323657-5909-1-git-send-email-weiyj_lk@163.com>
T24gVHVlLCAyMDE2LTA3LTEyIGF0IDExOjQwICswMDAwLCB3ZWl5al9sa0AxNjMuY29tIHdyb3Rl
Og0KPiBGcm9tOiBXZWkgWW9uZ2p1biA8eW9uZ2p1bl93ZWlAdHJlbmRtaWNyby5jb20uY24+DQo+
IA0KPiBVc2Ugc2V0dXBfdGltZXIgZnVuY3Rpb24gaW5zdGVhZCBvZiBpbml0aWFsaXppbmcgdGlt
ZXIgd2l0aCB0aGUNCj4gZnVuY3Rpb24NCj4gYW5kIGRhdGEgZmllbGRzDQo+IA0KPiBTaWduZWQt
b2ZmLWJ5OiBXZWkgWW9uZ2p1biA8eW9uZ2p1bl93ZWlAdHJlbmRtaWNyby5jb20uY24+DQo+IC0t
LQ0KDQpUaGFua3MgLSBJIHBpY2tlZCBpdCB1cCBhbmQgdXBsb2FkZWQgaXQgdG8gb3VyIGludGVy
bmFsIHRyZWUuDQo=
^ permalink raw reply
* [PATCH -next] mwifiex: fix possible memory leak in mwifiex_cfg80211_start_ap()
From: weiyj_lk @ 2016-07-12 11:43 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo
Cc: Wei Yongjun, linux-wireless
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
memory is malloced in mwifiex_cfg80211_start_ap() and should be
freed before leaving from the error handling cases, otherwise it
will cause memory leak.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index df5ebdf..1eec77e 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -1936,10 +1936,9 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
mwifiex_set_uap_rates(bss_cfg, params);
if (mwifiex_set_secure_params(priv, bss_cfg, params)) {
- kfree(bss_cfg);
mwifiex_dbg(priv->adapter, ERROR,
"Failed to parse secuirty parameters!\n");
- return -1;
+ goto out;
}
mwifiex_set_ht_params(priv, bss_cfg, params);
@@ -1968,7 +1967,7 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
if (mwifiex_11h_activate(priv, false)) {
mwifiex_dbg(priv->adapter, ERROR,
"Failed to disable 11h extensions!!");
- return -1;
+ goto out;
}
priv->state_11h.is_11h_active = false;
}
@@ -1976,12 +1975,11 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
if (mwifiex_config_start_uap(priv, bss_cfg)) {
mwifiex_dbg(priv->adapter, ERROR,
"Failed to start AP\n");
- kfree(bss_cfg);
- return -1;
+ goto out;
}
if (mwifiex_set_mgmt_ies(priv, ¶ms->beacon))
- return -1;
+ goto out;
if (!netif_carrier_ok(priv->netdev))
netif_carrier_on(priv->netdev);
@@ -1990,6 +1988,10 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
memcpy(&priv->bss_cfg, bss_cfg, sizeof(priv->bss_cfg));
kfree(bss_cfg);
return 0;
+
+out:
+ kfree(bss_cfg);
+ return -1;
}
/*
^ permalink raw reply related
* [PATCH -next] iwlwifi: mvm: use setup_timer instead of init_timer and data fields
From: weiyj_lk @ 2016-07-12 11:40 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, Sara Sharon
Cc: Wei Yongjun, linux-wireless
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use setup_timer function instead of initializing timer with the function
and data fields
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index f449ef9..7caad55 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -1351,11 +1351,9 @@ int iwl_mvm_sta_rx_agg(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
baid_data->baid = baid;
baid_data->timeout = timeout;
baid_data->last_rx = jiffies;
- init_timer(&baid_data->session_timer);
- baid_data->session_timer.function =
- iwl_mvm_rx_agg_session_expired;
- baid_data->session_timer.data =
- (unsigned long)&mvm->baid_map[baid];
+ setup_timer(&baid_data->session_timer,
+ iwl_mvm_rx_agg_session_expired,
+ (unsigned long)&mvm->baid_map[baid]);
baid_data->mvm = mvm;
baid_data->tid = tid;
baid_data->sta_id = mvm_sta->sta_id;
^ permalink raw reply related
* [PATCH -next] libertas: fix non static symbol warning
From: weiyj_lk @ 2016-07-12 11:32 UTC (permalink / raw)
To: Kalle Valo, sudip, Andreas Kemnade
Cc: Wei Yongjun, libertas-dev, linux-wireless
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fixes the following sparse warning:
drivers/net/wireless/marvell/libertas/cfg.c:2047:5: warning:
symbol 'lbs_set_power_mgmt' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/marvell/libertas/cfg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index ea48024..7ff2efa 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -2044,8 +2044,8 @@ static int lbs_leave_ibss(struct wiphy *wiphy, struct net_device *dev)
-int lbs_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
- bool enabled, int timeout)
+static int lbs_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
+ bool enabled, int timeout)
{
struct lbs_private *priv = wiphy_priv(wiphy);
^ permalink raw reply related
* Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets
From: Per Förlin @ 2016-07-12 10:23 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, arend
In-Reply-To: <38869535-4f77-f6d8-d8d0-cb01b3f9c65b@broadcom.com>
2016-07-12 11:48 GMT+02:00 Arend Van Spriel <arend.vanspriel@broadcom.com>:
>
>
> On 12-7-2016 10:35, Per Förlin wrote:
>> 2016-07-06 11:53 GMT+02:00 Per Förlin <per.forlin@gmail.com>:
>>> I have now verified this patch on backports 4.4.
>>>
>>> 2016-04-12 23:55 GMT+02:00 <per.forlin@gmail.com>:
>>>> From: Per Forlin <per.forlin@gmail.com>
>>>>
>>>> This patch resolves an issue where pend_8021x_cnt was not decreased
>>>> on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
>>>> because the counter indicated pending packets.
>>>>
>>>> WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
>>>> (warn_slowpath_common)
>>>> (warn_slowpath_null)
>>>> (brcmf_netdev_wait_pend8021x [brcmfmac])
>>>> (send_key_to_dongle [brcmfmac])
>>>> (brcmf_cfg80211_del_key [brcmfmac])
>>>> (nl80211_del_key [cfg80211])
>>>> (genl_rcv_msg)
>>>> (netlink_rcv_skb)
>>>> (genl_rcv)
>>>> (netlink_unicast)
>>>> (netlink_sendmsg)
>>>> (sock_sendmsg)
>>>> (___sys_sendmsg)
>>>> (__sys_sendmsg)
>>>> (SyS_sendmsg)
>>>>
>>>> The solution is to pull back the header offset in case
>>>> of an error in txdata(), which may happen in case of
>> Clarification:
>>
>> txdata=brcmf_proto_bcdc_txdata()
>> brcmf_proto_bcdc_txdata(): Calls brcmf_proto_bcdc_hdrpush()
>>
>> The header needs to be pulled back in case of error otherwise
>> the error handling and cleanup up will fail to decrease the counter
>> of pending packets.
>
> Yes, this part of the patch is clear to me.
>
Thanks, I wasn't sure.
>>>> packet overload in brcmf_sdio_bus_txdata.
>>>>
>>>> Overloading an WLAN interface is not an unlikely scenario.
>
> So here is where things start to look suspicious and I have mentioned
> this before. My thought here was "How the hell can you end up with a
> 2048 packets on the sdio queue", which I mentioned to you before. There
> is a high watermark on the queue upon which we do a netif_stop_queue()
> so network layer does not keep pushing tx packets our way. Looking
> further into this I found that we introduced a bug with commit
> 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.") so we ended
> up doing nothing except increasing as statistics debug counter :-(
>
Is there a fix available for the high watermark issue or is it
something you will look into?
To produce a load on the wlan interface I run
iperf -c 239.255.1.3 -u -b 10m -f m -i 60 -t 3000
and this is enough in my case to fill up the 2048 queue.
>>>> In case of packet overload the error print "out of bus->txq"
>>>> is very verbose. To reduce SPAM degrade it to a debug print.
>>>>
>>>> Signed-off-by: Per Forlin <per.forlin@gmail.com>
>>>> ---
>>>> Change log:
>>>> v2 - Add variable to know whether the counter is increased or not
>>>> v3 - txfinalize should decrease the counter. Adjust skb header offset
>>>> v4 - Fix build error
>>>>
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++++
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>>>> 3 files changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>> index ed9998b..f342f7c 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>> @@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>>> struct ethhdr *eh;
>>>> u16 type;
>>>>
>>>> + if (!ifp)
>>>> + goto free;
>>>> +
>
> This may not be needed.
>
This is not strictly needed. I can remove it.
>>>> eh = (struct ethhdr *)(txp->data);
>>>> type = ntohs(eh->h_proto);
>>>>
>>>> @@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>>> if (!success)
>>>> ifp->stats.tx_errors++;
>>>>
>>>> +free:
>>>> brcmu_pkt_buf_free_skb(txp);
>>>> }
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>> index f82c9ab..98cb83f 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>> @@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
>>>>
>>>> if (fws->avoid_queueing) {
>>>> rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
>>>> - if (rc < 0)
>>>> + if (rc < 0) {
>>>> + (void)brcmf_proto_hdrpull(drvr, false, skb, &ifp);
>
> Could it be that the ifp is NULL pointer after brcmf_proto_hdrpull().
> Can you check. Better use tmp_ifp variable in this call as you have a
> valid ifp before this call for sure.
>
To be on the safe side I can use NULL as in param like you propose,
and use the available ifp.
>>>> brcmf_txfinalize(ifp, skb, false);
>>>> + }
>>>> return rc;
>>>> }
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>> index a14d9d9d..485e2ad 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>> @@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, struct sk_buff *pkt)
>>>> *(u16 *)(pkt->cb) = 0;
>>>> if (!brcmf_sdio_prec_enq(&bus->txq, pkt, prec)) {
>>>> skb_pull(pkt, bus->tx_hdrlen);
>>>> - brcmf_err("out of bus->txq !!!\n");
>>>> + brcmf_dbg(INFO, "out of bus->txq !!!\n");
>
> Now that I understand the issue I want to keep this as error print as it
> should be very unlikely.
I would like to test this patch with the watermark fix to confirm this.
>
> Regards,
> Arend
Thanks for the review!
>
>>>> ret = -ENOSR;
>>>> } else {
>>>> ret = 0;
>>>> --
>>>> 2.1.4
>>>>
^ permalink raw reply
* TCP performance regression in mac80211 triggered by the fq code
From: Felix Fietkau @ 2016-07-12 10:09 UTC (permalink / raw)
To: linux-wireless; +Cc: Michal Kazior, Toke Høiland-Jørgensen
Hi,
With Toke's ath9k txq patch I've noticed a pretty nasty performance
regression when running local iperf on an AP (running the txq stuff) to
a wireless client.
Here's some things that I found:
- when I use only one TCP stream I get around 90-110 Mbit/s
- when running multiple TCP streams, I get only 35-40 Mbit/s total
- fairness between TCP streams looks completely fine
- there's no big queue buildup, the code never actually drops any packets
- if I put a hack in the fq code to force the hash to a constant value
(effectively disabling fq without disabling codel), the problem
disappears and even multiple streams get proper performance.
Please let me know if you have any ideas.
- Felix
^ permalink raw reply
* Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets
From: Arend Van Spriel @ 2016-07-12 9:48 UTC (permalink / raw)
To: Per Förlin, linux-wireless; +Cc: arend
In-Reply-To: <CAC0pXTJ-hnKgSMwf7KYPwBs7RB2YAgaouOdeJwD2kuLneCGXfA@mail.gmail.com>
On 12-7-2016 10:35, Per Förlin wrote:
> 2016-07-06 11:53 GMT+02:00 Per Förlin <per.forlin@gmail.com>:
>> I have now verified this patch on backports 4.4.
>>
>> 2016-04-12 23:55 GMT+02:00 <per.forlin@gmail.com>:
>>> From: Per Forlin <per.forlin@gmail.com>
>>>
>>> This patch resolves an issue where pend_8021x_cnt was not decreased
>>> on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
>>> because the counter indicated pending packets.
>>>
>>> WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
>>> (warn_slowpath_common)
>>> (warn_slowpath_null)
>>> (brcmf_netdev_wait_pend8021x [brcmfmac])
>>> (send_key_to_dongle [brcmfmac])
>>> (brcmf_cfg80211_del_key [brcmfmac])
>>> (nl80211_del_key [cfg80211])
>>> (genl_rcv_msg)
>>> (netlink_rcv_skb)
>>> (genl_rcv)
>>> (netlink_unicast)
>>> (netlink_sendmsg)
>>> (sock_sendmsg)
>>> (___sys_sendmsg)
>>> (__sys_sendmsg)
>>> (SyS_sendmsg)
>>>
>>> The solution is to pull back the header offset in case
>>> of an error in txdata(), which may happen in case of
> Clarification:
>
> txdata=brcmf_proto_bcdc_txdata()
> brcmf_proto_bcdc_txdata(): Calls brcmf_proto_bcdc_hdrpush()
>
> The header needs to be pulled back in case of error otherwise
> the error handling and cleanup up will fail to decrease the counter
> of pending packets.
Yes, this part of the patch is clear to me.
>>> packet overload in brcmf_sdio_bus_txdata.
>>>
>>> Overloading an WLAN interface is not an unlikely scenario.
So here is where things start to look suspicious and I have mentioned
this before. My thought here was "How the hell can you end up with a
2048 packets on the sdio queue", which I mentioned to you before. There
is a high watermark on the queue upon which we do a netif_stop_queue()
so network layer does not keep pushing tx packets our way. Looking
further into this I found that we introduced a bug with commit
9cd18359d31e ("brcmfmac: Make FWS queueing configurable.") so we ended
up doing nothing except increasing as statistics debug counter :-(
>>> In case of packet overload the error print "out of bus->txq"
>>> is very verbose. To reduce SPAM degrade it to a debug print.
>>>
>>> Signed-off-by: Per Forlin <per.forlin@gmail.com>
>>> ---
>>> Change log:
>>> v2 - Add variable to know whether the counter is increased or not
>>> v3 - txfinalize should decrease the counter. Adjust skb header offset
>>> v4 - Fix build error
>>>
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++++
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>>> 3 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>> index ed9998b..f342f7c 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>> @@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>> struct ethhdr *eh;
>>> u16 type;
>>>
>>> + if (!ifp)
>>> + goto free;
>>> +
This may not be needed.
>>> eh = (struct ethhdr *)(txp->data);
>>> type = ntohs(eh->h_proto);
>>>
>>> @@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>> if (!success)
>>> ifp->stats.tx_errors++;
>>>
>>> +free:
>>> brcmu_pkt_buf_free_skb(txp);
>>> }
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>> index f82c9ab..98cb83f 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>> @@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
>>>
>>> if (fws->avoid_queueing) {
>>> rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
>>> - if (rc < 0)
>>> + if (rc < 0) {
>>> + (void)brcmf_proto_hdrpull(drvr, false, skb, &ifp);
Could it be that the ifp is NULL pointer after brcmf_proto_hdrpull().
Can you check. Better use tmp_ifp variable in this call as you have a
valid ifp before this call for sure.
>>> brcmf_txfinalize(ifp, skb, false);
>>> + }
>>> return rc;
>>> }
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> index a14d9d9d..485e2ad 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> @@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, struct sk_buff *pkt)
>>> *(u16 *)(pkt->cb) = 0;
>>> if (!brcmf_sdio_prec_enq(&bus->txq, pkt, prec)) {
>>> skb_pull(pkt, bus->tx_hdrlen);
>>> - brcmf_err("out of bus->txq !!!\n");
>>> + brcmf_dbg(INFO, "out of bus->txq !!!\n");
Now that I understand the issue I want to keep this as error print as it
should be very unlikely.
Regards,
Arend
>>> ret = -ENOSR;
>>> } else {
>>> ret = 0;
>>> --
>>> 2.1.4
>>>
^ permalink raw reply
* Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets
From: Per Förlin @ 2016-07-12 8:35 UTC (permalink / raw)
To: linux-wireless; +Cc: arend, Per Forlin
In-Reply-To: <CAC0pXTLDeiiVma7AGD1XirQG=SqSDht_BA3arQQnvn=ztTLDug@mail.gmail.com>
2016-07-06 11:53 GMT+02:00 Per Förlin <per.forlin@gmail.com>:
> I have now verified this patch on backports 4.4.
>
> 2016-04-12 23:55 GMT+02:00 <per.forlin@gmail.com>:
>> From: Per Forlin <per.forlin@gmail.com>
>>
>> This patch resolves an issue where pend_8021x_cnt was not decreased
>> on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
>> because the counter indicated pending packets.
>>
>> WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
>> (warn_slowpath_common)
>> (warn_slowpath_null)
>> (brcmf_netdev_wait_pend8021x [brcmfmac])
>> (send_key_to_dongle [brcmfmac])
>> (brcmf_cfg80211_del_key [brcmfmac])
>> (nl80211_del_key [cfg80211])
>> (genl_rcv_msg)
>> (netlink_rcv_skb)
>> (genl_rcv)
>> (netlink_unicast)
>> (netlink_sendmsg)
>> (sock_sendmsg)
>> (___sys_sendmsg)
>> (__sys_sendmsg)
>> (SyS_sendmsg)
>>
>> The solution is to pull back the header offset in case
>> of an error in txdata(), which may happen in case of
Clarification:
txdata=brcmf_proto_bcdc_txdata()
brcmf_proto_bcdc_txdata(): Calls brcmf_proto_bcdc_hdrpush()
The header needs to be pulled back in case of error otherwise
the error handling and cleanup up will fail to decrease the counter
of pending packets.
>> packet overload in brcmf_sdio_bus_txdata.
>>
>> Overloading an WLAN interface is not an unlikely scenario.
>> In case of packet overload the error print "out of bus->txq"
>> is very verbose. To reduce SPAM degrade it to a debug print.
>>
>> Signed-off-by: Per Forlin <per.forlin@gmail.com>
>> ---
>> Change log:
>> v2 - Add variable to know whether the counter is increased or not
>> v3 - txfinalize should decrease the counter. Adjust skb header offset
>> v4 - Fix build error
>>
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++++
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>> 3 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> index ed9998b..f342f7c 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> @@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>> struct ethhdr *eh;
>> u16 type;
>>
>> + if (!ifp)
>> + goto free;
>> +
>> eh = (struct ethhdr *)(txp->data);
>> type = ntohs(eh->h_proto);
>>
>> @@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>> if (!success)
>> ifp->stats.tx_errors++;
>>
>> +free:
>> brcmu_pkt_buf_free_skb(txp);
>> }
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>> index f82c9ab..98cb83f 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>> @@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
>>
>> if (fws->avoid_queueing) {
>> rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
>> - if (rc < 0)
>> + if (rc < 0) {
>> + (void)brcmf_proto_hdrpull(drvr, false, skb, &ifp);
>> brcmf_txfinalize(ifp, skb, false);
>> + }
>> return rc;
>> }
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> index a14d9d9d..485e2ad 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> @@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, struct sk_buff *pkt)
>> *(u16 *)(pkt->cb) = 0;
>> if (!brcmf_sdio_prec_enq(&bus->txq, pkt, prec)) {
>> skb_pull(pkt, bus->tx_hdrlen);
>> - brcmf_err("out of bus->txq !!!\n");
>> + brcmf_dbg(INFO, "out of bus->txq !!!\n");
>> ret = -ENOSR;
>> } else {
>> ret = 0;
>> --
>> 2.1.4
>>
^ permalink raw reply
* Re: [PATCH] iwlwifi: add missing type declaration
From: Luca Coelho @ 2016-07-12 8:14 UTC (permalink / raw)
To: Arnd Bergmann, Johannes Berg, kvalo
Cc: Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo, Eliad Peller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20160711205020.1587254-1-arnd@arndb.de>
On Mon, 2016-07-11 at 22:49 +0200, Arnd Bergmann wrote:
> The iwl-debug.h header relies in implicit inclusion of linux/device.h
> and
> we get a lot of warnings without that:
>
> drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:23: error: 'struct
> device' declared inside parameter list will not be visible outside of
> this definition or declaration [-Werror]
> void __iwl_err(struct device *dev, bool rfkill_prefix, bool
> only_trace,
> ^~~~~~
> In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-
> read.h:66:0,
> from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-
> read.c:68:
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h: In function
> 'iwl_trans_tx':
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1030:348: error:
> passing argument 1 of '__iwl_err' from incompatible pointer type [-
> Werror=incompatible-pointer-types]
> IWL_ERR(trans, "%s bad state = %d\n", __func__, trans->state);
>
>
>
>
>
> ^
> In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-
> read.c:67:0:
> drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:6: note: expected
> 'struct device *' but argument is of type 'struct device *'
> void __iwl_err(struct device *dev, bool rfkill_prefix, bool
> only_trace,
> ^~~~~~~~~
>
> The easiest workaround is to just declare 'struct device' before its
> first use,
> rather than including the entire header file.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 21cb3222fe56 ("iwlwifi: decouple PCIe transport from
> mac80211")
> ---
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Agree with Kalle that he will take this directly to wireless-drivers-
next.
--
Cheers,
Luca.
^ 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