* [PATCH] MAINTAINERS: update for mwifiex driver maintainers
From: Amitkumar Karwar @ 2017-02-28 13:24 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar, Xinming Hu,
Ganapathi Bhat
Ganapathi & Xinming are starting to take a more active role in the
mwifiex driver maintainership here onwards on account of organizational
changes.
CC: Xinming Hu <huxm@marvell.com>
CC: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d8f71f2..9252718 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7772,6 +7772,8 @@ F: drivers/net/ethernet/marvell/mvneta.*
MARVELL MWIFIEX WIRELESS DRIVER
M: Amitkumar Karwar <akarwar@marvell.com>
M: Nishant Sarmukadam <nishants@marvell.com>
+M: Ganapathi Bhat <gbhat@marvell.com>
+M: Xinming Hu <huxm@marvell.com>
L: linux-wireless@vger.kernel.org
S: Maintained
F: drivers/net/wireless/marvell/mwifiex/
--
1.9.1
^ permalink raw reply related
* [PATCH v1 1/2] NFC: pn544: Request GPIOs with proper connection IDs
From: Andy Shevchenko @ 2017-02-28 14:08 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
linux-wireless, Mika Westerberg
Cc: Andy Shevchenko
Since ACPI does support _DSD we might have a firmware that provides a
GPIO mapping in DSDT. When GPIO is requested the core will check for
property with given name. That's why we have to follow the standard
names which are already in use in DT case.
Request GPIOs with proper connection IDs, i.e. use same names as used
for DT case.
In the future ACPI and DT cases might be unified.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/nfc/pn544/i2c.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index f837c39a8017..2df3176205c4 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -881,8 +881,7 @@ static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
struct device *dev = &client->dev;
/* Get EN GPIO from ACPI */
- gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1,
- GPIOD_OUT_LOW);
+ gpiod_en = devm_gpiod_get_index(dev, "enable", 1, GPIOD_OUT_LOW);
if (IS_ERR(gpiod_en)) {
nfc_err(dev, "Unable to get EN GPIO\n");
return -ENODEV;
@@ -891,8 +890,7 @@ static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
phy->gpio_en = desc_to_gpio(gpiod_en);
/* Get FW GPIO from ACPI */
- gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2,
- GPIOD_OUT_LOW);
+ gpiod_fw = devm_gpiod_get_index(dev, "firmware", 2, GPIOD_OUT_LOW);
if (IS_ERR(gpiod_fw)) {
nfc_err(dev, "Unable to get FW GPIO\n");
return -ENODEV;
--
2.11.0
^ permalink raw reply related
* [PATCH v1 2/2] NFC: pn544: Add GPIO ACPI mapping table
From: Andy Shevchenko @ 2017-02-28 14:08 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
linux-wireless, Mika Westerberg
Cc: Andy Shevchenko
In-Reply-To: <20170228140809.84921-1-andriy.shevchenko@linux.intel.com>
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/nfc/pn544/i2c.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index 2df3176205c4..5364bbd5ce55 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -874,6 +874,15 @@ static void pn544_hci_i2c_fw_work(struct work_struct *work)
}
}
+static const struct acpi_gpio_params enable_gpios = { 1, 0, false };
+static const struct acpi_gpio_params firmware_gpios = { 2, 0, false };
+
+static const struct acpi_gpio_mapping acpi_pn544_default_gpios[] = {
+ { "enable-gpios", &enable_gpios, 1 },
+ { "firmware-gpios", &firmware_gpios, 1 },
+ { },
+};
+
static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
{
struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
@@ -982,6 +991,11 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
+ r = acpi_dev_add_driver_gpios(ACPI_COMPANION(&client->dev),
+ acpi_pn544_default_gpios);
+ if (r)
+ return r;
+
phy = devm_kzalloc(&client->dev, sizeof(struct pn544_i2c_phy),
GFP_KERNEL);
if (!phy)
@@ -1092,6 +1106,7 @@ static int pn544_hci_i2c_remove(struct i2c_client *client)
pdata->free_resources();
}
+ acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
return 0;
}
--
2.11.0
^ permalink raw reply related
* btqca Bluetooth: hci1: Frame reassembly failed
From: Дмитрий @ 2017-02-28 17:41 UTC (permalink / raw)
To: linux-wireless
Hello,
I have Dell Venue 11 Pro with "Dell Wireless 1538", which contains
Bluetooth chip AR3002.
In ACPI dsdt tables:
Device (BTH0)
{
Name (_HID, "DLAC3002" /* Qualcomm Atheros Bluetooth
UART Transport */) // _HID: Hardware ID
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
Zero,
Zero
})
Name (_S4W, 0x02) // _S4W: S4 Device Wake State
Name (_S0W, 0x02) // _S0W: S0 Device Wake State
Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings
{
Name (UBUF, ResourceTemplate ()
{
UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne,
0xFC, LittleEndian, ParityTypeNone,
FlowControlHardware,
0x0020, 0x0020, "\\_SB.URT1",
0x00, ResourceConsumer, ,
)
Interrupt (ResourceConsumer, Edge, ActiveHigh,
ExclusiveAndWake, ,, )
{
0x00000046,
}
GpioIo (Exclusive, PullDefault, 0x0000,
0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0034
}
GpioIo (Exclusive, PullDefault, 0x0000,
0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0035
}
})
Return (UBUF) /* \_SB_.URT1.BTH0._CRS.UBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
In logs: kernel: 80860F0A:00: ttyS1 at MMIO 0x9094d000 (irq = 191,
base_baud = 2764800) is a 16550A
btattach -B /dev/ttyS1 -P qca:
kernel: Bluetooth: hci1: ROME setup
kernel: Bluetooth: hci1: Set UART speed to 3000000
kernel: Bluetooth: hci1: Frame reassembly failed (-84)
kernel: Bluetooth: hci1 command 0xfc00 tx timeout
kernel: Bluetooth: hci1: Failed to read version of ROME (-110)
kernel: Bluetooth: hci1: Failed to get version 0xffffff92
But windows drivers state that 115200 baudrate must be used. Also only
qca driver protocol gives feedback from chip, all others show no RX
packets in hciconfig.
hci1: Type: Primary Bus: UART
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:4 acl:0 sco:0 events:0 errors:0
TX bytes:10 acl:0 sco:0 commands:2 errors:0
Is this speed choose bug or there is another unsupported part?
Tried switch GPIOs but with no luck, no difference.
Thanks for helping.
Sincerely,
Dmitry Derevyanko.
^ permalink raw reply
* ath9k driver : Support for Continuous Test Tone mode
From: Senthilganapathy Paramasivam @ 2017-02-28 20:02 UTC (permalink / raw)
To: linux-wireless
Hi ,
One of our wireless embedded product is operating on Linux Kernel : 3.12.19.
This product has a 802.11 a/b/g/n Full-size Mini PCIe Card
EWM-W158F01E Which is based on atheros AR9592-AR1B Chipset. ath9k
driver supports this chip set.
One of the compliance testing requirement is :
In the minimum transfer rate for power measurements, and at the
maximum rate for the other measurements, with the transmitter
operating with continuous transmission.
I am looking for the test mode support in ath9k driver and user space
utility to invoke the test mode.
1. Configuring the atheros 9k driver in CONFIG_ATH9K_TX99 test mode
https://github.com/torvalds/linux/commit/ef6b19e40f525777a0052956bf7d9a1985f74993
as per the log message the supported kernel is from 3.14-rc1
Latest Kernel 3.12.70 also does not have support for TX99 mode.
2. User space utility to send the continuous tone
Some of the references using a special tool called Atheros test tool
for the user space utility.
There is a reference to a windows based utility "Atheros Radio test tool".
Some documents refer to linux based atheros test tool but they are
based on wireless extensions.
Searching for a similar utility did not yield any results.
Any pointers are welcome.
Thanks
Senthil
^ permalink raw reply
* Re: WARNING: CPU: 1 PID: 23668 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450
From: Jens Axboe @ 2017-02-28 20:41 UTC (permalink / raw)
To: sara.sharon; +Cc: linux-wireless, luciano.coelho, liad.kaufman
In-Reply-To: <c60e6859-f1ec-6656-2625-b5ce5f18059a@kernel.dk>
On 02/28/2017 11:02 AM, Jens Axboe wrote:
> Hi,
>
> I'm hitting this one a lot with current -git, which is this one:
>
> if (iwl_mvm_is_dqa_supported(mvm)) {
> iwl_mvm_disable_sta_queues(mvm, vif, mvm_sta);
> /*
> * If pending_frames is set at this point - it must be
> * driver internal logic error, since queues are empty
> * and removed successuly.
> * warn on it but set it to 0 anyway to avoid station
> * not being removed later in the function
> */
> WARN_ON(atomic_xchg(&mvm->pending_frames[sta_id], 0));
> }
>
> It's hit 4 times over the last day. The bug is probably older than the
> commit that added this warning:
>
> commit 94c3e614df2117626fccfac8f821c66e30556384
> Author: Sara Sharon <sara.sharon@intel.com>
> Date: Wed Dec 7 15:04:37 2016 +0200
>
> iwlwifi: mvm: fix pending frame counter calculation
>
> but the pestering is new.
Forgot to include the traces, find them below.
[ 3829.774681] ------------[ cut here ]------------
[ 3829.774708] WARNING: CPU: 2 PID: 9155 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[ 3829.774710] Modules linked in: rfcomm fuse ctr ccm arc4 bnep snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device iwlmvm mac80211 binfmt_misc snd_timer iwlwifi uvcvideo x86_pkg_temp_thermal intel_powerclamp kvm_intel videobuf2_vmalloc kvm snd videobuf2_memops nls_iso8859_1 nls_cp437 irqbypass aesni_intel videobuf2_v4l2 aes_x86_64 videobuf2_core crypto_simd btusb vfat cryptd fat glue_helper videodev soundcore btintel cfg80211 bluetooth hid_generic usbhid hid psmouse i915 e1000e ptp pps_core xhci_pci xhci_hcd intel_gtt
[ 3829.774785] CPU: 2 PID: 9155 Comm: kworker/u8:0 Tainted: G U 4.10.0+ #17
[ 3829.774787] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET45W (1.19 ) 11/08/2016
[ 3829.774824] Workqueue: phy0 ieee80211_iface_work [mac80211]
[ 3829.774826] Call Trace:
[ 3829.774837] dump_stack+0x4d/0x63
[ 3829.774843] __warn+0xcb/0xf0
[ 3829.774849] warn_slowpath_null+0x1d/0x20
[ 3829.774864] iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[ 3829.774875] iwl_mvm_mac_sta_state+0x3fb/0x590 [iwlmvm]
[ 3829.774898] drv_sta_state+0x83/0x4b0 [mac80211]
[ 3829.774922] __sta_info_destroy_part2+0x128/0x160 [mac80211]
[ 3829.774945] __sta_info_flush+0xdb/0x180 [mac80211]
[ 3829.774979] ieee80211_set_disassoc+0xba/0x3c0 [mac80211]
[ 3829.775017] ieee80211_sta_connection_lost.constprop.23+0x2a/0x50 [mac80211]
[ 3829.775056] ieee80211_sta_work+0x1f3/0x1440 [mac80211]
[ 3829.775063] ? update_curr+0x76/0x190
[ 3829.775069] ? dequeue_task_fair+0x612/0x1830
[ 3829.775100] ieee80211_iface_work+0x332/0x430 [mac80211]
[ 3829.775104] ? finish_task_switch+0x78/0x200
[ 3829.775111] process_one_work+0x1f3/0x4a0
[ 3829.775116] worker_thread+0x48/0x4e0
[ 3829.775121] kthread+0x101/0x140
[ 3829.775125] ? process_one_work+0x4a0/0x4a0
[ 3829.775129] ? kthread_create_on_node+0x40/0x40
[ 3829.775135] ret_from_fork+0x29/0x40
[ 3829.775140] ---[ end trace 4da4612127066e04 ]---
[ 3829.780886] iwlwifi 0000:04:00.0: Failed to find station
[ 3829.780899] wlp4s0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-22)
[ 3829.780934] iwlwifi 0000:04:00.0: Failed to find station
[ 3829.780938] wlp4s0: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-22)
[ 3829.903700] wlp4s0: authenticate with b4:75:0e:99:1f:e0
[ 3829.911954] wlp4s0: send auth to b4:75:0e:99:1f:e0 (try 1/3)
[ 3829.924048] wlp4s0: authenticated
[ 3829.927968] wlp4s0: associate with b4:75:0e:99:1f:e0 (try 1/3)
[ 3829.932783] wlp4s0: RX AssocResp from b4:75:0e:99:1f:e0 (capab=0x11 status=0 aid=1)
[ 3829.933844] wlp4s0: associated
[...]
[15590.492927] wlp4s0: deauthenticating from e2:cc:f8:1a:52:be by local choice (Reason: 3=DEAUTH_LEAVING)
[15590.503419] ------------[ cut here ]------------
[15590.503429] WARNING: CPU: 1 PID: 1012 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[15590.503430] Modules linked in: iwlmvm iwlwifi rfcomm fuse ctr ccm arc4 bnep snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device mac80211 binfmt_misc snd_timer uvcvideo x86_pkg_temp_thermal intel_powerclamp kvm_intel videobuf2_vmalloc kvm snd videobuf2_memops nls_iso8859_1 nls_cp437 irqbypass aesni_intel videobuf2_v4l2 aes_x86_64 videobuf2_core crypto_simd btusb vfat cryptd fat glue_helper videodev soundcore btintel cfg80211 bluetooth hid_generic usbhid hid psmouse i915 e1000e ptp pps_core xhci_pci xhci_hcd intel_gtt [last unloaded: iwlwifi]
[15590.503458] CPU: 1 PID: 1012 Comm: wpa_supplicant Tainted: G U W 4.10.0+ #17
[15590.503459] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET45W (1.19 ) 11/08/2016
[15590.503460] Call Trace:
[15590.503464] dump_stack+0x4d/0x63
[15590.503466] __warn+0xcb/0xf0
[15590.503468] warn_slowpath_null+0x1d/0x20
[15590.503472] iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[15590.503475] iwl_mvm_mac_sta_state+0x3fb/0x590 [iwlmvm]
[15590.503490] drv_sta_state+0x83/0x4b0 [mac80211]
[15590.503496] __sta_info_destroy_part2+0x128/0x160 [mac80211]
[15590.503502] __sta_info_flush+0xdb/0x180 [mac80211]
[15590.503512] ieee80211_set_disassoc+0xba/0x3c0 [mac80211]
[15590.503521] ieee80211_mgd_deauth+0xfa/0x210 [mac80211]
[15590.503530] ieee80211_deauth+0x18/0x20 [mac80211]
[15590.503546] cfg80211_mlme_deauth+0xa0/0x1e0 [cfg80211]
[15590.503554] nl80211_deauthenticate+0x124/0x160 [cfg80211]
[15590.503556] genl_family_rcv_msg+0x1b5/0x360
[15590.503558] genl_rcv_msg+0x59/0xa0
[15590.503560] ? genl_register_family+0x630/0x630
[15590.503561] netlink_rcv_skb+0x97/0xb0
[15590.503563] genl_rcv+0x28/0x40
[15590.503564] netlink_unicast+0x181/0x210
[15590.503566] netlink_sendmsg+0x2d8/0x390
[15590.503567] sock_sendmsg+0x38/0x50
[15590.503568] ___sys_sendmsg+0x25f/0x270
[15590.503569] ? ___sys_recvmsg+0x141/0x1b0
[15590.503572] ? __set_current_blocked+0x55/0x60
[15590.503574] ? signal_setup_done+0x5c/0xa0
[15590.503575] ? do_signal+0x175/0x640
[15590.503577] ? __fpu__restore_sig+0x8c/0x4e0
[15590.503578] __sys_sendmsg+0x45/0x80
[15590.503580] SyS_sendmsg+0x12/0x20
[15590.503582] entry_SYSCALL_64_fastpath+0x13/0x94
[15590.503583] RIP: 0033:0x7f78c96308a0
[15590.503583] RSP: 002b:00007fff812ffe28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[15590.503585] RAX: ffffffffffffffda RBX: 0000556ff4800f90 RCX: 00007f78c96308a0
[15590.503585] RDX: 0000000000000000 RSI: 00007fff812ffeb0 RDI: 0000000000000007
[15590.503586] RBP: 0000556ff48014a0 R08: 0000000000000000 R09: 0000000000000000
[15590.503586] R10: 0000556ff483ee80 R11: 0000000000000246 R12: 0000000000000001
[15590.503587] R13: 00007fff813004d8 R14: 0000556ff48016f0 R15: 000000000000000b
[15590.503588] ---[ end trace 4da4612127066e06 ]---
[15590.508925] iwlwifi 0000:04:00.0: Failed to find station
[15590.508929] wlp4s0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-22)
[15590.508941] iwlwifi 0000:04:00.0: Failed to find station
[15590.508943] wlp4s0: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-22)
[...]
[15605.883212] wlp4s0: authenticate with b4:75:0e:99:1f:e0
[15605.891574] wlp4s0: send auth to b4:75:0e:99:1f:e0 (try 1/3)
[15605.897327] wlp4s0: authenticated
[15605.903406] wlp4s0: associate with b4:75:0e:99:1f:e0 (try 1/3)
[15605.904771] wlp4s0: RX AssocResp from b4:75:0e:99:1f:e0 (capab=0x11 status=0 aid=2)
[15605.905850] wlp4s0: associated
[15605.905895] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
[15632.617250] wlp4s0: disconnect from AP b4:75:0e:99:1f:e0 for new auth to b4:75:0e:99:1f:df
[15632.621364] ------------[ cut here ]------------
[15632.621377] WARNING: CPU: 0 PID: 1012 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[15632.621378] Modules linked in: iwlmvm iwlwifi rfcomm fuse ctr ccm arc4 bnep snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device mac80211 binfmt_misc snd_timer uvcvideo x86_pkg_temp_thermal intel_powerclamp kvm_intel videobuf2_vmalloc kvm snd videobuf2_memops nls_iso8859_1 nls_cp437 irqbypass aesni_intel videobuf2_v4l2 aes_x86_64 videobuf2_core crypto_simd btusb vfat cryptd fat glue_helper videodev soundcore btintel cfg80211 bluetooth hid_generic usbhid hid psmouse i915 e1000e ptp pps_core xhci_pci xhci_hcd intel_gtt [last unloaded: iwlwifi]
[15632.621417] CPU: 0 PID: 1012 Comm: wpa_supplicant Tainted: G U W 4.10.0+ #17
[15632.621418] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET45W (1.19 ) 11/08/2016
[15632.621419] Call Trace:
[15632.621424] dump_stack+0x4d/0x63
[15632.621427] __warn+0xcb/0xf0
[15632.621430] warn_slowpath_null+0x1d/0x20
[15632.621436] iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[15632.621442] iwl_mvm_mac_sta_state+0x3fb/0x590 [iwlmvm]
[15632.621455] drv_sta_state+0x83/0x4b0 [mac80211]
[15632.621468] __sta_info_destroy_part2+0x128/0x160 [mac80211]
[15632.621480] __sta_info_flush+0xdb/0x180 [mac80211]
[15632.621497] ieee80211_set_disassoc+0xba/0x3c0 [mac80211]
[15632.621512] ieee80211_mgd_auth+0x2f5/0x330 [mac80211]
[15632.621528] ieee80211_auth+0x18/0x20 [mac80211]
[15632.621544] cfg80211_mlme_auth+0xf3/0x210 [cfg80211]
[15632.621558] nl80211_authenticate+0x2e0/0x340 [cfg80211]
[15632.621562] genl_family_rcv_msg+0x1b5/0x360
[15632.621565] genl_rcv_msg+0x59/0xa0
[15632.621567] ? genl_register_family+0x630/0x630
[15632.621569] netlink_rcv_skb+0x97/0xb0
[15632.621572] genl_rcv+0x28/0x40
[15632.621574] netlink_unicast+0x181/0x210
[15632.621576] netlink_sendmsg+0x2d8/0x390
[15632.621579] sock_sendmsg+0x38/0x50
[15632.621581] ___sys_sendmsg+0x25f/0x270
[15632.621582] ? ___sys_recvmsg+0x141/0x1b0
[15632.621585] ? iput+0x1c5/0x240
[15632.621587] ? dentry_free+0x4e/0x80
[15632.621589] ? mntput_no_expire+0x2c/0x1b0
[15632.621590] ? mntput+0x24/0x40
[15632.621592] ? __fput+0x174/0x1e0
[15632.621594] __sys_sendmsg+0x45/0x80
[15632.621597] SyS_sendmsg+0x12/0x20
[15632.621600] entry_SYSCALL_64_fastpath+0x13/0x94
[15632.621601] RIP: 0033:0x7f78c96308a0
[15632.621602] RSP: 002b:00007fff813000f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[15632.621604] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007f78c96308a0
[15632.621606] RDX: 0000000000000000 RSI: 00007fff81300180 RDI: 0000000000000007
[15632.621606] RBP: 0000556ff484221c R08: 0000000000000000 R09: 00000000000000df
[15632.621607] R10: 0000556ff4811de0 R11: 0000000000000246 R12: 0000556ff484221c
[15632.621608] R13: 0000556ff4857490 R14: 0000000000000000 R15: 0000000000000000
[15632.621610] ---[ end trace 4da4612127066e07 ]---
[15632.627578] wlp4s0: authenticate with b4:75:0e:99:1f:df
[15632.636345] wlp4s0: send auth to b4:75:0e:99:1f:df (try 1/3)
[15632.650504] wlp4s0: authenticated
[15632.655376] wlp4s0: associate with b4:75:0e:99:1f:df (try 1/3)
[15632.660036] wlp4s0: RX AssocResp from b4:75:0e:99:1f:df (capab=0x1411 status=0 aid=1)
[15632.675702] wlp4s0: associated
[15759.464681] ------------[ cut here ]------------
[15759.464718] WARNING: CPU: 1 PID: 23668 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[15759.464720] Modules linked in: iwlmvm iwlwifi rfcomm fuse ctr ccm arc4 bnep snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device mac80211 binfmt_misc snd_timer uvcvideo x86_pkg_temp_thermal intel_powerclamp kvm_intel videobuf2_vmalloc kvm snd videobuf2_memops nls_iso8859_1 nls_cp437 irqbypass aesni_intel videobuf2_v4l2 aes_x86_64 videobuf2_core crypto_simd btusb vfat cryptd fat glue_helper videodev soundcore btintel cfg80211 bluetooth hid_generic usbhid hid psmouse i915 e1000e ptp pps_core xhci_pci xhci_hcd intel_gtt [last unloaded: iwlwifi]
[15759.464819] CPU: 1 PID: 23668 Comm: kworker/u8:4 Tainted: G U W 4.10.0+ #17
[15759.464822] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET45W (1.19 ) 11/08/2016
[15759.464871] Workqueue: phy1 ieee80211_iface_work [mac80211]
[15759.464875] Call Trace:
[15759.464889] dump_stack+0x4d/0x63
[15759.464897] __warn+0xcb/0xf0
[15759.464904] warn_slowpath_null+0x1d/0x20
[15759.464925] iwl_mvm_rm_sta+0x3ce/0x450 [iwlmvm]
[15759.464939] iwl_mvm_mac_sta_state+0x3fb/0x590 [iwlmvm]
[15759.464971] drv_sta_state+0x83/0x4b0 [mac80211]
[15759.465002] __sta_info_destroy_part2+0x128/0x160 [mac80211]
[15759.465033] __sta_info_flush+0xdb/0x180 [mac80211]
[15759.465079] ieee80211_set_disassoc+0xba/0x3c0 [mac80211]
[15759.465121] ieee80211_sta_connection_lost.constprop.23+0x2a/0x50 [mac80211]
[15759.465161] ieee80211_sta_work+0x1f3/0x1440 [mac80211]
[15759.465168] ? update_curr+0x76/0x190
[15759.465173] ? dequeue_task_fair+0x612/0x1830
[15759.465212] ieee80211_iface_work+0x332/0x430 [mac80211]
[15759.465218] ? finish_task_switch+0x78/0x200
[15759.465227] process_one_work+0x1f3/0x4a0
[15759.465234] worker_thread+0x48/0x4e0
[15759.465240] kthread+0x101/0x140
[15759.465247] ? process_one_work+0x4a0/0x4a0
[15759.465252] ? kthread_create_on_node+0x40/0x40
[15759.465260] ret_from_fork+0x29/0x40
[15759.465267] ---[ end trace 4da4612127066e08 ]---
[15759.473252] iwlwifi 0000:04:00.0: Failed to find station
[15759.473267] wlp4s0: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-22)
[15759.596780] wlp4s0: authenticate with b4:75:0e:99:1f:e0
[15759.605604] wlp4s0: send auth to b4:75:0e:99:1f:e0 (try 1/3)
[15759.607833] wlp4s0: authenticated
[15759.617745] wlp4s0: associate with b4:75:0e:99:1f:e0 (try 1/3)
[15759.619111] wlp4s0: RX AssocResp from b4:75:0e:99:1f:e0 (capab=0x11 status=0 aid=2)
[15759.620061] wlp4s0: associated
--
Jens Axboe
^ permalink raw reply
* WARNING: CPU: 1 PID: 23668 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450
From: Jens Axboe @ 2017-02-28 18:02 UTC (permalink / raw)
To: sara.sharon; +Cc: linux-wireless, luciano.coelho, liad.kaufman
Hi,
I'm hitting this one a lot with current -git, which is this one:
if (iwl_mvm_is_dqa_supported(mvm)) {
iwl_mvm_disable_sta_queues(mvm, vif, mvm_sta);
/*
* If pending_frames is set at this point - it must be
* driver internal logic error, since queues are empty
* and removed successuly.
* warn on it but set it to 0 anyway to avoid station
* not being removed later in the function
*/
WARN_ON(atomic_xchg(&mvm->pending_frames[sta_id], 0));
}
It's hit 4 times over the last day. The bug is probably older than the
commit that added this warning:
commit 94c3e614df2117626fccfac8f821c66e30556384
Author: Sara Sharon <sara.sharon@intel.com>
Date: Wed Dec 7 15:04:37 2016 +0200
iwlwifi: mvm: fix pending frame counter calculation
but the pestering is new.
--
Jens Axboe
^ permalink raw reply
* [PATCH v2] mac80211: mesh - always do every discovery retry
From: Alexis Green @ 2017-02-28 23:50 UTC (permalink / raw)
To: linux-wireless
Changes since v1: Make this behavior optional and configurable via
netlink.
Instead of stopping path discovery when a path is found continue
attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
limit.
This is important because path messages are not reliable and it is
relatively common to have a short bad path to the destination along with a
longer but better path. With the original code rather often a path message
along the long path would be lost so we would stick with the bad path.
With this change we have a greater chance to get messages over the longer
path allowing us to select the long path if it's better.
The standard doesn't seem to address this issue. All it says (13.10.8.5)
is that discovery should be limited to dot11MeshHWMPmaxPREQretries.
Signed-off-by: Alexis Green <agreen@uniumwifi.com>
---
include/net/cfg80211.h | 3 ++
include/uapi/linux/nl80211.h | 3 ++
net/mac80211/cfg.c | 2 ++
net/mac80211/debugfs_netdev.c | 3 ++
net/mac80211/mesh_hwmp.c | 65 +++++++++++++++++++++++++++++--------------
net/wireless/mesh.c | 1 +
net/wireless/nl80211.c | 8 +++++-
net/wireless/trace.h | 5 +++-
8 files changed, 67 insertions(+), 23 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 86c12f8..fb32abf 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1382,6 +1382,8 @@ struct bss_parameters {
* @plink_timeout: If no tx activity is seen from a STA we've established
* peering with for longer than this time (in seconds), then remove it
* from the STA's list of peers. Default is 30 minutes.
+ * @always_max_discoveries: whether to always perform number of discovery
+ * attemts equal to dot11MeshHWMPmaxPREQretries
*/
struct mesh_config {
u16 dot11MeshRetryTimeout;
@@ -1412,6 +1414,7 @@ struct mesh_config {
enum nl80211_mesh_power_mode power_mode;
u16 dot11MeshAwakeWindowDuration;
u32 plink_timeout;
+ bool always_max_discoveries;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 9a499b1..58f8f0c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3449,6 +3449,8 @@ enum nl80211_mesh_power_mode {
* established peering with for longer than this time (in seconds), then
* remove it from the STA's list of peers. You may set this to 0 to disable
* the removal of the STA. Default is 30 minutes.
+ * @NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES: whether to always perform
+ * number of discovery attempts equal to MaxPREQretries (default is FALSE)
*
* @__NL80211_MESHCONF_ATTR_AFTER_LAST: internal use
*/
@@ -3482,6 +3484,7 @@ enum nl80211_meshconf_params {
NL80211_MESHCONF_POWER_MODE,
NL80211_MESHCONF_AWAKE_WINDOW,
NL80211_MESHCONF_PLINK_TIMEOUT,
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
/* keep last */
__NL80211_MESHCONF_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 9c7490c..9581873 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1956,6 +1956,8 @@ static int ieee80211_update_mesh_config(struct wiphy *wiphy,
nconf->dot11MeshAwakeWindowDuration;
if (_chg_mesh_attr(NL80211_MESHCONF_PLINK_TIMEOUT, mask))
conf->plink_timeout = nconf->plink_timeout;
+ if (_chg_mesh_attr(NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES, mask))
+ conf->always_max_discoveries = nconf->always_max_discoveries;
ieee80211_mbss_info_change_notify(sdata, BSS_CHANGED_BEACON);
return 0;
}
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 8f5fff8..ceec6e8 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -642,6 +642,8 @@ IEEE80211_IF_FILE(dot11MeshHWMPconfirmationInterval,
IEEE80211_IF_FILE(power_mode, u.mesh.mshcfg.power_mode, DEC);
IEEE80211_IF_FILE(dot11MeshAwakeWindowDuration,
u.mesh.mshcfg.dot11MeshAwakeWindowDuration, DEC);
+IEEE80211_IF_FILE(always_max_discoveries,
+ u.mesh.mshcfg.always_max_discoveries, DEC);
#endif
#define DEBUGFS_ADD_MODE(name, mode) \
@@ -763,6 +765,7 @@ static void add_mesh_config(struct ieee80211_sub_if_data *sdata)
MESHPARAMS_ADD(dot11MeshHWMPconfirmationInterval);
MESHPARAMS_ADD(power_mode);
MESHPARAMS_ADD(dot11MeshAwakeWindowDuration);
+ MESHPARAMS_ADD(always_max_discoveries);
#undef MESHPARAMS_ADD
}
#endif
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index d07ee3c..7c019f9 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1198,34 +1198,57 @@ void mesh_path_timer(unsigned long data)
{
struct mesh_path *mpath = (void *) data;
struct ieee80211_sub_if_data *sdata = mpath->sdata;
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ bool multiple_discoveries = ifmsh->mshcfg.always_max_discoveries;
int ret;
if (sdata->local->quiescing)
return;
spin_lock_bh(&mpath->state_lock);
- if (mpath->flags & MESH_PATH_RESOLVED ||
- (!(mpath->flags & MESH_PATH_RESOLVING))) {
- mpath->flags &= ~(MESH_PATH_RESOLVING | MESH_PATH_RESOLVED);
- spin_unlock_bh(&mpath->state_lock);
- } else if (mpath->discovery_retries < max_preq_retries(sdata)) {
- ++mpath->discovery_retries;
- mpath->discovery_timeout *= 2;
- mpath->flags &= ~MESH_PATH_REQ_QUEUED;
- spin_unlock_bh(&mpath->state_lock);
- mesh_queue_preq(mpath, 0);
+ if (!multiple_discoveries) {
+ if (mpath->flags & MESH_PATH_RESOLVED ||
+ (!(mpath->flags & MESH_PATH_RESOLVING))) {
+ mpath->flags &= ~(MESH_PATH_RESOLVING |
+ MESH_PATH_RESOLVED);
+ spin_unlock_bh(&mpath->state_lock);
+ return;
+ } else if (mpath->discovery_retries < max_preq_retries(sdata)) {
+ ++mpath->discovery_retries;
+ mpath->discovery_timeout *= 2;
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
+ spin_unlock_bh(&mpath->state_lock);
+ mesh_queue_preq(mpath, 0);
+ return;
+ }
} else {
- mpath->flags &= ~(MESH_PATH_RESOLVING |
- MESH_PATH_RESOLVED |
- MESH_PATH_REQ_QUEUED);
- mpath->exp_time = jiffies;
- spin_unlock_bh(&mpath->state_lock);
- if (!mpath->is_gate && mesh_gate_num(sdata) > 0) {
- ret = mesh_path_send_to_gates(mpath);
- if (ret)
- mhwmp_dbg(sdata, "no gate was reachable\n");
- } else
- mesh_path_flush_pending(mpath);
+ if (mpath->discovery_retries < max_preq_retries(sdata)) {
+ ++mpath->discovery_retries;
+ mpath->discovery_timeout *= 2;
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
+ spin_unlock_bh(&mpath->state_lock);
+ mesh_queue_preq(mpath, 0);
+ return;
+ } else if (mpath->flags & MESH_PATH_RESOLVED ||
+ (!(mpath->flags & MESH_PATH_RESOLVING))) {
+ mpath->flags &= ~(MESH_PATH_RESOLVING |
+ MESH_PATH_RESOLVED);
+ spin_unlock_bh(&mpath->state_lock);
+ return;
+ }
+ }
+
+ mpath->flags &= ~(MESH_PATH_RESOLVING |
+ MESH_PATH_RESOLVED |
+ MESH_PATH_REQ_QUEUED);
+ mpath->exp_time = jiffies;
+ spin_unlock_bh(&mpath->state_lock);
+ if (!mpath->is_gate && mesh_gate_num(sdata) > 0) {
+ ret = mesh_path_send_to_gates(mpath);
+ if (ret)
+ mhwmp_dbg(sdata, "no gate was reachable\n");
+ } else {
+ mesh_path_flush_pending(mpath);
}
}
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index 2d8518a..f82fcd3 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -77,6 +77,7 @@ const struct mesh_config default_mesh_config = {
.power_mode = NL80211_MESH_POWER_ACTIVE,
.dot11MeshAwakeWindowDuration = MESH_DEFAULT_AWAKE_WINDOW,
.plink_timeout = MESH_DEFAULT_PLINK_TIMEOUT,
+ .always_max_discoveries = false,
};
const struct mesh_setup default_mesh_setup = {
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d516527..6e1181d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5729,7 +5729,9 @@ static int nl80211_get_mesh_config(struct sk_buff *skb,
nla_put_u16(msg, NL80211_MESHCONF_AWAKE_WINDOW,
cur_params.dot11MeshAwakeWindowDuration) ||
nla_put_u32(msg, NL80211_MESHCONF_PLINK_TIMEOUT,
- cur_params.plink_timeout))
+ cur_params.plink_timeout) ||
+ nla_put_u8(msg, NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
+ cur_params.always_max_discoveries))
goto nla_put_failure;
nla_nest_end(msg, pinfoattr);
genlmsg_end(msg, hdr);
@@ -5771,6 +5773,7 @@ static const struct nla_policy nl80211_meshconf_params_policy[NL80211_MESHCONF_A
[NL80211_MESHCONF_POWER_MODE] = { .type = NLA_U32 },
[NL80211_MESHCONF_AWAKE_WINDOW] = { .type = NLA_U16 },
[NL80211_MESHCONF_PLINK_TIMEOUT] = { .type = NLA_U32 },
+ [NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES] = { .type = NLA_U8 },
};
static const struct nla_policy
@@ -5995,6 +5998,9 @@ do { \
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 0, 0xffffffff,
mask, NL80211_MESHCONF_PLINK_TIMEOUT,
nl80211_check_u32);
+ FILL_IN_MESH_PARAM_IF_SET(tb, cfg, always_max_discoveries, 0, 1, mask,
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
+ nl80211_check_bool);
if (mask_out)
*mask_out = mask;
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index fd55786..cc4a966 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -67,7 +67,8 @@
__field(u16, ht_opmode) \
__field(u32, dot11MeshHWMPactivePathToRootTimeout) \
__field(u16, dot11MeshHWMProotInterval) \
- __field(u16, dot11MeshHWMPconfirmationInterval)
+ __field(u16, dot11MeshHWMPconfirmationInterval) \
+ __field(bool, always_max_discoveries)
#define MESH_CFG_ASSIGN \
do { \
__entry->dot11MeshRetryTimeout = conf->dot11MeshRetryTimeout; \
@@ -108,6 +109,8 @@
conf->dot11MeshHWMProotInterval; \
__entry->dot11MeshHWMPconfirmationInterval = \
conf->dot11MeshHWMPconfirmationInterval; \
+ __entry->always_max_discoveries = \
+ conf->always_max_discoveries; \
} while (0)
#define CHAN_ENTRY __field(enum nl80211_band, band) \
^ permalink raw reply related
* [PATCH] iw: Add support for NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES netlink attribute
From: Alexis Green @ 2017-02-28 23:50 UTC (permalink / raw)
To: linux-wireless
This attributes allows configuring mesh to either do only minimum
number of discovery attempts (up to MaxPREretries) or always do
MaxPREretries number of tries even when getting responses.
Signed-off-by: Alexis Green <agreen@uniumwifi.com>
---
mesh.c | 3 +++
nl80211.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/mesh.c b/mesh.c
index 97f236b..b828408 100644
--- a/mesh.c
+++ b/mesh.c
@@ -264,6 +264,9 @@ const static struct mesh_param_descr _mesh_param_descrs[] =
_my_nla_put_u16, _parse_u16, _print_u16_in_TUs},
{"mesh_plink_timeout", NL80211_MESHCONF_PLINK_TIMEOUT,
_my_nla_put_u32, _parse_u32, _print_u32_in_seconds},
+ {"mesh_hwmp_always_max_discoveries",
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
+ _my_nla_put_u8, _parse_u8_as_bool, _print_u8},
};
static void print_all_mesh_param_descr(void)
diff --git a/nl80211.h b/nl80211.h
index 56368e9..bb53e8b 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -3352,6 +3352,8 @@ enum nl80211_mesh_power_mode {
* established peering with for longer than this time (in seconds), then
* remove it from the STA's list of peers. You may set this to 0 to disable
* the removal of the STA. Default is 30 minutes.
+ * @NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES: whether to always perform
+ * number of discovery attempts equal to MaxPREQretries (default is FALSE)
*
* @__NL80211_MESHCONF_ATTR_AFTER_LAST: internal use
*/
@@ -3385,6 +3387,7 @@ enum nl80211_meshconf_params {
NL80211_MESHCONF_POWER_MODE,
NL80211_MESHCONF_AWAKE_WINDOW,
NL80211_MESHCONF_PLINK_TIMEOUT,
+ NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
/* keep last */
__NL80211_MESHCONF_ATTR_AFTER_LAST,
--
2.5.0.rc3
^ permalink raw reply related
* Re: [RFC 0/5] iwlwifi: enhance final opmode work
From: Johannes Berg @ 2017-03-01 7:12 UTC (permalink / raw)
To: Luis R. Rodriguez, luciano.coelho, emmanuel.grumbach, tj, arjan,
ming.lei, zajec5
Cc: jeyu, rusty, pmladek, gregkh, linuxwifi, linux-wireless,
linux-kernel
In-Reply-To: <20170217020903.6370-1-mcgrof@kernel.org>
> One of the limitations of using async_schedule() though is we cannot
> request_module() synchronously on async calls given that the module
> initialization code will call async_synchronize_full() if the module
> being initialized happened to have used async work on its
> initialization routine, otherwise we'd deadlock.
>
> So, I either I change back to workqueus or we live happy with either:
I really think you should avoid breaking this API and change back.
Drivers have been using it, how to avoid the use-after-free with a
completion is well known, and there's generally no issue.
Making things "easier" while requiring lots of churn everywhere isn't
always a good thing.
If you end up introducing some new API then perhaps that new API would
make sense to use async_schedule(), but I don't really see all that
much point in changing all of this now.
johannes
^ permalink raw reply
* Re: ath9k driver : Support for Continuous Test Tone mode
From: Julien Massot @ 2017-03-01 9:03 UTC (permalink / raw)
To: Senthilganapathy Paramasivam; +Cc: linux-wireless
In-Reply-To: <CAPK922czwT9jmpkn0xXGJxwL74hzsKWjxkYEhZf15v2oHKPV3g@mail.gmail.com>
Hi Senthil,
On Tue, Feb 28, 2017 at 9:02 PM, Senthilganapathy Paramasivam
<senthilgp2020@gmail.com> wrote:
>
> Hi ,
> One of our wireless embedded product is operating on Linux Kernel : 3.12.=
19.
>
> This product has a 802.11 a/b/g/n Full-size Mini PCIe Card
> EWM-W158F01E Which is based on atheros AR9592-AR1B Chipset. ath9k
> driver supports this chip set.
>
> One of the compliance testing requirement is :
> In the minimum transfer rate for power measurements, and at the
> maximum rate for the other measurements, with the transmitter
> operating with continuous transmission.
>
> I am looking for the test mode support in ath9k driver and user space
> utility to invoke the test mode.
>
> 1. Configuring the atheros 9k driver in CONFIG_ATH9K_TX99 test mode
> https://github.com/torvalds/linux/commit/ef6b19e40f525777a0052956bf7d9a19=
85f74993
> as per the log message the supported kernel is from 3.14-rc1
> Latest Kernel 3.12.70 also does not have support for TX99 mode.
You may want to try backport driver
https://backports.wiki.kernel.org/index.php/Main_Page
>
>
> 2. User space utility to send the continuous tone
> Some of the references using a special tool called Atheros test tool
> for the user space utility.
> There is a reference to a windows based utility "Atheros Radio test too=
l".
> Some documents refer to linux based atheros test tool but they are
> based on wireless extensions.
> Searching for a similar utility did not yield any results.
Please take a look at this commit message
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
=3D89f927af7f3389e20c8ad24abfb3d1369f3ffc10
I tested it successfully using an AR9462 adapter and a kernel 4.0.
>From what I understood from tx99_power parameter
doing;
echo 10 > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99_power
will set the tx power to 5 dBm
Please try this shell script:
http://pastebin.com/ANZwVmbp
./test-wifi.sh 1 HT40+
First arg is the channel number,second one is the HT mode.
This script set the txpower to 20dBm.
I'm almost sure that there is a version of ART for Linux somewhere but you
may need to sign NDA, or special licence with QCA.
Best Regards,
Julien
--=20
*This email and any attachment thereto are confidential and intended solely=
=20
for the use of the individual or entity to whom they are addressed.If you=
=20
are not the intended recipient, please be advised that disclosing, copying,=
=20
distributing or taking any action in reliance on the contents of this email=
=20
is strictly prohibited. In such case, please immediately advise the sender,=
=20
and delete all copies and attachment from your system.This email shall not=
=20
be construed and is not tantamount to an offer, an acceptance of offer, or=
=20
an agreement by SoftBank Robotics Europe on any discussion or contractual=
=20
document whatsoever. No employee or agent is authorized to represent or=20
bind SoftBank Robotics Europe to third parties by email, or act on behalf=
=20
of SoftBank Robotics Europe by email, without express written confirmation=
=20
by SoftBank Robotics Europe=E2=80=99 duly authorized representatives.*
------------------------------
*Ce message =C3=A9lectronique et =C3=A9ventuelles pi=C3=A8ces jointes sont =
confidentiels,=20
et exclusivement destin=C3=A9s =C3=A0 la personne ou l'entit=C3=A9 =C3=A0 q=
ui ils sont=20
adress=C3=A9s.Si vous n'=C3=AAtes pas le destinataire vis=C3=A9, vous =C3=
=AAtes pri=C3=A9 de ne pas=20
divulguer, copier, distribuer ou prendre toute d=C3=A9cision sur la foi de =
ce=20
message =C3=A9lectronique. Merci d'en aviser imm=C3=A9diatement l'exp=C3=A9=
diteur et de=20
supprimer toutes les copies et =C3=A9ventuelles pi=C3=A8ces jointes de votr=
e=20
syst=C3=A8me.Ce message =C3=A9lectronique n'=C3=A9quivaut pas =C3=A0 une of=
fre, =C3=A0 une=20
acceptation d=E2=80=99offre, ou =C3=A0 un accord de SoftBank Robotics Europ=
e sur toute=20
discussion ou document contractuel quel qu=E2=80=99il soit, et ne peut =C3=
=AAtre=20
interpr=C3=A9t=C3=A9 comme tel. Aucun employ=C3=A9 ou agent de SoftBank Rob=
otics Europe=20
n'est autoris=C3=A9 =C3=A0 repr=C3=A9senter ou =C3=A0 engager la soci=C3=A9=
t=C3=A9 par email, ou =C3=A0 agir=20
au nom et pour le compte de la soci=C3=A9t=C3=A9 par email, sans qu=E2=80=
=99une confirmation=20
=C3=A9crite soit donn=C3=A9e par le repr=C3=A9sentant l=C3=A9gal de SoftBan=
k Robotics Europe ou=20
par toute autre personne ayant re=C3=A7u d=C3=A9l=C3=A9gation de pouvoir ap=
propri=C3=A9e.*
^ permalink raw reply
* FILS offloading
From: Arend Van Spriel @ 2017-03-01 10:28 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, Gery Kahn, Jouni Malinen
Hoi Jouni,
Not sure which email address to use ;-) I noticed a while ago that FILS
offloading was on the agenda of wireless workshop in Santa Fe. Recently,
looked at the FILS patches that were applied upstream and noticed:
static bool nl80211_valid_auth_type(struct cfg80211_registered_device *rdev,
enum nl80211_auth_type auth_type,
enum nl80211_commands cmd)
{
...
switch (cmd) {
...
case NL80211_CMD_CONNECT:
case NL80211_CMD_START_AP:
/* SAE not supported yet */
if (auth_type == NL80211_AUTHTYPE_SAE)
return false;
/* FILS not supported yet */
if (auth_type == NL80211_AUTHTYPE_FILS_SK ||
auth_type == NL80211_AUTHTYPE_FILS_SK_PFS ||
auth_type == NL80211_AUTHTYPE_FILS_PK)
return false;
return true;
default:
return false;
}
}
Are there any plans on QCA side to add FILS support for fullmac devices,
ie. supporting CONNECT command.
Regards,
Arend
^ permalink raw reply
* Deleting old wireless-testing tags
From: Bob Copeland @ 2017-03-01 14:14 UTC (permalink / raw)
To: linux-wireless
Hi all,
wireless-testing will resume again next week when the merge window opens,
and with 203 w-t tags since I started maintaining it a little over a year
ago, it's about time for some house-keeping. I plan to delete some of the
older tags in the kernel.org copy.
Before I do so, quick straw poll of anyone using this kernel: are there
specific tags I should keep, or any specific time period I should keep them
around?
E.g. I believe lede/openwrt are using compat-wireless builds generated from
wireless-testing; it might be worth retaining those particular tags just for
reference. I guess a few folks may be using it as a development tree and
would want a couple of kernel release cycles maintained, and so on.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: FILS offloading
From: Malinen, Jouni @ 2017-03-01 14:30 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Gery Kahn, Jouni Malinen
In-Reply-To: <d4fb8ca8-9632-3154-488e-5d7232601ed6@broadcom.com>
On Wed, Mar 01, 2017 at 11:28:48AM +0100, Arend Van Spriel wrote:
> Not sure which email address to use ;-) I noticed a while ago that FILS
> offloading was on the agenda of wireless workshop in Santa Fe. Recently,
> looked at the FILS patches that were applied upstream and noticed:
> static bool nl80211_valid_auth_type(struct cfg80211_registered_device *rd=
ev,
> case NL80211_CMD_CONNECT:
> case NL80211_CMD_START_AP:
> /* FILS not supported yet */
..
> Are there any plans on QCA side to add FILS support for fullmac devices,
> ie. supporting CONNECT command.
We do indeed have a patch going through internal review for this (well,
for the station part NL80211_CMD_CONNECT, not _START_AP). I hope to get
that posted shortly for public review.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Benjamin Beichler @ 2017-03-01 14:33 UTC (permalink / raw)
To: Ben Greear, Andrew Zaborowski; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4549b209-df6c-0eaa-65e6-72562c61bf4b@candelatech.com>
> You can specify the MAC address and name (ie, wiphy0) when creating a
> hwsim radio.
> You cannot specify the index. So, from a user-space perspective,
> I think the name and MAC is more important than the index.
>
That is actually not possible. The permanent MAC-Addresses of hwsim
radios are directly created by there internal ID, which is only
increased for new radios and definitely not reassigned.
But I would be happy, if this were possible, since it would make some
simulation related stuff easier (currently we need to unload and load
the hwsim module over and over again for every run).
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: Benjamin.Beichler@uni-rostock.de
www: http://www.imd.uni-rostock.de/
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Ben Greear @ 2017-03-01 15:35 UTC (permalink / raw)
To: Benjamin Beichler, Andrew Zaborowski; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4efcd470-86ee-2f3d-bbe2-1d82874edffd@uni-rostock.de>
On 03/01/2017 06:33 AM, Benjamin Beichler wrote:
>> You can specify the MAC address and name (ie, wiphy0) when creating a
>> hwsim radio.
>> You cannot specify the index. So, from a user-space perspective,
>> I think the name and MAC is more important than the index.
>>
> That is actually not possible. The permanent MAC-Addresses of hwsim
> radios are directly created by there internal ID, which is only
> increased for new radios and definitely not reassigned.
>
> But I would be happy, if this were possible, since it would make some
> simulation related stuff easier (currently we need to unload and load
> the hwsim module over and over again for every run).
Ahh, you are right. But you can specify the wiphy name, and then you
can use that to query the debugfs to find the MAC addr, and then sync
your user-space with that info.
It should also be easy enough to specify the MAC address when creating
the radio.
And, you should be able to create virtual STA, AP, etc, with any specified
MAC address, so the MAC of the radio really should not matter much?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Benjamin Beichler @ 2017-03-01 17:04 UTC (permalink / raw)
To: Ben Greear, Andrew Zaborowski; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4d3505b9-9714-8ad0-5159-794cb566dc3b@candelatech.com>
Am 01.03.2017 um 16:35 schrieb Ben Greear:
> That is actually not possible. The permanent MAC-Addresses of hwsim
>
>> radios are directly created by there internal ID, which is only
>> increased for new radios and definitely not reassigned.
>>
>> But I would be happy, if this were possible, since it would make some
>> simulation related stuff easier (currently we need to unload and load
>> the hwsim module over and over again for every run).
>
> Ahh, you are right. But you can specify the wiphy name, and then you
> can use that to query the debugfs to find the MAC addr, and then sync
> your user-space with that info.
>
> It should also be easy enough to specify the MAC address when creating
> the radio.
>
> And, you should be able to create virtual STA, AP, etc, with any
> specified
> MAC address, so the MAC of the radio really should not matter much?
>
That is another problem ... this won't work currently, since the frame
delivery compares the receiver address with the permanent MAC addresses
of all hwsim phys. I work as an idle task on patch, which makes this
lookup (currently implemented as linear search) as a hashmap mapping an
MAC to a wiphy struct , including scenarios with differing MAC addresses
of vifs.
> Thanks,
> Ben
>
kind regards
Benjamin
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: Benjamin.Beichler@uni-rostock.de
www: http://www.imd.uni-rostock.de/
^ permalink raw reply
* Re: [PATCH v3] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Seth Forshee @ 2017-03-01 14:59 UTC (permalink / raw)
To: Ryan Mounce; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <20170225031027.7871-1-ryan@mounce.com.au>
On Sat, Feb 25, 2017 at 01:40:27PM +1030, Ryan Mounce wrote:
> Sourced from the current legislation at
> https://www.legislation.gov.au/Details/F2016C00432
>
> The current rules exceed legal limits between 5250-5330MHz, and permit
> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
>
> Frequency ranges and EIRP limits for all ranges have been updated to
> match items 59-63, 65 in the linked document. As the rules for AU have
> never previously mirrored local regulations, changes include a
> significant increase in the allowable 2.4GHz EIRP and smaller increases
> in most other bands.
>
> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> bands) the lower, more restrictive band has been rounded up by 5MHz.
>
> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
This looks good to me. I'll give it a few more days to see if anyone
else has comments.
Thanks,
Seth
^ permalink raw reply
* [mwifiex] seemingly random crashes on 8897
From: Martin Pietryka @ 2017-03-01 19:15 UTC (permalink / raw)
To: linux-wireless, akarwar
Hi all,
we are running a 4.1 kernel and we have some instabilities using the
8897 over PCIe on an imx7 cpu.
We have observed crashes which look like the logs at the end. I'm not
sure if they are all somehow related.
As already mentioned we are using the 4.1 kernel from NXP with some
patches for the mwifiex driver backported from a more recent kernel,
these additional patches are the following:
* mwifiex: enable MSI interrupt support in pcie
* mwifiex: using right tid for addressing ra_list
* mwifiex: do not short circuit exit from mwifiex_set_mgmt_ies
I know that in the a more recent drivers there were some changes to the
interrupt handling, etc. So maybe there is an issue here. Especially
with MSI enabled.
Anybody got an idea?
Best regards,
Martin
Sometimes we see lots of these messages, WiFi continues to work:
[ 4108.037449] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4108.398976] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4119.549181] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4119.899053] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4193.769062] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4194.141753] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4413.821362] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4414.491489] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4490.359042] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4490.705755] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4587.521240] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4587.877673] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
[ 4601.168747] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
[ 4601.680754] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
One of the crashes
[ 123.004165] mwifiex_pcie 0000:01:00.0: mwifiex_cmd_timeout_func:
Timeout cmd id = 0x10, act = 0x1
[ 123.013072] mwifiex_pcie 0000:01:00.0: num_data_h2c_failure = 0
[ 123.019026] mwifiex_pcie 0000:01:00.0: num_cmd_h2c_failure = 0
[ 123.024886] mwifiex_pcie 0000:01:00.0: is_cmd_timedout = 1
[ 123.030378] mwifiex_pcie 0000:01:00.0: num_tx_timeout = 0
[ 123.035798] mwifiex_pcie 0000:01:00.0: last_cmd_index = 0
[ 123.041205] mwifiex_pcie 0000:01:00.0: last_cmd_id: 10 00 07 01 07 01
07 01 cf 00
[ 123.048709] mwifiex_pcie 0000:01:00.0: last_cmd_act: 01 00 00 00 00
00 00 00 00 34
[ 123.056301] mwifiex_pcie 0000:01:00.0: last_cmd_resp_index = 4
[ 123.062142] mwifiex_pcie 0000:01:00.0: last_cmd_resp_id: 07 81 07 81
07 01 07 01 07 81
[ 123.070078] mwifiex_pcie 0000:01:00.0: last_event_index = 1
[ 123.075672] mwifiex_pcie 0000:01:00.0: last_event: 33 00 0a 00 33 00
33 00 33 00
[ 123.083075] mwifiex_pcie 0000:01:00.0: data_sent=0 cmd_sent=1
[ 123.088841] mwifiex_pcie 0000:01:00.0: ps_mode=1 ps_state=0
[ 123.094470] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump start ==
[ 123.102229] mwifiex_pcie 0000:01:00.0: ITCM_SIZE=0x10000
[ 123.107778] mwifiex_pcie 0000:01:00.0: Start ITCM output, please wait...
[ 125.579854] mwifiex_pcie 0000:01:00.0: ITCM done: size=0x10000
[ 125.586025] mwifiex_pcie 0000:01:00.0: DTCM_SIZE=0x8000
[ 125.591300] mwifiex_pcie 0000:01:00.0: Start DTCM output, please wait...
[ 126.842731] mwifiex_pcie 0000:01:00.0: DTCM done: size=0x8000
[ 126.848813] mwifiex_pcie 0000:01:00.0: SQRAM_SIZE=0xa0000
[ 126.854653] mwifiex_pcie 0000:01:00.0: Start SQRAM output, please wait...
[ 151.729030] mwifiex_pcie 0000:01:00.0: SQRAM done: size=0xa0000
[ 151.735299] mwifiex_pcie 0000:01:00.0: IRAM_SIZE=0x58000
[ 151.740729] mwifiex_pcie 0000:01:00.0: Start IRAM output, please wait...
[ 165.469182] mwifiex_pcie 0000:01:00.0: IRAM done: size=0x58000
[ 165.475357] mwifiex_pcie 0000:01:00.0: APU_SIZE=0x350
[ 165.480449] mwifiex_pcie 0000:01:00.0: Start APU output, please wait...
[ 165.519799] mwifiex_pcie 0000:01:00.0: APU done: size=0x350
[ 165.525712] mwifiex_pcie 0000:01:00.0: CIU_SIZE=0x1000
[ 165.530873] mwifiex_pcie 0000:01:00.0: Start CIU output, please wait...
[ 165.692101] mwifiex_pcie 0000:01:00.0: CIU done: size=0x1000
[ 165.698105] mwifiex_pcie 0000:01:00.0: ICU_SIZE=0x110
[ 165.703175] mwifiex_pcie 0000:01:00.0: Start ICU output, please wait...
[ 165.720419] mwifiex_pcie 0000:01:00.0: ICU done: size=0x110
[ 165.726270] mwifiex_pcie 0000:01:00.0: MAC_SIZE=0x1dc0
[ 165.731432] mwifiex_pcie 0000:01:00.0: Start MAC output, please wait...
[ 166.027001] mwifiex_pcie 0000:01:00.0: MAC done: size=0x1dc0
[ 166.032971] mwifiex_pcie 0000:01:00.0: Firmware dump Finished!
[ 166.039021] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump end ==
Another crash with a differenc cmd id:
[ 66.523837] mwifiex_pcie 0000:01:00.0: mwifiex_cmd_timeout_func:
Timeout cmd id = 0x107, act = 0x0
[ 66.532817] mwifiex_pcie 0000:01:00.0: num_data_h2c_failure = 0
[ 66.538762] mwifiex_pcie 0000:01:00.0: num_cmd_h2c_failure = 0
[ 66.544624] mwifiex_pcie 0000:01:00.0: is_cmd_timedout = 1
[ 66.550122] mwifiex_pcie 0000:01:00.0: num_tx_timeout = 0
[ 66.555546] mwifiex_pcie 0000:01:00.0: last_cmd_index = 1
[ 66.560953] mwifiex_pcie 0000:01:00.0: last_cmd_id: 07 01 07 01 07 01
10 00 ce 00
[ 66.568464] mwifiex_pcie 0000:01:00.0: last_cmd_act: 00 00 00 00 00
00 01 00 00 10
[ 66.576056] mwifiex_pcie 0000:01:00.0: last_cmd_resp_index = 0
[ 66.581895] mwifiex_pcie 0000:01:00.0: last_cmd_resp_id: 07 01 07 81
07 81 07 01 07 01
[ 66.589834] mwifiex_pcie 0000:01:00.0: last_event_index = 0
[ 66.595431] mwifiex_pcie 0000:01:00.0: last_event: 0a 00 58 00 58 00
58 00 0a 00
[ 66.602833] mwifiex_pcie 0000:01:00.0: data_sent=0 cmd_sent=1
[ 66.608612] mwifiex_pcie 0000:01:00.0: ps_mode=1 ps_state=0
[ 66.614209] mwifiex_pcie 0000:01:00.0: cmd timeout
[ 66.619045] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump start ==
[ 66.635674] mwifiex_pcie 0000:01:00.0: ITCM_SIZE=0x10000
[ 66.641046] mwifiex_pcie 0000:01:00.0: Start ITCM output, please wait...
[ 68.915215] mwifiex_pcie 0000:01:00.0: ITCM done: size=0x10000
[ 68.921358] mwifiex_pcie 0000:01:00.0: DTCM_SIZE=0x8000
[ 68.926963] mwifiex_pcie 0000:01:00.0: Start DTCM output, please wait...
[ 70.059221] mwifiex_pcie 0000:01:00.0: DTCM done: size=0x8000
[ 70.065312] mwifiex_pcie 0000:01:00.0: SQRAM_SIZE=0xa0000
[ 70.070855] mwifiex_pcie 0000:01:00.0: Start SQRAM output, please wait...
[ 92.691599] mwifiex_pcie 0000:01:00.0: SQRAM done: size=0xa0000
[ 92.697994] mwifiex_pcie 0000:01:00.0: IRAM_SIZE=0x58000
[ 92.703405] mwifiex_pcie 0000:01:00.0: Start IRAM output, please wait...
[ 105.157862] mwifiex_pcie 0000:01:00.0: IRAM done: size=0x58000
[ 105.164083] mwifiex_pcie 0000:01:00.0: APU_SIZE=0x350
[ 105.169228] mwifiex_pcie 0000:01:00.0: Start APU output, please wait...
[ 105.204942] mwifiex_pcie 0000:01:00.0: APU done: size=0x350
[ 105.210823] mwifiex_pcie 0000:01:00.0: CIU_SIZE=0x1000
[ 105.216002] mwifiex_pcie 0000:01:00.0: Start CIU output, please wait...
[ 105.364402] mwifiex_pcie 0000:01:00.0: CIU done: size=0x1000
[ 105.370432] mwifiex_pcie 0000:01:00.0: ICU_SIZE=0x110
[ 105.375544] mwifiex_pcie 0000:01:00.0: Start ICU output, please wait...
[ 105.391618] mwifiex_pcie 0000:01:00.0: ICU done: size=0x110
[ 105.397459] mwifiex_pcie 0000:01:00.0: MAC_SIZE=0x1dc0
[ 105.402614] mwifiex_pcie 0000:01:00.0: Start MAC output, please wait...
[ 105.670126] mwifiex_pcie 0000:01:00.0: MAC done: size=0x1dc0
[ 105.676154] mwifiex_pcie 0000:01:00.0: Firmware dump Finished!
[ 105.681995] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump end ==
^ permalink raw reply
* Re: WARNING: CPU: 1 PID: 23668 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450
From: Jens Axboe @ 2017-03-01 23:25 UTC (permalink / raw)
To: sara.sharon; +Cc: linux-wireless, luciano.coelho, liad.kaufman
In-Reply-To: <9c4d1814-d6f2-e9c2-0b66-bbfadc002b15@kernel.dk>
On 02/28/2017 01:41 PM, Jens Axboe wrote:
> On 02/28/2017 11:02 AM, Jens Axboe wrote:
>> Hi,
>>
>> I'm hitting this one a lot with current -git, which is this one:
>>
>> if (iwl_mvm_is_dqa_supported(mvm)) {
>> iwl_mvm_disable_sta_queues(mvm, vif, mvm_sta);
>> /*
>> * If pending_frames is set at this point - it must be
>> * driver internal logic error, since queues are empty
>> * and removed successuly.
>> * warn on it but set it to 0 anyway to avoid station
>> * not being removed later in the function
>> */
>> WARN_ON(atomic_xchg(&mvm->pending_frames[sta_id], 0));
>> }
>>
>> It's hit 4 times over the last day. The bug is probably older than the
>> commit that added this warning:
>>
>> commit 94c3e614df2117626fccfac8f821c66e30556384
>> Author: Sara Sharon <sara.sharon@intel.com>
>> Date: Wed Dec 7 15:04:37 2016 +0200
>>
>> iwlwifi: mvm: fix pending frame counter calculation
>>
>> but the pestering is new.
>
> Forgot to include the traces, find them below.
Not that folks have been jumping all over this, but in case someone is
curious, it triggered twice here today. For those two times, the value
of mvm->pending_frames[sta_id] was 80 and 39, respectively.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] mac80211: mesh - always do every discovery retry
From: Chun-Yeow Yeoh @ 2017-03-02 1:28 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Alexis Green, Alexis Green
> Instead of stopping path discovery when a path is found continue
> attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
> limit.
I am not too sure whether by simply broadcasting the PREQ frame could
actually solve the problem and this may cause problem of PREQ flooding
in your network when the number of nodes scale. Please take note that
all nodes need to rebroadcast the PREQ frame until target STA. Path
discovery should stop once the path is established. By attempting 2nd,
3rd or 4th doesn't guarantee the next path will be "good".
> This is important because path messages are not reliable and it is
> relatively common to have a short bad path to the destination along with a
> longer but better path. With the original code rather often a path message
> along the long path would be lost so we would stick with the bad path.
> With this change we have a greater chance to get messages over the longer
> path allowing us to select the long path if it's better.
Reduce the mesh_hwmp_active_path_timeout or mesh_path_refresh_time to
reestablish your path link as soon as possible. Also, if you would
like to have such aggressive behavior, you can reduce the
mesh_hwmp_preq_min_interval to have more aggressive PREQ sending in
your network.
----
Chun-Yeow
^ permalink raw reply
* Re: pull-request: mac80211 2017-02-28
From: David Miller @ 2017-03-01 23:09 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170228095019.10637-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 28 Feb 2017 10:50:18 +0100
> First round of fixes - we actually have quite a few.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
> I had another question - I have this average.h API change pending
> (you saw it before). It seems it might be a good time to get it in
> now, since no new users should be showing up. If I put it in only
> with the next merge window, new users might show up and break.
Ok, you can feel free to send this now for 'net' if you like.
^ permalink raw reply
* Re: WARNING: CPU: 1 PID: 23668 at drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1539 iwl_mvm_rm_sta+0x3ce/0x450
From: Jens Axboe @ 2017-03-02 4:10 UTC (permalink / raw)
To: Luca Coelho; +Cc: luciano.coelho, sara.sharon, liad.kaufman, linux-wireless
In-Reply-To: <f2bedfee-e74f-47d6-9088-94171f0e5538@email.android.com>
On 03/01/2017 08:33 PM, Luca Coelho wrote:
> Hi Jens,
>
> On Mar 1, 2017 20:25, Jens Axboe <axboe@kernel.dk> wrote:
>
> Not that folks have been jumping all over this, but in case someone is
> curious, it triggered twice here today. For those two times, the value
> of mvm->pending_frames[sta_id] was 80 and 39, respectively.
>
> Sorry for the delay, I'm on vacation now with limited internet access.
> But we'll take a look into this early next week at the latest.
>
> Thanks a lot for the detailed report!
No worries, thanks for responding. I just wanted to ensure this wasn't
dropped on the floor.
BTW, a few more values of ->pending_frames[sta_id]:
$ dmesg | grep "ret="
[ 2334.308254] ret=39
[ 7915.311828] ret=80
[31602.317204] ret=41
[32139.510993] ret=54
[33292.917759] ret=96
it seems to often happen around resume.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Johannes Berg @ 2017-03-02 8:39 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <18699231-6ea2-5209-a384-d8f2c2adcdb9@candelatech.com>
> Looks like there are two conventions used (see
> HWSIM_CMD_TX_INFO_FRAME, and HWSIM_CMD_NEW_RADIO). I guess you want
> it indented like the NEW_RADIO command?
Huh, sorry - yes, indented like NEW_RADIO please, I'll fix the others.
johannes
^ permalink raw reply
* Re: [PATCHv2 1/4] cfg80211: Add support to enable or disable btcoex
From: Johannes Berg @ 2017-03-02 8:45 UTC (permalink / raw)
To: c_traja, linux-wireless; +Cc: ath10k
In-Reply-To: <1488029873-14600-2-git-send-email-c_traja@qti.qualcomm.com>
You need to fix the build-bot warning, it's legitimate (though hard to
spot):
> + TP_printk(WIPHY_PR_FMT, ", enabled=%d",
> + WIPHY_PR_ARG, __entry->enabled)
> +);
You have a stray comma there after WIPHY_PR_FMT.
johannes
^ 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