* Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
From: Luca Coelho @ 2017-10-12 18:29 UTC (permalink / raw)
To: Mark Brown, Kalle Valo, Chaya Rachel Ivgi, Shahar S Matityahu,
Wireless
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171012172512.tlsdjhppfz2hu4vr@sirena.co.uk>
On Thu, 2017-10-12 at 18:25 +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
> drivers/net/wireless/intel/iwlwifi/iwl-config.h
>
> between commit:
>
> dd05f9aab4426f ("iwlwifi: pcie: dynamic Tx command queue size")
>
> from the wireless-drivers tree and commit:
>
> 44fd09dad5d2b7 ("iwlwifi: nvm: set the correct offsets to 3168
> series")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.
>
> diff --cc drivers/net/wireless/intel/iwlwifi/iwl-config.h
> index 71cb1ecde0f7,b9f3b350fe34..000000000000
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h
> @@@ -332,7 -320,9 +332,9 @@@ struct iwl_pwr_tx_backoff
> * @integrated: discrete or integrated
> * @gen2: a000 and on transport operation
> * @cdb: CDB support
> - * @ext_nvm: extended NVM format
> + * @nvm_type: see &enum iwl_nvm_type
> + * @tx_cmd_queue_size: size of the cmd queue. If zero, use the same
> value as
> + * the regular queues
> *
> * We enable the driver to be backward compatible wrt. hardware
> features.
> * API differences in uCode shouldn't be handled here but through
> TLVs
> @@@ -382,7 -371,9 +384,8 @@@ struct iwl_cfg
> use_tfh:1,
> gen2:1,
> cdb:1,
> - ext_nvm:1,
nvm_type seems to be missing from here?
> dbgc_supported:1;
> + u16 tx_cmd_queue_size;
> u8 valid_tx_ant;
> u8 valid_rx_ant;
> u8 non_shared_ant;
--
Luca.
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
From: Mark Brown @ 2017-10-12 18:35 UTC (permalink / raw)
To: Luciano Coelho
Cc: Kalle Valo, Chaya Rachel Ivgi, Shahar S Matityahu, Wireless,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <1507832866.5497.2.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
On Thu, Oct 12, 2017 at 09:27:46PM +0300, Luciano Coelho wrote:
> On Thu, 2017-10-12 at 19:21 +0100, Mark Brown wrote:
> > I may have confused the trees when I was pasting things in, the
> > commits
> > are filled in by hand.
> Ah, okay. But still, if the same patches conflicted twice, why wasn't
> there only one occurrence with both conflicts at once?
With trees like this that don't coordinate with their fixes branch there
are frequently multiple conflicts introduced so I generally report
things file by file without even looking at the new ones.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
From: Luca Coelho @ 2017-10-12 18:50 UTC (permalink / raw)
To: Mark Brown
Cc: Kalle Valo, Chaya Rachel Ivgi, Shahar S Matityahu, Wireless,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171012183505.oo77lgdbmqjevsuo@sirena.co.uk>
On Thu, 2017-10-12 at 19:35 +0100, Mark Brown wrote:
> On Thu, Oct 12, 2017 at 09:27:46PM +0300, Luciano Coelho wrote:
> > On Thu, 2017-10-12 at 19:21 +0100, Mark Brown wrote:
> > > I may have confused the trees when I was pasting things in, the
> > > commits
> > > are filled in by hand.
> >
> > Ah, okay. But still, if the same patches conflicted twice, why
> > wasn't
> > there only one occurrence with both conflicts at once?
>
> With trees like this that don't coordinate with their fixes branch
> there
> are frequently multiple conflicts introduced so I generally report
> things file by file without even looking at the new ones.
Sorry for the trouble. But how do you suggest that we "coordinate our
fixes branch"? Merge fixes into the main tree?
--
Luca.
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
From: Mark Brown @ 2017-10-12 18:59 UTC (permalink / raw)
To: Luca Coelho
Cc: Kalle Valo, Chaya Rachel Ivgi, Shahar S Matityahu, Wireless,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <1507834251.5497.7.camel@coelho.fi>
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
On Thu, Oct 12, 2017 at 09:50:51PM +0300, Luca Coelho wrote:
> On Thu, 2017-10-12 at 19:35 +0100, Mark Brown wrote:
> > With trees like this that don't coordinate with their fixes branch
> > there
> > are frequently multiple conflicts introduced so I generally report
> > things file by file without even looking at the new ones.
> Sorry for the trouble. But how do you suggest that we "coordinate our
> fixes branch"? Merge fixes into the main tree?
That'd be easiest for me! It's not of necessity a problem if the
conflicts are easy enough to resolve if you just let things get merged
in -next, it's just more an observation that that's a thing that happens
and that this is how I cope with it. Stephen may do things a bit
differently.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
From: Luca Coelho @ 2017-10-12 19:02 UTC (permalink / raw)
To: Mark Brown
Cc: Kalle Valo, Chaya Rachel Ivgi, Shahar S Matityahu, Wireless,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171012185944.bip4cdk7bd4d6mpc@sirena.co.uk>
On Thu, 2017-10-12 at 19:59 +0100, Mark Brown wrote:
> On Thu, Oct 12, 2017 at 09:50:51PM +0300, Luca Coelho wrote:
> > On Thu, 2017-10-12 at 19:35 +0100, Mark Brown wrote:
> > > With trees like this that don't coordinate with their fixes
> > > branch
> > > there
> > > are frequently multiple conflicts introduced so I generally
> > > report
> > > things file by file without even looking at the new ones.
> > Sorry for the trouble. But how do you suggest that we "coordinate
> > our
> > fixes branch"? Merge fixes into the main tree?
>
> That'd be easiest for me! It's not of necessity a problem if the
> conflicts are easy enough to resolve if you just let things get
> merged
> in -next, it's just more an observation that that's a thing that
> happens
> and that this is how I cope with it. Stephen may do things a bit
> differently.
Cool, I'll discuss this with Kalle and make sure I note these potential
conflicts early enough so everyone is aware when they're coming.
Thanks for taking over while Stephen is away! I really appreciate it,
since linux-next is a very important part of our process. :)
--
Luca.
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
From: Mark Brown @ 2017-10-12 19:12 UTC (permalink / raw)
To: Luca Coelho
Cc: Kalle Valo, Chaya Rachel Ivgi, Shahar S Matityahu, Wireless,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <1507832979.5497.4.camel@coelho.fi>
[-- Attachment #1: Type: text/plain, Size: 428 bytes --]
On Thu, Oct 12, 2017 at 09:29:39PM +0300, Luca Coelho wrote:
> On Thu, 2017-10-12 at 18:25 +0100, Mark Brown wrote:
> > @@@ -382,7 -371,9 +384,8 @@@ struct iwl_cfg
> > use_tfh:1,
> > gen2:1,
> > cdb:1,
> > - ext_nvm:1,
> nvm_type seems to be missing from here?
Oh bother. Either my error or git's... but it does seem to be
building so I'm a bit confused about what's going on there.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* iwlwifi crash with hostapd
From: Mario Theodoridis @ 2017-10-12 20:26 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 6919 bytes --]
Hello everyone,
i'm running Kubuntu 16.04 as a Virtualbox VM host, and a wireless AP
with an Intel Wireless 7260.
My WLAN connections frequently keep dying, so that i need to disconnect
and reconnect in order to use them again.
My syslog is full of these:
Oct 12 21:48:55 zippy kernel: [3546600.957321] ------------[ cut here
]------------
Oct 12 21:48:55 zippy kernel: [3546600.957352] WARNING: CPU: 2 PID: 1571
at
/build/linux-YyUNAI/linux-4.4.0/drivers/net/wireless/iwlwifi/mvm/utils.c:740
iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]()
Oct 12 21:48:55 zippy kernel: [3546600.957356] Modules linked in: btrfs
xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c md4
nls_utf8 cifs fscache bnep drbg ansi_cprng ctr ccm pci_stub vboxpci(OE)
vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bridge stp llc nf_log_ipv4
nf_log_common xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack iptable_filter ip_tables x_tables arc4
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
intel_rapl x86_pkg_temp_thermal snd_hda_intel intel_powerclamp coretemp
snd_hda_codec kvm_intel snd_hda_core snd_hwdep input_leds kvm snd_pcm
iwlmvm snd_seq_midi joydev snd_seq_midi_event irqbypass mac80211
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_rawmidi
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper iwlwifi
cryptd snd_seq cfg80211 serio_raw snd_seq_device snd_timer snd mei_me
soundcore mei shpchp hci_uart btbcm btqca btintel intel_lpss_acpi
bluetooth 8250_fintek intel_lpss acpi_als kfifo_buf industrialio
tpm_infineon mac_hid acpi_pad parport_pc ppdev lp parport autofs4
hid_generic usbhid i915_bpo intel_ips i2c_algo_bit drm_kms_helper e1000e
syscopyarea sysfillrect sysimgblt ptp fb_sys_fops psmouse pps_core e100
e1000 ahci drm mii libahci wmi pinctrl_sunrisepoint video i2c_hid
pinctrl_intel hid fjes
Oct 12 21:48:55 zippy kernel: [3546600.957507] CPU: 2 PID: 1571 Comm:
hostapd Tainted: G W OE 4.4.0-93-generic #116-Ubuntu
Oct 12 21:48:55 zippy kernel: [3546600.957511] Hardware name: Gigabyte
Technology Co., Ltd. Z170M-D3H/Z170M-D3H-CF, BIOS F20 11/17/2016
Oct 12 21:48:55 zippy kernel: [3546600.957514] 0000000000000286
f553094adee223e4 ffff880429a2b748 ffffffff813f9f83
Oct 12 21:48:55 zippy kernel: [3546600.957520] 0000000000000000
ffffffffc07335e8 ffff880429a2b780 ffffffff810812f2
Oct 12 21:48:55 zippy kernel: [3546600.957526] ffff88042605d4c8
0000000000000011 ffff88042605d550 0000000000000007
Oct 12 21:48:55 zippy kernel: [3546600.957531] Call Trace:
Oct 12 21:48:55 zippy kernel: [3546600.957541] [<ffffffff813f9f83>]
dump_stack+0x63/0x90
Oct 12 21:48:55 zippy kernel: [3546600.957550] [<ffffffff810812f2>]
warn_slowpath_common+0x82/0xc0
Oct 12 21:48:55 zippy kernel: [3546600.957555] [<ffffffff8108143a>]
warn_slowpath_null+0x1a/0x20
Oct 12 21:48:55 zippy kernel: [3546600.957572] [<ffffffffc070aa46>]
iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957587] [<ffffffffc0709bfd>] ?
iwl_mvm_send_cmd_pdu_status+0x4d/0x70 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957604] [<ffffffffc070e588>] ?
iwl_mvm_sta_tx_agg+0xc8/0x150 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957621] [<ffffffffc0710853>]
iwl_mvm_sta_tx_agg_flush+0x1b3/0x200 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957635] [<ffffffffc0701492>]
iwl_mvm_mac_ampdu_action+0xe2/0x350 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957669] [<ffffffffc061db5f>]
drv_ampdu_action+0x6f/0x180 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957702] [<ffffffffc062972d>]
___ieee80211_stop_tx_ba_session+0x13d/0x260 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957734] [<ffffffffc0629e15>]
__ieee80211_stop_tx_ba_session+0x35/0x50 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957763] [<ffffffffc062837f>]
ieee80211_sta_tear_down_BA_sessions+0x3f/0x70 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957790] [<ffffffffc061eab4>]
__sta_info_destroy_part1+0x54/0x470 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957818] [<ffffffffc0621bb6>]
__sta_info_destroy+0x16/0x40 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957826] [<ffffffff81841042>] ?
mutex_lock+0x12/0x30
Oct 12 21:48:55 zippy kernel: [3546600.957852] [<ffffffffc0621c78>]
sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957888] [<ffffffffc0636dad>]
ieee80211_del_station+0x1d/0x30 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957924] [<ffffffffc04e94d0>]
nl80211_del_station+0xe0/0x1f0 [cfg80211]
Oct 12 21:48:55 zippy kernel: [3546600.957934] [<ffffffff8176c164>]
genl_family_rcv_msg+0x1e4/0x3e0
Oct 12 21:48:55 zippy kernel: [3546600.957941] [<ffffffff81721ab3>] ?
skb_queue_tail+0x43/0x50
Oct 12 21:48:55 zippy kernel: [3546600.957948] [<ffffffff8176c360>] ?
genl_family_rcv_msg+0x3e0/0x3e0
Oct 12 21:48:55 zippy kernel: [3546600.957954] [<ffffffff8176c3d6>]
genl_rcv_msg+0x76/0xb0
Oct 12 21:48:55 zippy kernel: [3546600.957960] [<ffffffff8176b8d4>]
netlink_rcv_skb+0xa4/0xc0
Oct 12 21:48:55 zippy kernel: [3546600.957966] [<ffffffff8176bf68>]
genl_rcv+0x28/0x40
Oct 12 21:48:55 zippy kernel: [3546600.957972] [<ffffffff8176b2aa>]
netlink_unicast+0x18a/0x240
Oct 12 21:48:55 zippy kernel: [3546600.957978] [<ffffffff8176b65b>]
netlink_sendmsg+0x2fb/0x3a0
Oct 12 21:48:55 zippy kernel: [3546600.957986] [<ffffffff813a06f1>] ?
aa_sock_msg_perm+0x61/0x150
Oct 12 21:48:55 zippy kernel: [3546600.957991] [<ffffffff8171aad8>]
sock_sendmsg+0x38/0x50
Oct 12 21:48:55 zippy kernel: [3546600.957996] [<ffffffff8171b581>]
___sys_sendmsg+0x281/0x290
Oct 12 21:48:55 zippy kernel: [3546600.958004] [<ffffffff8122b088>] ?
destroy_inode+0x38/0x60
Oct 12 21:48:55 zippy kernel: [3546600.958010] [<ffffffff8122b1dd>] ?
evict+0x12d/0x190
Oct 12 21:48:55 zippy kernel: [3546600.958016] [<ffffffff8122670e>] ?
dentry_free+0x4e/0x90
Oct 12 21:48:55 zippy kernel: [3546600.958021] [<ffffffff81226d4e>] ?
dput+0x1ee/0x220
Oct 12 21:48:55 zippy kernel: [3546600.958027] [<ffffffff81230614>] ?
mntput+0x24/0x40
Oct 12 21:48:55 zippy kernel: [3546600.958031] [<ffffffff812112f0>] ?
__fput+0x190/0x220
Oct 12 21:48:55 zippy kernel: [3546600.958036] [<ffffffff8171bed1>]
__sys_sendmsg+0x51/0x90
Oct 12 21:48:55 zippy kernel: [3546600.958041] [<ffffffff8171bf22>]
SyS_sendmsg+0x12/0x20
Oct 12 21:48:55 zippy kernel: [3546600.958049] [<ffffffff818431f2>]
entry_SYSCALL_64_fastpath+0x16/0x71
Oct 12 21:48:55 zippy kernel: [3546600.958077] ---[ end trace
d45f6f07a89c801f ]---
Also added to wireless-info.txt for better legibility.
I'm not sure if this is the right forum to post this.
If it isn't, a pointer to the right place would be appreciated.
Please include me in the reply as i'm not on the list.
Let me know, what additional details i need to provide, as i'm
interested in getting this to work.
Thanks.
Regards
Mario
[-- Attachment #2: wireless-info.txt --]
[-- Type: text/plain, Size: 24437 bytes --]
########## wireless info START ##########
Report from: 12 Oct 2017 22:16 CEST +0200
Booted last: 12 Oct 2017 00:00 CEST +0200
Script from: 25 Mar 2017 07:04 UTC +0000
##### release ###########################
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
##### kernel ############################
Linux 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Parameters: ro
##### desktop ###########################
/usr/share/xsessions/plasma
##### lspci #############################
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I219-V [8086:15b8] (rev 31)
Subsystem: Gigabyte Technology Co., Ltd Ethernet Connection (2) I219-V [1458:e000]
Kernel driver in use: e1000e
03:00.0 Ethernet controller [0200]: Intel Corporation 82546GB Gigabit Ethernet Controller [8086:1079] (rev 03)
Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter [8086:117a]
Kernel driver in use: e1000
03:00.1 Ethernet controller [0200]: Intel Corporation 82546GB Gigabit Ethernet Controller [8086:1079] (rev 03)
Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter [8086:117a]
Kernel driver in use: e1000
03:01.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter [8086:000c]
Kernel driver in use: e100
07:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev 73)
Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4070]
Kernel driver in use: iwlwifi
##### lsusb #############################
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046a:0011 Cherry GmbH G83 (RS 6000) Keyboard
Bus 001 Device 002: ID 046d:c06b Logitech, Inc. G700 Wireless Gaming Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
##### PCMCIA card info ##################
##### rfkill ############################
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
##### lsmod #############################
iwlmvm 311296 0
mac80211 737280 1 iwlmvm
iwlwifi 200704 1 iwlmvm
cfg80211 565248 3 iwlwifi,mac80211,iwlmvm
wmi 20480 0
##### interfaces ########################
auto lo enp3s1 enp3s0f0 br0
iface lo inet loopback
iface enp3s1 inet manual
pre-up ip link set dev enp3s1 up
post-down ip link set dev enp3s1 down
iface enp3s0f0 inet static
address 192.168.23.3
netmask 255.255.255.0
pre-up iptables-restore < /etc/iptables.rules
up route add -net 192.168.123.0/24 gw 192.168.23.4 dev enp3s0f0
up route add -net 192.168.8.0/24 gw 192.168.23.4 dev enp3s0f0
iface br0 inet static
address 192.168.7.3
netmask 255.255.255.0
gateway 192.168.7.1
pre-up iptables-restore < /etc/iptables.rules
bridge_ports enp3s0f1 enp0s31f6
bridge_stp off
bridge_fd 0
bridge_maxwait 0
##### ifconfig ##########################
br0 Link encap:Ethernet HWaddr <MAC 'br0' [IF1]>
inet addr:192.168.7.3 Bcast:192.168.7.255 Mask:255.255.255.0
inet6 addr: fe80::<IP6 'br0' [IF1]>/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13934960 errors:0 dropped:0 overruns:0 frame:0
TX packets:15765171 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6215561896 (6.2 GB) TX bytes:14972856148 (14.9 GB)
enp0s31f6 Link encap:Ethernet HWaddr <MAC 'enp0s31f6' [IF2]>
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:16 Memory:ef500000-ef520000
enp3s1 Link encap:Ethernet HWaddr <MAC 'enp3s1' [IF3]>
inet6 addr: fe80::<IP6 'enp3s1' [IF3]>/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:438075393 errors:0 dropped:0 overruns:0 frame:0
TX packets:441029119 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:54579667263 (54.5 GB) TX bytes:30334186597 (30.3 GB)
enp3s0f0 Link encap:Ethernet HWaddr <MAC 'enp3s0f0' [IF4]>
inet addr:192.168.23.3 Bcast:192.168.23.255 Mask:255.255.255.0
inet6 addr: fe80::<IP6 'enp3s0f0' [IF4]>/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1266025 errors:0 dropped:0 overruns:0 frame:0
TX packets:871646 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1322534113 (1.3 GB) TX bytes:469259116 (469.2 MB)
enp3s0f1 Link encap:Ethernet HWaddr <MAC 'br0' [IF1]>
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:196425 errors:0 dropped:0 overruns:0 frame:0
TX packets:1035558 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:253396859 (253.3 MB) TX bytes:843385655 (843.3 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:76305 errors:0 dropped:0 overruns:0 frame:0
TX packets:76305 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:6768601 (6.7 MB) TX bytes:6768601 (6.7 MB)
wlp7s0 Link encap:Ethernet HWaddr <MAC 'wlp7s0' [IF6]>
inet6 addr: fe80::<IP6 'wlp7s0' [IF6]>/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13929919 errors:0 dropped:0 overruns:0 frame:0
TX packets:16161507 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6184442744 (6.1 GB) TX bytes:15553764211 (15.5 GB)
##### iwconfig ##########################
enp3s0f1 no wireless extensions.
lo no wireless extensions.
br0 no wireless extensions.
enp0s31f6 no wireless extensions.
enp3s0f0 no wireless extensions.
enp3s1 no wireless extensions.
wlp7s0 IEEE 802.11abgn Mode:Master Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
##### route #############################
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.7.1 0.0.0.0 UG 0 0 0 br0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp3s0f0
192.168.7.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.8.0 192.168.23.4 255.255.255.0 UG 0 0 0 enp3s0f0
192.168.23.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0f0
192.168.123.0 192.168.23.4 255.255.255.0 UG 0 0 0 enp3s0f0
##### resolv.conf #######################
domain schmut.com
nameserver 192.168.23.4
##### network managers ##################
Installed:
None found.
Running:
None found.
##### NetworkManager info ###############
NetworkManager is not installed (package "network-manager").
##### NetworkManager.state ##############
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
##### NetworkManager.conf ###############
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq
[ifupdown]
managed=false
##### NetworkManager profiles ###########
No NetworkManager profiles found.
##### iw reg get ########################
Region: Europe/Berlin (based on set time zone)
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
##### iwlist channels ###################
enp3s0f1 no frequency information.
lo no frequency information.
br0 no frequency information.
enp0s31f6 no frequency information.
enp3s0f0 no frequency information.
enp3s1 no frequency information.
wlp7s0 32 channels in total; available frequencies :
Channel 01 : 2.412 GHz
Channel 02 : 2.417 GHz
Channel 03 : 2.422 GHz
Channel 04 : 2.427 GHz
Channel 05 : 2.432 GHz
Channel 06 : 2.437 GHz
Channel 07 : 2.442 GHz
Channel 08 : 2.447 GHz
Channel 09 : 2.452 GHz
Channel 10 : 2.457 GHz
Channel 11 : 2.462 GHz
Channel 12 : 2.467 GHz
Channel 13 : 2.472 GHz
Channel 36 : 5.18 GHz
Channel 40 : 5.2 GHz
Channel 44 : 5.22 GHz
Channel 48 : 5.24 GHz
Channel 52 : 5.26 GHz
Channel 56 : 5.28 GHz
Channel 60 : 5.3 GHz
Channel 64 : 5.32 GHz
Channel 100 : 5.5 GHz
Channel 104 : 5.52 GHz
Channel 108 : 5.54 GHz
Channel 112 : 5.56 GHz
Channel 116 : 5.58 GHz
Channel 120 : 5.6 GHz
Channel 124 : 5.62 GHz
Channel 128 : 5.64 GHz
Channel 132 : 5.66 GHz
Channel 136 : 5.68 GHz
Channel 140 : 5.7 GHz
##### iwlist scan #######################
enp3s0f1 Interface doesn't support scanning.
lo Interface doesn't support scanning.
br0 Interface doesn't support scanning.
enp0s31f6 Interface doesn't support scanning.
enp3s0f0 Interface doesn't support scanning.
enp3s1 Interface doesn't support scanning.
wlp7s0 Interface doesn't support scanning : Operation not supported
##### module infos ######################
[iwlmvm]
filename: /lib/modules/4.4.0-93-generic/kernel/drivers/net/wireless/iwlwifi/mvm/iwlmvm.ko
license: GPL
author: Copyright(c) 2003- 2015 Intel Corporation <ilw@linux.intel.com>
description: The new Intel(R) wireless AGN driver for Linux
srcversion: 6E932A4867C43B598CE49EB
depends: iwlwifi,mac80211,cfg80211
intree: Y
vermagic: 4.4.0-93-generic SMP mod_unload modversions
parm: init_dbg:set to true to debug an ASSERT in INIT fw (default: false (bool)
parm: power_scheme:power management scheme: 1-active, 2-balanced, 3-low power, default: 2 (int)
parm: tfd_q_hang_detect:TFD queues hang detection (default: true (bool)
[mac80211]
filename: /lib/modules/4.4.0-93-generic/kernel/net/mac80211/mac80211.ko
license: GPL
description: IEEE 802.11 subsystem
srcversion: 066D9B501A63401DBFCBF56
depends: cfg80211
intree: Y
vermagic: 4.4.0-93-generic SMP mod_unload modversions
parm: minstrel_vht_only:Use only VHT rates when VHT is supported by sta. (bool)
parm: max_nullfunc_tries:Maximum nullfunc tx tries before disconnecting (reason 4). (int)
parm: max_probe_tries:Maximum probe tries before disconnecting (reason 4). (int)
parm: beacon_loss_count:Number of beacon intervals before we decide beacon was lost. (int)
parm: probe_wait_ms:Maximum time(ms) to wait for probe response before disconnecting (reason 4). (int)
parm: ieee80211_default_rc_algo:Default rate control algorithm for mac80211 to use (charp)
[iwlwifi]
filename: /lib/modules/4.4.0-93-generic/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko
license: GPL
author: Copyright(c) 2003- 2015 Intel Corporation <ilw@linux.intel.com>
description: Intel(R) Wireless WiFi driver for Linux
firmware: iwlwifi-100-5.ucode
firmware: iwlwifi-1000-5.ucode
firmware: iwlwifi-135-6.ucode
firmware: iwlwifi-105-6.ucode
firmware: iwlwifi-2030-6.ucode
firmware: iwlwifi-2000-6.ucode
firmware: iwlwifi-5150-2.ucode
firmware: iwlwifi-5000-5.ucode
firmware: iwlwifi-6000g2b-6.ucode
firmware: iwlwifi-6000g2a-5.ucode
firmware: iwlwifi-6050-5.ucode
firmware: iwlwifi-6000-4.ucode
firmware: iwlwifi-7265D-13.ucode
firmware: iwlwifi-7265-13.ucode
firmware: iwlwifi-3160-13.ucode
firmware: iwlwifi-7260-13.ucode
firmware: iwlwifi-8000-13.ucode
srcversion: 4116E844336D79483D28F6F
depends: cfg80211
intree: Y
vermagic: 4.4.0-93-generic SMP mod_unload modversions
parm: swcrypto:using crypto in software (default 0 [hardware]) (int)
parm: 11n_disable:disable 11n functionality, bitmap: 1: full, 2: disable agg TX, 4: disable agg RX, 8 enable agg TX (uint)
parm: amsdu_size_8K:enable 8K amsdu size (default 0) (int)
parm: fw_restart:restart firmware in case of error (default true) (bool)
parm: antenna_coupling:specify antenna coupling in dB (default: 0 dB) (int)
parm: nvm_file:NVM file name (charp)
parm: d0i3_disable:disable d0i3 functionality (default: Y) (bool)
parm: lar_disable:disable LAR functionality (default: N) (bool)
parm: uapsd_disable:disable U-APSD functionality (default: Y) (bool)
parm: bt_coex_active:enable wifi/bt co-exist (default: enable) (bool)
parm: led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking, 3=Off (default: 0) (int)
parm: power_save:enable WiFi power management (default: disable) (bool)
parm: power_level:default power save level (range from 1 - 5, default: 1) (int)
parm: fw_monitor:firmware monitor - to debug FW (default: false - needs lots of memory) (bool)
[cfg80211]
filename: /lib/modules/4.4.0-93-generic/kernel/net/wireless/cfg80211.ko
description: wireless configuration support
license: GPL
author: Johannes Berg
srcversion: 170344E572FC372824FFAC3
depends:
intree: Y
vermagic: 4.4.0-93-generic SMP mod_unload modversions
parm: bss_entries_limit:limit to number of scan BSS entries (per wiphy, default 1000) (int)
parm: ieee80211_regdom:IEEE 802.11 regulatory domain code (charp)
parm: cfg80211_disable_40mhz_24ghz:Disable 40MHz support in the 2.4GHz band (bool)
##### module parameters #################
[iwlmvm]
init_dbg: N
power_scheme: 2
tfd_q_hang_detect: Y
[mac80211]
beacon_loss_count: 7
ieee80211_default_rc_algo: minstrel_ht
max_nullfunc_tries: 2
max_probe_tries: 5
minstrel_vht_only: Y
probe_wait_ms: 500
[iwlwifi]
11n_disable: 0
amsdu_size_8K: 0
antenna_coupling: 0
bt_coex_active: Y
d0i3_disable: Y
fw_monitor: N
fw_restart: Y
lar_disable: N
led_mode: 0
nvm_file: (null)
power_level: 0
power_save: N
swcrypto: 0
uapsd_disable: Y
[cfg80211]
bss_entries_limit: 1000
cfg80211_disable_40mhz_24ghz: N
ieee80211_regdom: DE
##### /etc/modules ######################
##### modprobe options ##################
[/etc/modprobe.d/blacklist-ath_pci.conf]
blacklist ath_pci
[/etc/modprobe.d/blacklist.conf]
blacklist evbug
blacklist usbmouse
blacklist usbkbd
blacklist eepro100
blacklist de4x5
blacklist eth1394
blacklist snd_intel8x0m
blacklist snd_aw2
blacklist i2c_i801
blacklist prism54
blacklist bcm43xx
blacklist garmin_gps
blacklist asus_acpi
blacklist snd_pcsp
blacklist pcspkr
blacklist amd76x_edac
[/etc/modprobe.d/blacklist-rare-network.conf]
alias net-pf-3 off
alias net-pf-6 off
alias net-pf-9 off
alias net-pf-11 off
alias net-pf-12 off
alias net-pf-19 off
alias net-pf-21 off
alias net-pf-36 off
[/etc/modprobe.d/cfg80211.conf]
options cfg80211 ieee80211_regdom=DE
[/etc/modprobe.d/iwlwifi.conf]
remove iwlwifi \
(/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs /sbin/rmmod) \
&& /sbin/modprobe -r mac80211
[/etc/modprobe.d/mlx4.conf]
softdep mlx4_core post: mlx4_en
##### rc.local ##########################
exit 0
##### pm-utils ##########################
##### udev rules ########################
##### dmesg #############################
[3546610.715458] [<ffffffffc070aa46>] iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]
[3546610.715471] [<ffffffffc0709bfd>] ? iwl_mvm_send_cmd_pdu_status+0x4d/0x70 [iwlmvm]
[3546610.715486] [<ffffffffc070e588>] ? iwl_mvm_sta_tx_agg+0xc8/0x150 [iwlmvm]
[3546610.715500] [<ffffffffc0710853>] iwl_mvm_sta_tx_agg_flush+0x1b3/0x200 [iwlmvm]
[3546610.715513] [<ffffffffc0701492>] iwl_mvm_mac_ampdu_action+0xe2/0x350 [iwlmvm]
[3547281.137583] br0 drop IN=br0 OUT= MAC=<MAC 'br0' [IF1]>:14:89:fd:d3:0d:29:08:00 SRC=192.168.7.10 DST=192.168.7.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36290 DF PROTO=TCP SPT=1716 DPT=37044 WINDOW=249 RES=0x00 ACK FIN URGP=0
[3547285.653367] br0 drop IN=br0 OUT= MAC=<MAC 'br0' [IF1]>:14:89:fd:d3:0d:29:08:00 SRC=192.168.7.10 DST=192.168.7.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36291 DF PROTO=TCP SPT=1716 DPT=37044 WINDOW=249 RES=0x00 ACK FIN URGP=0
[3547294.680452] br0 drop IN=br0 OUT= MAC=<MAC 'br0' [IF1]>:14:89:fd:d3:0d:29:08:00 SRC=192.168.7.10 DST=192.168.7.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36292 DF PROTO=TCP SPT=1716 DPT=37044 WINDOW=249 RES=0x00 ACK FIN URGP=0
[3547312.761016] br0 drop IN=br0 OUT= MAC=<MAC 'br0' [IF1]>:14:89:fd:d3:0d:29:08:00 SRC=192.168.7.10 DST=192.168.7.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36293 DF PROTO=TCP SPT=1716 DPT=37044 WINDOW=249 RES=0x00 ACK FIN URGP=0
[3547348.917940] br0 drop IN=br0 OUT= MAC=<MAC 'br0' [IF1]>:14:89:fd:d3:0d:29:08:00 SRC=192.168.7.10 DST=192.168.7.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36294 DF PROTO=TCP SPT=1716 DPT=37044 WINDOW=249 RES=0x00 ACK FIN URGP=0
[3548211.392714] WARNING: CPU: 5 PID: 1571 at /build/linux-YyUNAI/linux-4.4.0/drivers/net/wireless/iwlwifi/mvm/utils.c:740 iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]()
[3548211.392936] [<ffffffffc070aa46>] iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]
[3548211.392950] [<ffffffffc0709bfd>] ? iwl_mvm_send_cmd_pdu_status+0x4d/0x70 [iwlmvm]
[3548211.392965] [<ffffffffc070e588>] ? iwl_mvm_sta_tx_agg+0xc8/0x150 [iwlmvm]
[3548211.392982] [<ffffffffc0710853>] iwl_mvm_sta_tx_agg_flush+0x1b3/0x200 [iwlmvm]
[3548211.392995] [<ffffffffc0701492>] iwl_mvm_mac_ampdu_action+0xe2/0x350 [iwlmvm]
########## wireless info END ############
Oct 12 21:48:55 zippy kernel: [3546600.957321] ------------[ cut here ]------------
Oct 12 21:48:55 zippy kernel: [3546600.957352] WARNING: CPU: 2 PID: 1571 at /build/linux-YyUNAI/linux-4.4.0/drivers/net/wireless/iwlwifi/mvm/utils.c:740 iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]()
Oct 12 21:48:55 zippy kernel: [3546600.957356] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c md4 nls_utf8 cifs fscache bnep drbg ansi_cprng ctr ccm pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bridge stp llc nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables arc4 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic intel_rapl x86_pkg_temp_thermal snd_hda_intel intel_powerclamp coretemp snd_hda_codec kvm_intel snd_hda_core snd_hwdep input_leds kvm snd_pcm iwlmvm snd_seq_midi joydev snd_seq_midi_event irqbypass mac80211 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper iwlwifi cryptd snd_seq cfg80211 serio_raw snd_seq_device snd_timer snd mei_me soundcore mei shpchp hci_uart btbcm btqca btintel intel_lpss_acpi bluetooth 8250_fintek intel_lpss acpi_als kfifo_buf industrialio tpm_infineon mac_hid acpi_pad parport_pc ppdev lp parport autofs4 hid_generic usbhid i915_bpo intel_ips i2c_algo_bit drm_kms_helper e1000e syscopyarea sysfillrect sysimgblt ptp fb_sys_fops psmouse pps_core e100 e1000 ahci drm mii libahci wmi pinctrl_sunrisepoint video i2c_hid pinctrl_intel hid fjes
Oct 12 21:48:55 zippy kernel: [3546600.957507] CPU: 2 PID: 1571 Comm: hostapd Tainted: G W OE 4.4.0-93-generic #116-Ubuntu
Oct 12 21:48:55 zippy kernel: [3546600.957511] Hardware name: Gigabyte Technology Co., Ltd. Z170M-D3H/Z170M-D3H-CF, BIOS F20 11/17/2016
Oct 12 21:48:55 zippy kernel: [3546600.957514] 0000000000000286 f553094adee223e4 ffff880429a2b748 ffffffff813f9f83
Oct 12 21:48:55 zippy kernel: [3546600.957520] 0000000000000000 ffffffffc07335e8 ffff880429a2b780 ffffffff810812f2
Oct 12 21:48:55 zippy kernel: [3546600.957526] ffff88042605d4c8 0000000000000011 ffff88042605d550 0000000000000007
Oct 12 21:48:55 zippy kernel: [3546600.957531] Call Trace:
Oct 12 21:48:55 zippy kernel: [3546600.957541] [<ffffffff813f9f83>] dump_stack+0x63/0x90
Oct 12 21:48:55 zippy kernel: [3546600.957550] [<ffffffff810812f2>] warn_slowpath_common+0x82/0xc0
Oct 12 21:48:55 zippy kernel: [3546600.957555] [<ffffffff8108143a>] warn_slowpath_null+0x1a/0x20
Oct 12 21:48:55 zippy kernel: [3546600.957572] [<ffffffffc070aa46>] iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957587] [<ffffffffc0709bfd>] ? iwl_mvm_send_cmd_pdu_status+0x4d/0x70 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957604] [<ffffffffc070e588>] ? iwl_mvm_sta_tx_agg+0xc8/0x150 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957621] [<ffffffffc0710853>] iwl_mvm_sta_tx_agg_flush+0x1b3/0x200 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957635] [<ffffffffc0701492>] iwl_mvm_mac_ampdu_action+0xe2/0x350 [iwlmvm]
Oct 12 21:48:55 zippy kernel: [3546600.957669] [<ffffffffc061db5f>] drv_ampdu_action+0x6f/0x180 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957702] [<ffffffffc062972d>] ___ieee80211_stop_tx_ba_session+0x13d/0x260 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957734] [<ffffffffc0629e15>] __ieee80211_stop_tx_ba_session+0x35/0x50 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957763] [<ffffffffc062837f>] ieee80211_sta_tear_down_BA_sessions+0x3f/0x70 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957790] [<ffffffffc061eab4>] __sta_info_destroy_part1+0x54/0x470 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957818] [<ffffffffc0621bb6>] __sta_info_destroy+0x16/0x40 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957826] [<ffffffff81841042>] ? mutex_lock+0x12/0x30
Oct 12 21:48:55 zippy kernel: [3546600.957852] [<ffffffffc0621c78>] sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957888] [<ffffffffc0636dad>] ieee80211_del_station+0x1d/0x30 [mac80211]
Oct 12 21:48:55 zippy kernel: [3546600.957924] [<ffffffffc04e94d0>] nl80211_del_station+0xe0/0x1f0 [cfg80211]
Oct 12 21:48:55 zippy kernel: [3546600.957934] [<ffffffff8176c164>] genl_family_rcv_msg+0x1e4/0x3e0
Oct 12 21:48:55 zippy kernel: [3546600.957941] [<ffffffff81721ab3>] ? skb_queue_tail+0x43/0x50
Oct 12 21:48:55 zippy kernel: [3546600.957948] [<ffffffff8176c360>] ? genl_family_rcv_msg+0x3e0/0x3e0
Oct 12 21:48:55 zippy kernel: [3546600.957954] [<ffffffff8176c3d6>] genl_rcv_msg+0x76/0xb0
Oct 12 21:48:55 zippy kernel: [3546600.957960] [<ffffffff8176b8d4>] netlink_rcv_skb+0xa4/0xc0
Oct 12 21:48:55 zippy kernel: [3546600.957966] [<ffffffff8176bf68>] genl_rcv+0x28/0x40
Oct 12 21:48:55 zippy kernel: [3546600.957972] [<ffffffff8176b2aa>] netlink_unicast+0x18a/0x240
Oct 12 21:48:55 zippy kernel: [3546600.957978] [<ffffffff8176b65b>] netlink_sendmsg+0x2fb/0x3a0
Oct 12 21:48:55 zippy kernel: [3546600.957986] [<ffffffff813a06f1>] ? aa_sock_msg_perm+0x61/0x150
Oct 12 21:48:55 zippy kernel: [3546600.957991] [<ffffffff8171aad8>] sock_sendmsg+0x38/0x50
Oct 12 21:48:55 zippy kernel: [3546600.957996] [<ffffffff8171b581>] ___sys_sendmsg+0x281/0x290
Oct 12 21:48:55 zippy kernel: [3546600.958004] [<ffffffff8122b088>] ? destroy_inode+0x38/0x60
Oct 12 21:48:55 zippy kernel: [3546600.958010] [<ffffffff8122b1dd>] ? evict+0x12d/0x190
Oct 12 21:48:55 zippy kernel: [3546600.958016] [<ffffffff8122670e>] ? dentry_free+0x4e/0x90
Oct 12 21:48:55 zippy kernel: [3546600.958021] [<ffffffff81226d4e>] ? dput+0x1ee/0x220
Oct 12 21:48:55 zippy kernel: [3546600.958027] [<ffffffff81230614>] ? mntput+0x24/0x40
Oct 12 21:48:55 zippy kernel: [3546600.958031] [<ffffffff812112f0>] ? __fput+0x190/0x220
Oct 12 21:48:55 zippy kernel: [3546600.958036] [<ffffffff8171bed1>] __sys_sendmsg+0x51/0x90
Oct 12 21:48:55 zippy kernel: [3546600.958041] [<ffffffff8171bf22>] SyS_sendmsg+0x12/0x20
Oct 12 21:48:55 zippy kernel: [3546600.958049] [<ffffffff818431f2>] entry_SYSCALL_64_fastpath+0x16/0x71
Oct 12 21:48:55 zippy kernel: [3546600.958077] ---[ end trace d45f6f07a89c801f ]---
^ permalink raw reply
* Re: iwlwifi crash with hostapd
From: James Cameron @ 2017-10-12 21:24 UTC (permalink / raw)
To: Mario Theodoridis; +Cc: linux-wireless
In-Reply-To: <6e51916a-6178-5620-8f45-54705c1b4d98@schmut.com>
On Thu, Oct 12, 2017 at 10:26:33PM +0200, Mario Theodoridis wrote:
> Hello everyone,
>
> i'm running Kubuntu 16.04 as a Virtualbox VM host, and a wireless AP
> with an Intel Wireless 7260.
>
> My WLAN connections frequently keep dying, so that i need to
> disconnect and reconnect in order to use them again.
> My syslog is full of these:
>
> Oct 12 21:48:55 zippy kernel: [3546600.957321] ------------[ cut here
> ]------------
> Oct 12 21:48:55 zippy kernel: [3546600.957352] WARNING: CPU: 2 PID: 1571 at
> /build/linux-YyUNAI/linux-4.4.0/drivers/net/wireless/iwlwifi/mvm/utils.c:740
> iwl_mvm_disable_txq+0x2a6/0x2c0 [iwlmvm]()
> [...]
> I'm not sure if this is the right forum to post this.
> If it isn't, a pointer to the right place would be appreciated.
This is a right place. Another right place is Ubuntu bug reporting.
> Please include me in the reply as i'm not on the list.
> Let me know, what additional details i need to provide, as i'm
> interested in getting this to work.
There's a good chance this problem has been fixed already. You
are using a v4.4 kernel with many patches applied by Ubuntu. Here, we
are more concerned with the latest kernels, and v4.4 is quite old.
Please test some of the later kernels, see
https://wiki.ubuntu.com/Kernel/MainlineBuilds
In particular, test v4.13 or v4.14-rc4.
If the problem still happens, capture the same information and send it
again as a reply.
If the problem doesn't happen, then you can either continue to use the
new kernel, or find when the problem was fixed; a long but rewarding
process.
Should the problem have been fixed for v4.10, you might also switch to
using the Ubuntu package linux-generic-hwe-16.04.
https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#hwe-16.04
Hope that helps.
> Thanks.
>
> Regards
>
> Mario
[...]
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* wl1837: poor performance?
From: Russell King - ARM Linux @ 2017-10-12 23:08 UTC (permalink / raw)
To: linux-wireless, Reizer, Eyal, Maxim Altshul
On Thu, Oct 12, 2017 at 10:59:25AM +0100, Russell King - ARM Linux wrote:
> It looks like ti wilink is unmaintained, so I've added some people who
> have touched the driver recently.
>
> Running wl1837 on a Hummingboard2 (iMX6 Dual core) I've seen one instance
> of the warning below. Luckily, the recovery worked and connectivity was
> maintained.
I also have a question about seemingly poor performance of this driver,
so starting a new thread.
When running a ping on two clients (and only two clients) connected to
a single AP:
AP: Broadcom brcmfmac bcm4330 Linux machine.
With a ping running on each client machine, the AP reports:
# iw wlan0 station dump
Station a4:xx:xx:xx:xx:xx (on wlan0) <-- rtl8192eu
inactive time: 0 ms
rx packets: 6846
tx packets: 2108
tx failed: 0
tx bitrate: 13.0 MBit/s
rx bitrate: 19.5 MBit/s
authorized: yes
authenticated: yes
WMM/WME: yes
TDLS peer: no
Station 00:0f:00:xx:xx:xx (on wlan0) <-- wl1837
inactive time: 0 ms
rx packets: 589233
tx packets: 360969
tx failed: 737
tx bitrate: 13.0 MBit/s
rx bitrate: 19.5 MBit/s
authorized: yes
authenticated: yes
WMM/WME: yes
TDLS peer: no
Client 1: wl1837 using mainline driver:
# iw wlan0 link
Connected to xx:xx:xx:xx:xx:xx (on wlan0)
SSID: XXXX
freq: 2447
RX: 223158 bytes (2307 packets)
TX: 1502828 bytes (1955 packets)
signal: -78 dBm
tx bitrate: 19.5 MBit/s MCS 2
bss flags: short-preamble short-slot-time
dtim period: 2
beacon int: 100
Ping statistics:
64 bytes from 192.168.250.1: icmp_seq=85 ttl=64 time=10.6 ms
64 bytes from 192.168.250.1: icmp_seq=86 ttl=64 time=10.5 ms
64 bytes from 192.168.250.1: icmp_seq=87 ttl=64 time=10.9 ms
64 bytes from 192.168.250.1: icmp_seq=88 ttl=64 time=10.4 ms
64 bytes from 192.168.250.1: icmp_seq=89 ttl=64 time=12.2 ms
64 bytes from 192.168.250.1: icmp_seq=90 ttl=64 time=12.6 ms
90 packets transmitted, 88 received, 2% packet loss, time 89223ms
rtt min/avg/max/mdev = 3.359/58.323/2275.188/273.244 ms, pipe 3
Client 2: rtl8192eu (using vendor driver):
# iw wlan0 link
Connected to xx:xx:xx:xx:xx:xx (on wlan0)
SSID: XXXX
freq: 2447
signal: -78 dBm
tx bitrate: 65.0 MBit/s
Ping statistics:
64 bytes from 192.168.250.1: icmp_seq=85 ttl=64 time=6.55 ms
64 bytes from 192.168.250.1: icmp_seq=86 ttl=64 time=3.34 ms
64 bytes from 192.168.250.1: icmp_seq=87 ttl=64 time=3.96 ms
64 bytes from 192.168.250.1: icmp_seq=88 ttl=64 time=3.47 ms
64 bytes from 192.168.250.1: icmp_seq=89 ttl=64 time=3.48 ms
64 bytes from 192.168.250.1: icmp_seq=90 ttl=64 time=3.35 ms
90 packets transmitted, 90 received, 0% packet loss, time 89124ms
rtt min/avg/max/mdev = 3.191/4.902/26.607/3.978 ms
The difference is quite marked: the rtl8192eu seems to perform much
better than the wl1837 even though the wl1837 is located closer to
the AP than the rtl8192eu.
Most of the ping times via the wl1837 look to be around 10ms, vs
3ms for the rtl8192eu, as can be seen above.
Individually, the ping times are very similar to the above.
All wifi interfaces have power save disabled, either via the driver
module options where possible, or via iw wlan0 set power_save 0
So, why does wl1837 appear to be performing not as well than the
rtl8192eu?
Are out of tree vendor drivers in fact better than kernel-merged
drivers? :)
The machines are synchronised via NTP across the wifi link as best
they can manage with the irregularity in the network (the rtl8192eu
syncs /way/ better than the wl1837 - rtl8192eu is always sync'd to
within 250us, the wl1837 keeps reporting milliseconds offset in the
NTP loop stats):
>From the AP:
23:54:18.026441 IP 192.168.250.4 > 192.168.250.1: ICMP echo request, id 1112, seq 110, length 64
23:54:18.026604 IP 192.168.250.1 > 192.168.250.4: ICMP echo reply, id 1112, seq 110, length 64
23:54:19.036396 IP 192.168.250.4 > 192.168.250.1: ICMP echo request, id 1112, seq 111, length 64
23:54:19.036560 IP 192.168.250.1 > 192.168.250.4: ICMP echo reply, id 1112, seq 111, length 64
23:54:20.036874 IP 192.168.250.4 > 192.168.250.1: ICMP echo request, id 1112, seq 112, length 64
23:54:20.037025 IP 192.168.250.1 > 192.168.250.4: ICMP echo reply, id 1112, seq 112, length 64
>From the wl1837 client:
23:54:18.028504 IP 192.168.250.4 > 192.168.250.1: ICMP echo request, id 1112, seq 110, length 64
23:54:18.032074 IP 192.168.250.1 > 192.168.250.4: ICMP echo reply, id 1112, seq 110, length 64
23:54:19.030464 IP 192.168.250.4 > 192.168.250.1: ICMP echo request, id 1112, seq 111, length 64
23:54:19.043282 IP 192.168.250.1 > 192.168.250.4: ICMP echo reply, id 1112, seq 111, length 64
23:54:20.031082 IP 192.168.250.4 > 192.168.250.1: ICMP echo request, id 1112, seq 112, length 64
23:54:20.042887 IP 192.168.250.1 > 192.168.250.4: ICMP echo reply, id 1112, seq 112, length 64
Same for the rtl8192eu - AP:
23:58:35.215467 IP 192.168.250.2 > 192.168.250.1: ICMP echo request, id 23188, seq 6, length 64
23:58:35.215659 IP 192.168.250.1 > 192.168.250.2: ICMP echo reply, id 23188, seq 6, length 64
23:58:36.217136 IP 192.168.250.2 > 192.168.250.1: ICMP echo request, id 23188, seq 7, length 64
23:58:36.217337 IP 192.168.250.1 > 192.168.250.2: ICMP echo reply, id 23188, seq 7, length 64
23:58:37.218105 IP 192.168.250.2 > 192.168.250.1: ICMP echo request, id 23188, seq 8, length 64
23:58:37.218290 IP 192.168.250.1 > 192.168.250.2: ICMP echo reply, id 23188, seq 8, length 64
rtl8192eu:
23:58:35.213928 IP 192.168.250.2 > 192.168.250.1: ICMP echo request, id 23188, seq 6, length 64
23:58:35.219372 IP 192.168.250.1 > 192.168.250.2: ICMP echo reply, id 23188, seq 6, length 64
23:58:36.215656 IP 192.168.250.2 > 192.168.250.1: ICMP echo request, id 23188, seq 7, length 64
23:58:36.219300 IP 192.168.250.1 > 192.168.250.2: ICMP echo reply, id 23188, seq 7, length 64
23:58:37.216558 IP 192.168.250.2 > 192.168.250.1: ICMP echo request, id 23188, seq 8, length 64
23:58:37.223240 IP 192.168.250.1 > 192.168.250.2: ICMP echo reply, id 23188, seq 8, length 64
If you closely look at the results, it appears that the packet at
"seq 112" was received before it was transmitted - presumably because
NTP is not able to synchronise very well because of the poorly
performing driver/hardware. So, it's not possible to determine if
it's the transmit or the receive which is causing the delay.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: AceLan Kao @ 2017-10-13 1:12 UTC (permalink / raw)
To: Daniel Drake
Cc: Kalle Valo, Christoph Hellwig, QCA ath9k Development,
linux-wireless, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CAFv23QkLJ0m112Y8iAGv+6DyFT52Hqnxq5Fy=ryWTWxu8oTXdw@mail.gmail.com>
Hi Daniel,
After applied the 2 commits you mentioned in the email, ath9k works.
https://marc.info/?l=linux-wireless&m=150631274108016&w=2
https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657
Best regards,
AceLan Kao.
2017-10-05 14:39 GMT+08:00 AceLan Kao <acelan.kao@canonical.com>:
> Hi all,
>
> Please drop my patches, Qualcomm is working internally and will submit
> the MSI patch by themselves.
> Thanks.
>
> Hi Daniel,
>
> I'll try your patches tomorrow.
>
> Best regards,
> AceLan Kao.
>
> 2017-10-02 12:21 GMT+08:00 Daniel Drake <drake@endlessm.com>:
>> Hi AceLan,
>>
>> On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao <acelan.kao@canonical.com> wrote:
>>> Hi Daniel,
>>>
>>> I've tried your patch, but it doesn't work for me.
>>> Wifi can scan AP, but can't get connected.
>>
>> Can you please clarify which patch(es) you have tried?
>>
>> This is the base patch which adds the infrastructure to request
>> specific MSI IRQ vectors:
>> https://marc.info/?l=linux-wireless&m=150631274108016&w=2
>>
>> This is the ath9k MSI patch which makes use of that:
>> https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657
>>
>> If you were already able to use ath9k MSI interrupts without specific
>> consideration for which MSI vector numbers were used, these are the
>> possible explanations that spring to mind:
>>
>> 1. You got lucky and it picked a vector number that is 4-aligned. You
>> can check this in the "lspci -vvv" output. You'll see something like:
>> Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+
>> Address: 00000000fee0300c Data: 4142
>> The lower number is the vector number. In my example here 0x42 (66) is
>> not 4-aligned so the failure condition will be hit.
>>
>> 2. You are using interrupt remapping, which I suspect may provide a
>> high likelihood of MSI interrupt vectors being 4-aligned. See if
>> /proc/interrupts shows the IRQ type as IR-PCI-MSI
>> Unfortunately interrupt remapping is not available here,
>> https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023717.html
>>
>> 3. My assumption that all ath9k hardware corrupts the MSI vector
>> number could wrong. However we've seen this on different wifi modules
>> in laptops produced by different OEMs and ODMs, so it seems to be a
>> somewhat widespread problem at least.
>>
>> 4. My assumption that ath9k hardware is corrupting the MSI vector
>> number could be wrong; maybe another component is to blame, could it
>> be a BIOS issue? Admittedly I don't really know how I can debug the
>> layers inbetween seeing the MSI Message Data value disagree with the
>> vector number being handled inside do_IRQ().
>>
>> Daniel
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: Daniel Drake @ 2017-10-13 1:17 UTC (permalink / raw)
To: AceLan Kao
Cc: Kalle Valo, Christoph Hellwig, QCA ath9k Development,
linux-wireless, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CAFv23Q=dFRfxXQnY3pu_zV-yK9yaw-t3-Kn2q9YFFuyB9jJMog@mail.gmail.com>
On Fri, Oct 13, 2017 at 9:12 AM, AceLan Kao <acelan.kao@canonical.com> wrote:
> Hi Daniel,
>
> After applied the 2 commits you mentioned in the email, ath9k works.
>
> https://marc.info/?l=linux-wireless&m=150631274108016&w=2
> https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657
Thanks for testing. However the approach was basically rejected in this thread:
[PATCH] PCI MSI: allow alignment restrictions on vector allocation
https://marc.info/?t=150631283200001&r=1&w=2
So we still need an upstream solution.
I am curious what Qualcomm have to say about their hardware corrupting
the MSI Message Data value. Is there any news on them submitting the
MSI support patch?
Separately we have the option of seeing if Intel can help us unblock
the legacy interrupt (assuming it was simply blocked by the BIOS), or
adding an interrupt-polling fallback path to ath9k.
Daniel
^ permalink raw reply
* pull-request: wireless-drivers 2017-10-13
From: Kalle Valo @ 2017-10-13 7:25 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net tree, more info in the signed tag below.
Please let me know if there are any problems.
Kalle
The following changes since commit 3e747fa18202896b5be66b88478352d5880fb8eb:
Merge ath-current from ath.git (2017-09-25 10:06:12 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-10-13
for you to fetch changes up to a6127b4440d1f74f26b64006b2f50c9dc6d66efc:
Merge tag 'iwlwifi-for-kalle-2017-10-06' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2017-10-09 17:31:39 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 4.14
Nothing really special standing out, all of these are important fixes
which should go to 4.14.
iwlwifi
* fix support for 3168 device series
* fix a potential crash when using FW debugging recording;
* improve channel flags parsing to avoid warnings on too long traces
* return -ENODATA when the temperature is not available, since the
-EIO we were returning was causing fatal errors in userspace
* avoid printing too many messages in dmesg when using monitor mode,
since this can become very noisy and completely flood the logs
brcmsmac
* reduce stack usage to avoid frame size warnings with KASAN
brcmfmac
* add a check to avoid copying uninitialised memory
rtlwifi:
* fix a regression with rtl8821ae starting from v4.11 where
connections was frequently lost
----------------------------------------------------------------
Arnd Bergmann (1):
brcmsmac: make some local variables 'static const' to reduce stack size
Chaya Rachel Ivgi (1):
iwlwifi: nvm: set the correct offsets to 3168 series
Golan Ben Ami (1):
iwlwifi: stop dbgc recording before stopping DMA
Johannes Berg (1):
iwlwifi: nvm-parse: unify channel flags printing
Kalle Valo (1):
Merge tag 'iwlwifi-for-kalle-2017-10-06' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Kevin Cernekee (1):
brcmfmac: Add check for short event packets
Larry Finger (1):
rtlwifi: rtl8821ae: Fix connection lost problem
Luca Coelho (1):
iwlwifi: mvm: return -ENODATA when reading the temperature with the FW down
Shaul Triebitz (1):
iwlwifi: mvm: do not print security error in monitor mode
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 3 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 197 ++++++++++-----------
drivers/net/wireless/intel/iwlwifi/cfg/7000.c | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 2 +-
.../net/wireless/intel/iwlwifi/fw/api/nvm-reg.h | 2 +
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 7 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 15 ++
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 16 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 137 +++++++-------
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 7 +
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 21 ++-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 2 +-
18 files changed, 232 insertions(+), 197 deletions(-)
^ permalink raw reply
* Re: bcma: keep *config menu together
From: Kalle Valo @ 2017-10-13 9:37 UTC (permalink / raw)
To: Randy Dunlap; +Cc: LKML, linux-wireless, Andrew Morton, Rafał Miłecki
In-Reply-To: <c4250321-0c2e-4f9c-7fea-aa1001d9c3a8@infradead.org>
Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Use "if BCMA"/"endif" around all Kconfig symbols so that they are
> kept together in *config menus instead of showing up in unexpected
> places. Also remove "depends on BCMA" since this is handled by the
> "if BCMA" addition.
>
> Tested with ARCH={x86_64,MIPS} using make {n,menu,g,x}config.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Rafał Miłecki <zajec5@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
0f0a0af82626 bcma: keep *config menu together
--
https://patchwork.kernel.org/patch/9974679/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: kill useless list_empty checks
From: Kalle Valo @ 2017-10-13 9:38 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, Douglas Anderson, Ganapathi Bhat
In-Reply-To: <1507043984-9832-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> From: Douglas Anderson <dianders@chromium.org>
>
> There's absolutely no reason to check to see if a list is empty
> before iterating through it. It's just like writing code like
> this:
>
> if (count != 0) {
> for (i = 0; i < count; i++) {
> ...
> }
> }
>
> The loop will already be avoided if "count == 0" so there was no
> reason to check.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
2 patches applied to wireless-drivers-next.git, thanks.
40351051d022 mwifiex: kill useless list_empty checks
f0f7c2275fb9 mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c
--
https://patchwork.kernel.org/patch/9983061/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: double the size of chan_stats array in adapter
From: Kalle Valo @ 2017-10-13 9:39 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang,
James Cao, Mangesh Malusare, Rohit Fule, Ganapathi Bhat
In-Reply-To: <1507118766-17713-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> From: Rohit Fule <rohitf@marvell.com>
>
> When a user requests scan, driver sends multiple scan requests
> to firmware, which might be active or passive. Firmware will
> send channel statistics for each channel in the request. This will
> be stored in chan_stats array.
>
> Few channels might report hidden SSIDs in passive scan results.
> So, once the original scan request is finished, driver issues an
> active scan request for all channels which reported hidden SSIDs.
> This will cause duplicates in the chan_stats array. At worst,
> every channel will have a hidden SSID, in which case the driver
> can issue active scan requests for each channel. So the complete
> scan statistics size will be twice of existing limit.
>
> At present maximum number of channels returned in scan statistics
> is 31(BG) + 14(A) = 45. Clearly there will be an overflow of the
> chan_stats array in the above mentioned scenario. To fix this
> double the size of chan_stats array.
>
> Signed-off-by: Rohit Fule <rohitf@marvell.com>
> Signed-off-by: Mangesh Malusare <mmangesh@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
2d5cc60949e0 mwifiex: double the size of chan_stats array in adapter
--
https://patchwork.kernel.org/patch/9984471/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] mwifiex: Use put_unaligned_le32
From: Kalle Valo @ 2017-10-13 9:42 UTC (permalink / raw)
To: Himanshu Jha
Cc: amitkarwar, nishants, gbhat, huxm, linux-wireless, netdev,
linux-kernel, Himanshu Jha
In-Reply-To: <1507302279-3875-1-git-send-email-himanshujha199640@gmail.com>
Himanshu Jha <himanshujha199640@gmail.com> wrote:
> Use put_unaligned_le32 rather than using byte ordering function and
> memcpy which makes code clear.
> Also, add the header file where it is declared.
>
> Done using Coccinelle and semantic patch used is :
>
> @ rule1 @
> identifier tmp; expression ptr,x; type T;
> @@
>
> - tmp = cpu_to_le32(x);
>
> <+... when != tmp
> - memcpy(ptr, (T)&tmp, ...);
> + put_unaligned_le32(x,ptr);
> ...+>
>
> @ depends on rule1 @
> type j; identifier tmp;
> @@
>
> - j tmp;
> ...when != tmp
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
317049204cd3 mwifiex: Use put_unaligned_le32
--
https://patchwork.kernel.org/patch/9989655/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [01/10] rtlwifi: Fix MAX MPDU of VHT capability
From: Kalle Valo @ 2017-10-13 9:44 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, Ping-Ke Shih, Larry Finger, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting
In-Reply-To: <20170929194800.15617-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> We must choose only one of VHT_CAP among
> IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895,
> IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991 and
> IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Cc: Birming Chiu <birming@realtek.com>
> Cc: Shaofu <shaofu@realtek.com>
> Cc: Steven Ting <steventing@realtek.com>
10 patches applied to wireless-drivers-next.git, thanks.
f06eb3f9c03e rtlwifi: Fix MAX MPDU of VHT capability
ecf4000e0d92 rtlwifi: Remove redundant semicolon in wifi.h.
0c07bd745760 rtlwifi: rtl8192ee: Make driver support 64bits DMA.
cdc9c7a032aa rtlwifi: Implement rtl_get_tx_hw_rate to yield correct hw_rate
c1816f1709e8 rtlwifi: Add rtl_get_hal_edca_param() to generate register's format of EDCA.
74451b935c42 rtlwifi: Add TX/RX throughput statistics in period
08ab7465f36c rtlwifi: Add RSSI and RF type to wifi.h for phydm
aa59a1e7c6e8 rtlwifi: Remove BAND_NUM and related fields
1d22b17744a3 rtlwifi: Add bw_update parameter for RA mask update.
84efbad4f867 rtlwifi: Add module parameter ASPM
--
https://patchwork.kernel.org/patch/9978583/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 03/10] rtlwifi: rtl8192ee: Make driver support 64bits DMA.
From: Kalle Valo @ 2017-10-13 9:56 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, Ping-Ke Shih, Yan-Hsuan Chuang, Birming Chiu,
Shaofu, Steven Ting
In-Reply-To: <20170929194800.15617-4-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> 1. Both 32-bit and 64-bit use the same TX/RX buffer desc layout
> 2. Extend set_desc() and get_desc() to set and get 64-bit address
> 3. Remove directive DMA_IS_64BIT
> 4. Add module parameter to turn on 64-bit dma
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Cc: Birming Chiu <birming@realtek.com>
> Cc: Shaofu <shaofu@realtek.com>
> Cc: Steven Ting <steventing@realtek.com>
I applied this already but I still want to give few general remarks
about frequent problems with rtlwifi patches:
> @@ -691,9 +691,10 @@ static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw,
> return 0;
> rtlpci->rx_ring[rxring_idx].rx_buf[desc_idx] = skb;
> if (rtlpriv->use_new_trx_flow) {
> + /* skb->cb may be 64 bit address */
> rtlpriv->cfg->ops->set_desc(hw, (u8 *)entry, false,
> HW_DESC_RX_PREPARE,
> - (u8 *)&bufferaddress);
> + (u8 *)(dma_addr_t *)skb->cb);
What I see a lot are these very questionable looking use of casts like
here. Casting should be also avoided as much as possible and used only
when it's absolutely necessary. If you have to do (u8) or (u8 *) almost
in every second line something is very wrong.
> +static void platform_enable_dma64(struct pci_dev *pdev, bool dma64)
> +{
> + u8 value;
> +
> + pci_read_config_byte(pdev, 0x719, &value);
> +
> + /* 0x719 Bit5 is DMA64 bit fetch. */
> + if (dma64)
> + value |= BIT(5);
> + else
> + value &= ~BIT(5);
> +
> + pci_write_config_byte(pdev, 0x719, value);
> +}
Another gripe I have is about the use of magic values. There always
should be a define/enum with a descriptive name for register addresses
and values.
--
Kalle Valo
^ permalink raw reply
* Re: rtlwifi: Remove unused cur_rfstate variables
From: Kalle Valo @ 2017-10-13 9:58 UTC (permalink / raw)
To: Christos Gkekas
Cc: Larry Finger, Chaoming Li, linux-wireless, netdev, linux-kernel,
Christos Gkekas
In-Reply-To: <1507756515-15738-1-git-send-email-chris.gekas@gmail.com>
Christos Gkekas <chris.gekas@gmail.com> wrote:
> Clean up unused cur_rfstate variables in rtl8188ee, rtl8723ae, rtl8723be
> and rtl8821ae.
>
> Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
76d7b12cbbe2 rtlwifi: Remove unused cur_rfstate variables
--
https://patchwork.kernel.org/patch/10000659/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2,1/8] qtnfmac: do not cache AP settings in driver structures
From: Kalle Valo @ 2017-10-13 10:00 UTC (permalink / raw)
To: Igor Mitsyanko; +Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20171005013813.13332-2-igor.mitsyanko.os@quantenna.com>
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>
> Cached AP setings are passed to WiFi card right after they are
> initialized and are never used for anything else. There is no
> point in keeping them in driver state.
>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
8 patches applied to wireless-drivers-next.git, thanks.
9b692df1e66f qtnfmac: do not cache AP settings in driver structures
8b5f4aa7340a qtnfmac: pass all AP settings to wireless card for processing
f99201cb084d qtnfmac: pass channel definition to WiFi card on START_AP command
524522c445e1 qtnfmac: get rid of QTNF_STATE_AP_CONFIG
d7b80052fa91 qtnfmac: get rid of QTNF_STATE_AP_START flag
9766d1dd52ec qtnfmac: do not cache BSS state in per-VIF structure
d23d13613162 qtnfmac: make encryption info a part of CONNECT command.
ef81e8e9dbbb qtnfmac: do not cache current channel info in driver's state
--
https://patchwork.kernel.org/patch/9986277/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rsi: fix integer overflow warning
From: Kalle Valo @ 2017-10-13 10:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Prameela Rani Garnepudi, Amitkumar Karwar, Arnd Bergmann,
Pavani Muthyala, Karun Eagalapati, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20171005120547.328687-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> gcc produces a harmless warning about a recently introduced
> signed integer overflow:
>
> drivers/net/wireless/rsi/rsi_91x_hal.c: In function 'rsi_prepare_mgmt_desc':
> include/uapi/linux/swab.h:13:15: error: integer overflow in expression [-Werror=overflow]
> (((__u16)(x) & (__u16)0x00ffU) << 8) | \
> ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
> include/uapi/linux/swab.h:104:2: note: in expansion of macro '___constant_swab16'
> ___constant_swab16(x) : \
> ^~~~~~~~~~~~~~~~~~
> include/uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16'
> #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
> ^~~~~~~~
> include/linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16'
> #define cpu_to_le16 __cpu_to_le16
> ^~~~~~~~~~~~~
> drivers/net/wireless/rsi/rsi_91x_hal.c:136:3: note: in expansion of macro 'cpu_to_le16'
> cpu_to_le16((tx_params->vap_id << RSI_DESC_VAP_ID_OFST) &
> ^~~~~~~~~~~
>
> The problem is that the 'mask' value is a signed integer that gets
> turned into a negative number when truncated to 16 bits. Making it
> an unsigned constant avoids this.
>
> Fixes: eac4eed3224b ("rsi: tx and rx path enhancements for p2p mode")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
a39644b235c1 rsi: fix integer overflow warning
--
https://patchwork.kernel.org/patch/9986961/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] backports: remove CRYPTO_CCM backport
From: Johannes Berg @ 2017-10-13 10:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This never actually worked properly as far as I can tell,
and now it looks like it won't even compile due to the
real crypto_memneq() backport.
Just remove it - distro kernels have it enabled and all
others should just enable it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
backport/compat/Kconfig | 11 -------
backport/compat/Makefile | 1 -
backport/compat/backports.h | 10 ------
backport/compat/main.c | 9 +-----
patches/crypto-ccm.patch | 78 ---------------------------------------------
5 files changed, 1 insertion(+), 108 deletions(-)
delete mode 100644 patches/crypto-ccm.patch
diff --git a/backport/compat/Kconfig b/backport/compat/Kconfig
index 542cf0cca781..492efbfc7d9f 100644
--- a/backport/compat/Kconfig
+++ b/backport/compat/Kconfig
@@ -102,17 +102,6 @@ config BPAUTO_USERSEL_BUILD_ALL
It's only really useful for compat testing, so
you probably shouldn't enable it.
-config BPAUTO_CRYPTO_CCM
- depends on CRYPTO_AEAD
- depends on CRYPTO_CTR
- bool
-
-config BPAUTO_BUILD_CRYPTO_CCM
- bool
- default n if CRYPTO_CCM
- default y if BPAUTO_CRYPTO_CCM
- #c-file crypto/ccm.c
-
config BPAUTO_CRYPTO_SKCIPHER
tristate
depends on KERNEL_4_3
diff --git a/backport/compat/Makefile b/backport/compat/Makefile
index ead22a0099fc..69cfd514da71 100644
--- a/backport/compat/Makefile
+++ b/backport/compat/Makefile
@@ -37,7 +37,6 @@ compat-$(CPTCFG_KERNEL_4_7) += backport-4.7.o
compat-$(CPTCFG_KERNEL_4_8) += backport-4.8.o
compat-$(CPTCFG_KERNEL_4_10) += backport-4.10.o
-compat-$(CPTCFG_BPAUTO_BUILD_CRYPTO_CCM) += crypto-ccm.o
compat-$(CPTCFG_BPAUTO_CRYPTO_SKCIPHER) += crypto-skcipher.o
compat-$(CPTCFG_BPAUTO_BUILD_SYSTEM_DATA_VERIFICATION) += verification/verify.o
diff --git a/backport/compat/backports.h b/backport/compat/backports.h
index ccc8972b41f6..538488887fca 100644
--- a/backport/compat/backports.h
+++ b/backport/compat/backports.h
@@ -3,16 +3,6 @@
#include <linux/version.h>
-#ifdef CPTCFG_BPAUTO_BUILD_CRYPTO_CCM
-int crypto_ccm_module_init(void);
-void crypto_ccm_module_exit(void);
-#else
-static inline int crypto_ccm_module_init(void)
-{ return 0; }
-static inline void crypto_ccm_module_exit(void)
-{}
-#endif
-
#ifdef CPTCFG_BPAUTO_BUILD_WANT_DEV_COREDUMP
int devcoredump_init(void);
void devcoredump_exit(void);
diff --git a/backport/compat/main.c b/backport/compat/main.c
index 5d45e3dad3e3..0bf04201a0bd 100644
--- a/backport/compat/main.c
+++ b/backport/compat/main.c
@@ -53,16 +53,10 @@ EXPORT_SYMBOL_GPL(backport_dependency_symbol);
static int __init backport_init(void)
{
- int ret = crypto_ccm_module_init();
+ int ret = devcoredump_init();
if (ret)
return ret;
- ret = devcoredump_init();
- if (ret) {
- crypto_ccm_module_exit();
- return ret;
- }
-
printk(KERN_INFO "Loading modules backported from " CPTCFG_KERNEL_NAME
#ifndef BACKPORTS_GIT_TRACKED
" version " CPTCFG_KERNEL_VERSION
@@ -86,7 +80,6 @@ subsys_initcall(backport_init);
static void __exit backport_exit(void)
{
- crypto_ccm_module_exit();
devcoredump_exit();
}
module_exit(backport_exit);
diff --git a/patches/crypto-ccm.patch b/patches/crypto-ccm.patch
deleted file mode 100644
index 2136689eca91..000000000000
--- a/patches/crypto-ccm.patch
+++ /dev/null
@@ -1,78 +0,0 @@
---- a/compat/crypto-ccm.c
-+++ b/compat/crypto-ccm.c
-@@ -14,13 +14,44 @@
- #include <crypto/internal/hash.h>
- #include <crypto/internal/skcipher.h>
- #include <crypto/scatterwalk.h>
-+#include <crypto/algapi.h>
- #include <linux/err.h>
- #include <linux/init.h>
- #include <linux/kernel.h>
- #include <linux/module.h>
- #include <linux/slab.h>
-+#include <linux/version.h>
-
--#include "internal.h"
-+#if LINUX_VERSION_IS_LESS(3,13,0)
-+/* consider properly backporting this? */
-+static int crypto_memneq(const void *a, const void *b, size_t size)
-+{
-+ unsigned long neq = 0;
-+
-+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
-+ while (size >= sizeof(unsigned long)) {
-+ neq |= *(unsigned long *)a ^ *(unsigned long *)b;
-+ /* OPTIMIZER_HIDE_VAR(neq); */
-+ barrier();
-+ a += sizeof(unsigned long);
-+ b += sizeof(unsigned long);
-+ size -= sizeof(unsigned long);
-+ }
-+#endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
-+ while (size > 0) {
-+ neq |= *(unsigned char *)a ^ *(unsigned char *)b;
-+ /* OPTIMIZER_HIDE_VAR(neq); */
-+ barrier();
-+ a += 1;
-+ b += 1;
-+ size -= 1;
-+ }
-+ return neq != 0UL ? 1 : 0;
-+}
-+#endif
-+
-+/* from internal.h */
-+struct crypto_alg *crypto_alg_mod_lookup(const char *name, u32 type, u32 mask);
-
- struct ccm_instance_ctx {
- struct crypto_skcipher_spawn ctr;
-@@ -1001,7 +1032,7 @@ static struct crypto_template crypto_cbc
- .module = THIS_MODULE,
- };
-
--static int __init crypto_ccm_module_init(void)
-+int __init crypto_ccm_module_init(void)
- {
- int err;
-
-@@ -1033,19 +1064,10 @@ out_undo_cbcmac:
- goto out;
- }
-
--static void __exit crypto_ccm_module_exit(void)
-+void __exit crypto_ccm_module_exit(void)
- {
- crypto_unregister_template(&crypto_rfc4309_tmpl);
- crypto_unregister_template(&crypto_ccm_tmpl);
- crypto_unregister_template(&crypto_ccm_base_tmpl);
- crypto_unregister_template(&crypto_cbcmac_tmpl);
- }
--
--module_init(crypto_ccm_module_init);
--module_exit(crypto_ccm_module_exit);
--
--MODULE_LICENSE("GPL");
--MODULE_DESCRIPTION("Counter with CBC MAC");
--MODULE_ALIAS_CRYPTO("ccm_base");
--MODULE_ALIAS_CRYPTO("rfc4309");
--MODULE_ALIAS_CRYPTO("ccm");
--
2.14.2
^ permalink raw reply related
* Re: [PATCH] backports: remove CRYPTO_CCM backport
From: Johannes Berg @ 2017-10-13 10:32 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20171013102818.26226-1-johannes@sipsolutions.net>
T24gRnJpLCAyMDE3LTEwLTEzIGF0IDEyOjI4ICswMjAwLCBKb2hhbm5lcyBCZXJnIHdyb3RlOgo+
IEZyb206IEpvaGFubmVzIEJlcmcgPGpvaGFubmVzLmJlcmdAaW50ZWwuY29tPgo+IAo+IFRoaXMg
bmV2ZXIgYWN0dWFsbHkgd29ya2VkIHByb3Blcmx5IGFzIGZhciBhcyBJIGNhbiB0ZWxsLAo+IGFu
ZCBub3cgaXQgbG9va3MgbGlrZSBpdCB3b24ndCBldmVuIGNvbXBpbGUgZHVlIHRvIHRoZQo+IHJl
YWwgY3J5cHRvX21lbW5lcSgpIGJhY2twb3J0Lgo+IAo+IEp1c3QgcmVtb3ZlIGl0IC0gZGlzdHJv
IGtlcm5lbHMgaGF2ZSBpdCBlbmFibGVkIGFuZCBhbGwKPiBvdGhlcnMgc2hvdWxkIGp1c3QgZW5h
YmxlIGl0LgoKU29ycnksIHdyb25nIGxpc3QsIHdpbGwgcmVzZW5kLgoKam9oYW5uZXMKSW50ZWwg
RGV1dHNjaGxhbmQgR21iSApSZWdpc3RlcmVkIEFkZHJlc3M6IEFtIENhbXBlb24gMTAtMTIsIDg1
NTc5IE5ldWJpYmVyZywgR2VybWFueQpUZWw6ICs0OSA4OSA5OSA4ODUzLTAsIHd3dy5pbnRlbC5k
ZQpNYW5hZ2luZyBEaXJlY3RvcnM6IENocmlzdGluIEVpc2Vuc2NobWlkLCBDaHJpc3RpYW4gTGFt
cHJlY2h0ZXIKQ2hhaXJwZXJzb24gb2YgdGhlIFN1cGVydmlzb3J5IEJvYXJkOiBOaWNvbGUgTGF1
ClJlZ2lzdGVyZWQgT2ZmaWNlOiBNdW5pY2gKQ29tbWVyY2lhbCBSZWdpc3RlcjogQW10c2dlcmlj
aHQgTXVlbmNoZW4gSFJCIDE4NjkyOAo=
^ permalink raw reply
* Re: ath10k: fix core PCI suspend when WoWLAN is supported but disabled
From: Kalle Valo @ 2017-10-13 11:37 UTC (permalink / raw)
To: Brian Norris
Cc: ath10k, linux-wireless, Grant Grundler, linux-kernel,
Brian Norris, Ryan Hsu, Michal Kazior
In-Reply-To: <20170919232416.108247-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> For devices where the FW supports WoWLAN but user-space has not
> configured it, we don't do any PCI-specific suspend/resume operations,
> because mac80211 doesn't call drv_suspend() when !wowlan. This has
> particularly bad effects for some platforms, because we don't stop the
> power-save timer, and if this timer goes off after the PCI controller
> has suspended the link, Bad Things will happen.
>
> Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> got some of this right, in that it understood there was a problem on
> non-WoWLAN firmware. But it forgot the $subject case.
>
> Fix this by moving all the PCI driver suspend/resume logic exclusively
> into the driver PM hooks. This shouldn't affect WoWLAN support much
> (this just gets executed later on).
>
> I would just as well kill the entirety of ath10k_hif_suspend(), as it's
> not even implemented on the USB or SDIO drivers. I expect that we don't
> need the callback, except to return "supported" (i.e., 0) or "not
> supported" (i.e., -EOPNOTSUPP).
>
> Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Cc: Ryan Hsu <ryanhsu@qti.qualcomm.com>
> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
> Cc: Michal Kazior <michal.kazior@tieto.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
96378bd2c6cd ath10k: fix core PCI suspend when WoWLAN is supported but disabled
--
https://patchwork.kernel.org/patch/9960481/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: check power save support in STA mode through FW IE
From: Kalle Valo @ 2017-10-13 11:38 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <150670357817.24239.7065449335785410650.stgit@potku.adurom.net>
Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Currently ath10k host enables power save support in station mode by
> default for all firmwares but Power save for station mode still not supported
> in some of the firmware versions. Which results in firmware crash while
> issueing multiple scan commands.
>
> Fix this problem by introducing new FW feature flag to check power save
> support in firmware and then the firmware image can tell to ath10k that power
> save mode is not supported in station mode.
>
> Signed-off-by: Venkateswara Naralasetty <vnaralas@qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
36d9cdb6fb4a ath10k: check power save support in STA mode through FW IE
--
https://patchwork.kernel.org/patch/9978455/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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