Re: Problem with 40Mhz on 2.5GHz with Intel 8260
On Wed, Sep 21, 2016 at 11:19 PM, Volker Mische wrote: > Hi, > > On 09/21/2016 09:20 AM, Emmanuel Grumbach wrote: can you try to unplug the power cord? I had reports that said that this can help. Again, just a debug step to give us a hint of what you can be experiencing. >>> >>> Unplug without any module parameters or combined with the >>> cfg80211_disable_40mhz_24ghz or power_scheme one? >> >> Nope - default configuration. > > the issue also happens when the power cord is unplugged. Ok - thanks for trying. > Besides this, we need to go for firmware debugging. But as I said, don't expect this to be fast and easy. Please open a bug in bugzilla.kernel.org. CC linuxw...@intel.com and we will guide you there on how to provide the information we need. > > I've filled bug 172431 > > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=172431 Saw that. Thanks. > > Cheers, > Volker
Re: ath9k_htc kernel driver regression affecting throughput
memory will be very tight. There is 160k or known ram and bits and pieces elsewhere. The rom is 24k (maximum). I currently am not to worried about it. (although I am watching it) bruce On 9/21/16, Ben Greear wrote: > > > On 09/21/2016 08:34 PM, bruce m beach wrote: > i.e a lable that the code jumps to and nothing else. At this point I have added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice since it is available a boot, no matter what) and over the next few months I am going to move ->all<- the rom code into ram starting with the USB subsystem. > > Have you investigated whether you have enough RAM to do this? > > I haven't looked at ath9k_htc, but in general, that type of architecture > is tight on RAM in my experience. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com >
Re: ath9k_htc kernel driver regression affecting throughput
On 09/21/2016 08:34 PM, bruce m beach wrote: i.e a lable that the code jumps to and nothing else. At this point I have added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice since it is available a boot, no matter what) and over the next few months I am going to move ->all<- the rom code into ram starting with the USB subsystem. Have you investigated whether you have enough RAM to do this? I haven't looked at ath9k_htc, but in general, that type of architecture is tight on RAM in my experience. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: ath9k_htc kernel driver regression affecting throughput
> We recently updated FW to GCC 6.2 which can detect more problems. So it
> will be probably interesting for you to pick this patch out.
Yes I saw the message by Adrian Chadd and tried tried to git clone the link
he gave but that clearly wasn't what was to be done. Is there a patch that I
need to apply to the firmware? I do have a local copy.
On 9/20/16, Oleksij Rempel wrote:
> Am 21.09.2016 um 05:43 schrieb bruce m beach:
>> Oleksij
>>
>> I looked at
>> https://unix.stackexchange.com/questions/122050/
>> send-traffic-to-self-over-physical-network-on-ubuntu
>>
>> It appearred to too complicated but
>>
>> https://unix.stackexchange.com/questions/122050/
>> send-traffic-to-self-over-physical-network-on-ubuntu
>> with:
>> # Create a network namespace and move one of interfaces into it:
>> ip netns add test2
>> ip link set wlan0 netns test2
>> # Start a shell in the new namespace:
>>ip netns exec test2 bash
>> # Then proceed as if you had two machines. When finished exit the
>> shell and
>> # delete the namespace:
>>ip netns del test2
>> Certainly looks interesting but after I got a
>> RTNETLINK answers: Invalid argument
>> I lost interest. My heart isn't in it. I'm still working on the firmware.
>> I
>> have started a new tree (tree #3) that consists of a userland firmware
>> uploader
>> and until recently the following firmware:
>>
>> app_start( void ) {}
>>
>> i.e a lable that the code jumps to and nothing else. At this point I have
>> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
>> since it is available a boot, no matter what) and over the next few
>> months I am going to move ->all<- the rom code into ram starting with
>> the USB subsystem.
>>
>> Bruce
>>
>
>
> Wow, this sounds interesting :)
> We recently updated FW to GCC 6.2 which can detect more problems. So it
> will be probably interesting for you to pick this patch out.
>
> --
> Regards,
> Oleksij
>
>
Re: pull-request: wireless-drivers 2016-09-20
From: Kalle Valo Date: Tue, 20 Sep 2016 13:20:46 +0300 > last pull request for 4.8, unless something really drastic comes up. And > a small one even, just a small fix to iwlwifi to avoid a firmware crash. > > Please let me know if there are any problems. Pulled, thanks.
Re: Problem with 40Mhz on 2.5GHz with Intel 8260
Hi, On 09/21/2016 09:20 AM, Emmanuel Grumbach wrote: >>> can you try to unplug the power cord? I had reports that said that >>> this can help. Again, just a debug step to give us a hint of what you >>> can be experiencing. >> >> Unplug without any module parameters or combined with the >> cfg80211_disable_40mhz_24ghz or power_scheme one? > > Nope - default configuration. the issue also happens when the power cord is unplugged. >>> Besides this, we need to go for firmware debugging. But as I said, >>> don't expect this to be fast and easy. Please open a bug in >>> bugzilla.kernel.org. CC linuxw...@intel.com and we will guide you >>> there on how to provide the information we need. I've filled bug 172431 [1]: https://bugzilla.kernel.org/show_bug.cgi?id=172431 Cheers, Volker
Re: RTL8192EU on rtl8xxxu driver breaks every few minutes
Oops, forgot to forward the previous reply to the mailing list. I have attached the output of iw link the AP is an asus dsl-n55u router in 2.4 GHz mode, using WPA2-Personal with AES encryption. It's also running a second 5GHz wireless network which has a different SSID. Also, this seems to be some kind of power saving kicking in, as the dongle keeps working as long as I keep doing things over ssh. On 09/20/2016 10:12 PM, Jes Sorensen wrote: > "Franc[e]sco" writes: >> Hi, I happen to own a RTL8192EU WiFi dongle which is marked as untested >> by the rtl8xxxu driver. >> >> I'm on a linux from scratch system using kernel 4.7.3 and wpa_supplicant >> 2.5. >> >> The dongle appears to connect and work fine, but after around 10 minutes >> it deauthenticates and enters and endless loop of authentication >> timeout. This continues even if I bring the interface down and back up >> again. The only way to restore the connection is to physically remove >> and re-plug the usb dongle. >> >> I have attached a dmesg log of connecting and entering the auth loop. > Please provide details about the AP you are trying to connect to and iw > link output. > > Jes $ ./iw enx001988001e33 link Connected to e0:3f:49:97:0c:68 (on enx001988001e33) SSID: memes freq: 2472 RX: 4328394 bytes (26075 packets) TX: 380760 bytes (2785 packets) signal: -60 dBm tx bitrate: 1.0 MBit/s
[PATCH v2] carl9170: fix debugfs crashes
Ben Greear reported:
> I see lots of instability as soon as I load up the carl9710 NIC.
> My application is going to be poking at it's debugfs files...
>
> BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> [carl9170] at addr 0x8801bc1208b0
> Read of size 8 by task btserver/5888
> ===
> BUG kmalloc-256 (Tainted: GW ): kasan: bad access detected
> ---
>
> INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>...
This breakage was caused by the introduction of intermediate
fops in debugfs by commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")
Thankfully, the original/real fops are still available in d_fsdata.
Reported-by: Ben Greear
Signed-off-by: Christian Lamparter
Cc: stable # 4.7+
---
drivers/net/wireless/ath/carl9170/debug.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/debug.c
b/drivers/net/wireless/ath/carl9170/debug.c
index 6808db4..ec3a64e 100644
--- a/drivers/net/wireless/ath/carl9170/debug.c
+++ b/drivers/net/wireless/ath/carl9170/debug.c
@@ -75,7 +75,8 @@ static ssize_t carl9170_debugfs_read(struct file *file, char
__user *userbuf,
if (!ar)
return -ENODEV;
- dfops = container_of(file->f_op, struct carl9170_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+struct carl9170_debugfs_fops, fops);
if (!dfops->read)
return -ENOSYS;
@@ -127,7 +128,8 @@ static ssize_t carl9170_debugfs_write(struct file *file,
if (!ar)
return -ENODEV;
- dfops = container_of(file->f_op, struct carl9170_debugfs_fops, fops);
+ dfops = container_of(debugfs_real_fops(file),
+struct carl9170_debugfs_fops, fops);
if (!dfops->write)
return -ENOSYS;
--
2.9.3
Re: [PATCH 2/4] carl9170: fix debugfs crashes
On Wednesday, September 21, 2016 12:13:25 PM CEST Greg KH wrote:
> On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > Ben Greear reported:
> > > I see lots of instability as soon as I load up the carl9710 NIC.
> > > My application is going to be poking at it's debugfs files...
> > >
> > > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > > [carl9170] at addr 8801bc1208b0
> > > Read of size 8 by task btserver/5888
> > > ===
> > > BUG kmalloc-256 (Tainted: GW ): kasan: bad access detected
> > > ---
> > >
> > > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > >...
> >
> > This breakage was caused by the introduction of intermediate
> > fops in debugfs by commit 9fd4dcece43a
> > ("debugfs: prevent access to possibly dead file_operations at file open")
> >
> > Thankfully, the original/real fops are still available in d_fsdata.
> >
> > Reported-by: Ben Greear
> > Reviewed-by: Nicolai Stange
> > Signed-off-by: Christian Lamparter
> > Acked-by: Kalle Valo
> > Cc: stable # 4.7+
> > ---
> > drivers/net/wireless/ath/carl9170/debug.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/carl9170/debug.c
> > b/drivers/net/wireless/ath/carl9170/debug.c
> > index 01a0919..ad7ffd5 100644
> > --- a/drivers/net/wireless/ath/carl9170/debug.c
> > +++ b/drivers/net/wireless/ath/carl9170/debug.c
> > @@ -75,7 +75,7 @@ static ssize_t carl9170_debugfs_read(struct file *file,
> > char __user *userbuf,
> >
> > if (!ar)
> > return -ENODEV;
> > - dfops = container_of(file->f_path.dentry->d_fsdata,
> > + dfops = container_of(debugfs_real_fops(file),
> > struct carl9170_debugfs_fops, fops);
> >
> > if (!dfops->read)
> > @@ -128,7 +128,7 @@ static ssize_t carl9170_debugfs_write(struct file *file,
> >
> > if (!ar)
> > return -ENODEV;
> > - dfops = container_of(file->f_path.dentry->d_fsdata,
> > + dfops = container_of(debugfs_real_fops(file),
> > struct carl9170_debugfs_fops, fops);
> > if (!dfops->write)
> > return -ENOSYS;
>
> What tree is this against? I can't apply it to 4.8-rc5, or 4.8-rc7, are
> you sure it is still needed?
---
Yes, the patch is needed. That said I screwed this patch up and as a result
it is faulty. I'll send out v2 shortly
Thanks,
Christian
Re: ath10k mesh mode issue
Hi Michal, thanks for the reply: I've already loaded the ath10k_core with the rowmode parameters, this is the modinfo result: root@Tam:~# modinfo ath10k_core filename: /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_core.ko license:Dual BSD/GPL description:Core module for QCA988X PCIe devices. author: Qualcomm Atheros srcversion: 407804E6D5A63597F137E9B depends:mac80211,cfg80211,compat,ath vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8 parm: debug_mask:Debugging mask (uint) parm: uart_print:Uart target debugging (bool) parm: skip_otp:Skip otp failure for calibration in testmode (bool) parm: cryptmode:Crypto mode: 0-hardware, 1-software (uint) parm: rawmode:Use raw 802.11 frame datapath (bool) root@Tam:~# modinfo ath10k_pci filename: /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko firmware: ath10k/QCA9377/hw1.0/board.bin firmware: ath10k/QCA9377/hw1.0/firmware-5.bin firmware: ath10k/QCA6174/hw3.0/board-2.bin firmware: ath10k/QCA6174/hw3.0/board.bin firmware: ath10k/QCA6174/hw3.0/firmware-5.bin firmware: ath10k/QCA6174/hw3.0/firmware-4.bin firmware: ath10k/QCA6174/hw2.1/board-2.bin firmware: ath10k/QCA6174/hw2.1/board.bin firmware: ath10k/QCA6174/hw2.1/firmware-5.bin firmware: ath10k/QCA6174/hw2.1/firmware-4.bin firmware: ath10k/QCA988X/hw2.0/board-2.bin firmware: ath10k/QCA988X/hw2.0/board.bin firmware: ath10k/QCA988X/hw2.0/firmware-5.bin firmware: ath10k/QCA988X/hw2.0/firmware-4.bin firmware: ath10k/QCA988X/hw2.0/firmware-3.bin firmware: ath10k/QCA988X/hw2.0/firmware-2.bin firmware: ath10k/QCA988X/hw2.0/firmware.bin license:Dual BSD/GPL description:Driver support for Atheros QCA988X PCIe devices author: Qualcomm Atheros version:backported from Linux (v4.4.2-0-g1cb8570) using backports v4.4.2-1-0-gbec4037 srcversion: EBB3D4E36DE49B7EC8057D0 alias: pci:v168Cd0042sv*sd*bc*sc*i* alias: pci:v168Cd0040sv*sd*bc*sc*i* alias: pci:v168Cd003Esv*sd*bc*sc*i* alias: pci:v168Cd0041sv*sd*bc*sc*i* alias: pci:v168Cd003Csv*sd*bc*sc*i* depends:ath10k_core,compat vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8 parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint) parm: reset_mode:0: auto, 1: warm only (default: 0) (uint) I've loaded adding the line ath10k_core rawmode=1 to the file etc/modules The problem persists... maybe it's a firmware issue or even a fault of the wifi card? Really many thanks Matteo > > 2016-09-19 13:22 GMT+02:00 Michal Kazior : >> >> On 16 September 2016 at 12:56, Matteo Grandi wrote: >> > Hello all, >> [...] >> > [8.589474] ath10k_pci :07:00.0: qca988x hw2.0 (0x4100016c, >> > 0x043222ff sub :) fw 10.2.4.70.54 fwapi 5 bdapi 1 htt-ver 2.1 >> > wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features >> > no-p2p,raw-mode >> >> The "raw-mode" here only hints the firmware is capable of raw mode >> operation which needs to be explicitly enabled. >> >> >> > [8.589491] ath10k_pci :07:00.0: debug 1 debugfs 1 tracing 0 >> > dfs 0 testmode 1 >> > [8.691670] ath: EEPROM regdomain: 0x0 >> > [8.691680] ath: EEPROM indicates default country code should be used >> > [8.691686] ath: doing EEPROM country->regdmn map search >> > [8.691695] ath: country maps to regdmn code: 0x3a >> > [8.691702] ath: Country alpha2 being used: US >> > [8.691706] ath: Regpair used: 0x3a >> > [ 176.983250] ath10k_pci :07:00.0: must load driver with >> > rawmode=1 to add mesh interfaces >> [...] >> > - I've also tried to load the ath10k modules adding the parameter >> > rowmode=1 but I had an error "rawmode unknown parameter" >> >> Only ath10k_core needs to be loaded with rawmode=1. >> >> You can check available module parameters with: >> modinfo ath10k_core >> modinfo ath10k_pci >> >> >> Michał > >
Re: TCP data throughput for BCM43362
On 19-09-16 08:36, Jörg Krause wrote: > Hi Arend, > > On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote: >> On 14-9-2016 15:41, Jörg Krause wrote: >>> >>> Hi, >>> >>> On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote: On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel wrote: > > > On 22-8-2016 15:37, Jörg Krause wrote: >> >> >> >> Hi all, >> >> I am back from vacation and I'd like to do more >> investigations >> about >> this issue. Please see my comments below... >> >> On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel wrote: >>> >>> >>> >>> On 06-08-16 16:12, Jörg Krause wrote: Hi all, >>> >>> A bit weird email format making it a bit hard to determine >>> where >>> your >>> last reply starts... >>> On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote: On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause >>> @emb ed ded. ro cks> wrote: Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel < arend.vanspr...@broadcom.com>: Op 5 aug. 2016 22:46 schreef "Jörg Krause" : Hi, I'm using a custom ARM board with an BCM43362 wifi chip from Broadcom. The wifi chip is attached via SDIO to the controller with a clock of 48MHz. Linux kernel version is 4.7. When measuring the network bandwidth with iperf3 I get a bandwith of only around 5 Mbps. I found a similar thread at the Broadcom community [1] where the test was done with a M4 CPU + BCM43362 and an average result of 3.3 Mbps. Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data throughput greater than 20 Mbps. Why is the throughput I measured much lower? Note that I measured several times with almost no neighbor devices or networks. This is a test sample measured with iperf3: $ iperf3 -c 192.168.2.1 -i 1 -t 10 Connecting to host 192.168.2.1, port 5201 [ 4] local 192.168.2.155 port 36442 connected to 192.168.2.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwn d [ 4] 0.00-1.00 sec 615 KBytes 5.04 Mbits/sec0 56.6 KBytes [ 4] 1.00-2.00 sec 622 KBytes 5.10 Mbits/sec0 84.8 KBytes [ 4] 2.00-3.00 sec 625 KBytes 5.12 Mbits/sec0113 KBytes [ 4] 3.00-4.00 sec 571 KBytes 4.68 Mbits/sec0140 KBytes [ 4] 4.00-5.00 sec 594 KBytes 4.87 Mbits/sec0167 KBytes [ 4] 5.00-6.00 sec 628 KBytes 5.14 Mbits/sec0195 KBytes [ 4] 6.00-7.00 sec 619 KBytes 5.07 Mbits/sec0202 KBytes [ 4] 7.00-8.00 sec 608 KBytes 4.98 Mbits/sec0202 KBytes [ 4] 8.00-9.00 sec 602 KBytes 4.93 Mbits/sec0202 KBytes [ 4] 9.00-10.00 sec 537 KBytes 4.40 Mbits/sec0202 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0 sender [ 4] 0.00-10.00 sec 5.68 MBytes 4.76 Mbits/sec receiver Not overly familiar with iperf3. Do these lines mean you are doing bidirectional test, ie. upstream and downstream at the same time. Another thing affecting tput could be power-save. No, iperf3 does not support bidrectional test. Power-save is turned off. What does iw link say? >>> >>> but I guess it starts here! >>> I compared the results with a Cubietruck I have: # iperf3 -s --- Server listening on 5201 ---
RE: [PATCH v3 0/9] Add support for Neighbor Awareness Networking
> -Original Message- > From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com] > Sent: Wednesday, September 21, 2016 12:40 > To: Luca Coelho ; johan...@sipsolutions.net > Cc: linux-wireless@vger.kernel.org; Beker, Ayala ; > Otcheretianski, Andrei ; Coelho, Luciano > > Subject: Re: [PATCH v3 0/9] Add support for Neighbor Awareness > Networking > > > > On 20-9-2016 16:31, Luca Coelho wrote: > > From: Luca Coelho > > > > Hi, > > > > Now v3 of the NAN patchset. Ayala has taken care of the kbuild bot > > compilation errors and of all Arend's comments, except for the one > > about adding a helper function instead checking for P2P_DEVICE and NAN > > for non-netdev interfaces. > > > > Comments are welcome, as always. > > This series exports three functions to be used by drivers: > > void cfg80211_free_nan_func(struct cfg80211_nan_func *f); void > cfg80211_nan_match(struct wireless_dev *wdev, > struct cfg80211_nan_match_params *match, gfp_t > gfp); void cfg80211_nan_func_terminated(struct wireless_dev *wdev, > u8 inst_id, > enum nl80211_nan_func_term_reason > reason, > u64 cookie, gfp_t gfp); > > Some more descriptive text about the use of these functions would be > appropriate I think. For example looking at the patch series it seems the > responsibility to call cfg80211_free_nan_func() is in the driver although > allocation is done by cfg80211. Regarding the cfg80211_free_nan_func() it is documented in patch "[PATCH v3 3/9] cfg80211: add add_nan_func / del_nan_func" Here: * @add_nan_func: Add a NAN function. Returns negative value on failure. * On success @nan_func ownership is transferred to the driver and * it may access it outside of the scope of this function. The driver * should free the @nan_func when no longer needed by calling * cfg80211_free_nan_func(). * On success the driver should assign an instance_id in the * provided @nan_func. All the others are pretty much straight forward. Match and termination events are defined in NAN spec - so it should be easy to know when to call these functions. > Actually, I do not see mac80211 calling it so are > we leaking there? I would expect it being called in > .del_nan_func() callback and/or .stop_nan(). It is. Look at "[PATCH v3 8/9] mac80211: Implement add_nan_func and rm_nan_func". It is called in stop_nan() and nan_func_terminated() callback. The nan function can't be freed directly in del_nan_func() - otherwise it would be racy with match/termination notifications. > Rather than exporting > cfg80211_free_nan_func() I would prefer calling > cfg80211_nan_func_terminated() and have cfg80211 take care of freeing > nan_func resources. As I already answered, there are some situations when the wdev isn't available and mac80211 can't call cfg80211_nan_func_terminated() - for example nan interface is being stopped (at least it's true for mac80211). Also I think that the driver should be able to free the nan function without being forced to send notification to the user space and the other way around. > > Regards, > Arend > > > Cheers, > > Luca. > > > > > > Ayala Beker (9): > > cfg80211: add start / stop NAN commands > > mac80211: add boilerplate code for start / stop NAN > > cfg80211: add add_nan_func / del_nan_func > > cfg80211: allow the user space to change current NAN configuration > > cfg80211: provide a function to report a match for NAN > > cfg80211: Provide an API to report NAN function termination > > mac80211: implement nan_change_conf > > mac80211: Implement add_nan_func and rm_nan_func > > mac80211: Add API to report NAN function match > > > > include/net/cfg80211.h | 184 - > > include/net/mac80211.h | 65 + > > include/uapi/linux/nl80211.h | 253 + > > net/mac80211/cfg.c | 208 ++ > > net/mac80211/chan.c | 6 + > > net/mac80211/driver-ops.h| 80 ++ > > net/mac80211/ieee80211_i.h | 17 ++ > > net/mac80211/iface.c | 28 +- > > net/mac80211/main.c | 8 + > > net/mac80211/offchannel.c| 4 +- > > net/mac80211/rx.c| 3 + > > net/mac80211/trace.h | 133 + > > net/mac80211/util.c | 50 +++- > > net/wireless/chan.c | 2 + > > net/wireless/core.c | 35 +++ > > net/wireless/core.h | 3 + > > net/wireless/mlme.c | 1 + > > net/wireless/nl80211.c | 642 > ++- > > net/wireless/rdev-ops.h | 58 > > net/wireless/trace.h | 90 ++ > > net/wireless/util.c | 28 +- > > 21 files changed, 1888 insertions(+), 10 deletions(-) > >
[PATCH] ath10k: fix copy engine 5 destination ring stuck
Firmware is running watchdog timer for tracking copy engine ring index and write index. Whenever both indices are stuck at same location for given duration, watchdog will be trigger to assert target. While updating copy engine destination ring write index, driver ensures that write index will not be same as read index by finding delta between these two indices (CE_RING_DELTA). HTT target to host copy engine (CE5) is special case where ring buffers will be reused and delta check is not applied while updating write index. In rare scenario, whenever CE5 ring is full, both indices will be referring same location and this is causing CE ring stuck issue as explained above. This issue is originally reported on IPQ4019 during long hour stress testing and during veriwave max clients testsuites. The same issue is also observed in other chips as well. Fix this by ensuring that write index is one less than read index which means that full ring is available for receiving data. Cc: sta...@vger.kernel.org Tested-by: Tamizh chelvam Signed-off-by: Rajkumar Manoharan --- drivers/net/wireless/ath/ath10k/ce.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c index 65d8d714e917..00d3f93058db 100644 --- a/drivers/net/wireless/ath/ath10k/ce.c +++ b/drivers/net/wireless/ath/ath10k/ce.c @@ -433,6 +433,13 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe *pipe, u32 nentries) unsigned int nentries_mask = dest_ring->nentries_mask; unsigned int write_index = dest_ring->write_index; u32 ctrl_addr = pipe->ctrl_addr; + u32 cur_write_idx = ath10k_ce_dest_ring_write_index_get(ar, ctrl_addr); + + /* Prevent CE ring stuck issue that will occur when ring is full. +* Make sure that write index is 1 less than read index. +*/ + if ((cur_write_idx + nentries) == dest_ring->sw_index) + nentries -= 1; write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries); ath10k_ce_dest_ring_write_index_set(ar, ctrl_addr, write_index); -- 2.10.0
Re: [PATCH 2/4] carl9170: fix debugfs crashes
On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> Ben Greear reported:
> > I see lots of instability as soon as I load up the carl9710 NIC.
> > My application is going to be poking at it's debugfs files...
> >
> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > [carl9170] at addr 8801bc1208b0
> > Read of size 8 by task btserver/5888
> > ===
> > BUG kmalloc-256 (Tainted: GW ): kasan: bad access detected
> > ---
> >
> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> >...
>
> This breakage was caused by the introduction of intermediate
> fops in debugfs by commit 9fd4dcece43a
> ("debugfs: prevent access to possibly dead file_operations at file open")
>
> Thankfully, the original/real fops are still available in d_fsdata.
>
> Reported-by: Ben Greear
> Reviewed-by: Nicolai Stange
> Signed-off-by: Christian Lamparter
> Acked-by: Kalle Valo
> Cc: stable # 4.7+
> ---
> drivers/net/wireless/ath/carl9170/debug.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/debug.c
> b/drivers/net/wireless/ath/carl9170/debug.c
> index 01a0919..ad7ffd5 100644
> --- a/drivers/net/wireless/ath/carl9170/debug.c
> +++ b/drivers/net/wireless/ath/carl9170/debug.c
> @@ -75,7 +75,7 @@ static ssize_t carl9170_debugfs_read(struct file *file,
> char __user *userbuf,
>
> if (!ar)
> return -ENODEV;
> - dfops = container_of(file->f_path.dentry->d_fsdata,
> + dfops = container_of(debugfs_real_fops(file),
>struct carl9170_debugfs_fops, fops);
>
> if (!dfops->read)
> @@ -128,7 +128,7 @@ static ssize_t carl9170_debugfs_write(struct file *file,
>
> if (!ar)
> return -ENODEV;
> - dfops = container_of(file->f_path.dentry->d_fsdata,
> + dfops = container_of(debugfs_real_fops(file),
>struct carl9170_debugfs_fops, fops);
> if (!dfops->write)
> return -ENOSYS;
What tree is this against? I can't apply it to 4.8-rc5, or 4.8-rc7, are
you sure it is still needed?
thanks,
greg k-h
Re: [PATCH v3 0/9] Add support for Neighbor Awareness Networking
On 20-9-2016 16:31, Luca Coelho wrote: > From: Luca Coelho > > Hi, > > Now v3 of the NAN patchset. Ayala has taken care of the kbuild bot > compilation errors and of all Arend's comments, except for the one > about adding a helper function instead checking for P2P_DEVICE and NAN > for non-netdev interfaces. > > Comments are welcome, as always. This series exports three functions to be used by drivers: void cfg80211_free_nan_func(struct cfg80211_nan_func *f); void cfg80211_nan_match(struct wireless_dev *wdev, struct cfg80211_nan_match_params *match, gfp_t gfp); void cfg80211_nan_func_terminated(struct wireless_dev *wdev, u8 inst_id, enum nl80211_nan_func_term_reason reason, u64 cookie, gfp_t gfp); Some more descriptive text about the use of these functions would be appropriate I think. For example looking at the patch series it seems the responsibility to call cfg80211_free_nan_func() is in the driver although allocation is done by cfg80211. Actually, I do not see mac80211 calling it so are we leaking there? I would expect it being called in .del_nan_func() callback and/or .stop_nan(). Rather than exporting cfg80211_free_nan_func() I would prefer calling cfg80211_nan_func_terminated() and have cfg80211 take care of freeing nan_func resources. Regards, Arend > Cheers, > Luca. > > > Ayala Beker (9): > cfg80211: add start / stop NAN commands > mac80211: add boilerplate code for start / stop NAN > cfg80211: add add_nan_func / del_nan_func > cfg80211: allow the user space to change current NAN configuration > cfg80211: provide a function to report a match for NAN > cfg80211: Provide an API to report NAN function termination > mac80211: implement nan_change_conf > mac80211: Implement add_nan_func and rm_nan_func > mac80211: Add API to report NAN function match > > include/net/cfg80211.h | 184 - > include/net/mac80211.h | 65 + > include/uapi/linux/nl80211.h | 253 + > net/mac80211/cfg.c | 208 ++ > net/mac80211/chan.c | 6 + > net/mac80211/driver-ops.h| 80 ++ > net/mac80211/ieee80211_i.h | 17 ++ > net/mac80211/iface.c | 28 +- > net/mac80211/main.c | 8 + > net/mac80211/offchannel.c| 4 +- > net/mac80211/rx.c| 3 + > net/mac80211/trace.h | 133 + > net/mac80211/util.c | 50 +++- > net/wireless/chan.c | 2 + > net/wireless/core.c | 35 +++ > net/wireless/core.h | 3 + > net/wireless/mlme.c | 1 + > net/wireless/nl80211.c | 642 > ++- > net/wireless/rdev-ops.h | 58 > net/wireless/trace.h | 90 ++ > net/wireless/util.c | 28 +- > 21 files changed, 1888 insertions(+), 10 deletions(-) >
wifi test automation?
Hallo all, What kind of WiFi testomation are you using? Right now i found some links, do some of this used by WiFi devs? http://avocado-framework.github.io/ https://autotest.github.io/ https://github.com/Wi-FiTestSuite https://wireless.wiki.kernel.org/en/developers/testing/wifi-test
[PATCH] rsi: fix memory leak in module unload
debugfs entry removal statement moved inside CONFIG_RSI_DEBUGSFS flag
added freeing of below structures
* channel list for each supported band
* rsi debugfs info
Signed-off-by: Prameela Rani Garnepudi
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index dbb2389..f4bbf15 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -194,6 +194,7 @@ static void rsi_register_rates_channels(struct rsi_hw
*adapter, int band)
void rsi_mac80211_detach(struct rsi_hw *adapter)
{
struct ieee80211_hw *hw = adapter->hw;
+ enum nl80211_band band;
if (hw) {
ieee80211_stop_queues(hw);
@@ -201,7 +202,17 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
ieee80211_free_hw(hw);
}
+ for (band = 0; band < 2; band++) {
+ struct ieee80211_supported_band *sband =
+ &adapter->sbands[band];
+
+ kfree(sband->channels);
+ }
+
+#ifdef CONFIG_RSI_DEBUGFS
rsi_remove_dbgfs(adapter);
+ kfree(adapter->dfsentry);
+#endif
}
EXPORT_SYMBOL_GPL(rsi_mac80211_detach);
--
2.4.11
Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
On 20-9-2016 16:36, Luca Coelho wrote: > Hi Arend, > > On Tue, 2016-09-20 at 14:29 +0200, Arend Van Spriel wrote: >> On 20-9-2016 13:45, Beker, Ayala wrote: >>> I don't think there is something in common to those interface types >>> that can fit such a function semantically, so I decided not to >>> change it. >>> Do you have any idea? >> >> What is common is that these are both non-netdev interface types. > > I tend to agree with you. I also thought about an > ieee80211_has_netdev() function for this, but I didn't check whether > this was exactly what we need... Maybe it does not fit all instances, but quite a few checks are there to skip netdev related stuff. > In any case, do you mind if we address this in a separate patch? Fine by me. Regards, Arend > -- > Cheers, > Luca. >
Re: Problem with 40Mhz on 2.5GHz with Intel 8260
>>> >>> I've set the iwlmvm power_scheme to 1 (and allowed the 40Mhz >>> connection). First I thought it's good, but after a while the queue >>> still got stuck. Especially after waking up from a suspend (not sure if >>> that matters). >> >> Ok - good to know. >> >>> >>> What are the next steps? >> >> can you try to unplug the power cord? I had reports that said that >> this can help. Again, just a debug step to give us a hint of what you >> can be experiencing. > > Unplug without any module parameters or combined with the > cfg80211_disable_40mhz_24ghz or power_scheme one? Nope - default configuration. > > >> Besides this, we need to go for firmware debugging. But as I said, >> don't expect this to be fast and easy. Please open a bug in >> bugzilla.kernel.org. CC linuxw...@intel.com and we will guide you >> there on how to provide the information we need. > > OK, will do once I did try with unplugging. I've seen previous reports > on the issue. As I'm already running a Kernel compiled from source I > hope that at least I can move fast :) Oh - the firmware debugging doesn't involve any source modification. > > Cheers, > Volker >
Re: Problem with 40Mhz on 2.5GHz with Intel 8260
Hi, On 09/21/2016 08:54 AM, Emmanuel Grumbach wrote: >> On 09/20/2016 08:22 AM, Volker Mische wrote: >>> On 09/20/2016 07:39 AM, Emmanuel Grumbach wrote: On Mon, Sep 19, 2016 at 5:00 PM, Volker Mische wrote: > I'm having connectivity issues with an Intel 8260 on a 2.5GHz network > when using 40Mhz. I'm getting errors like > > Queue 2 stuck for 1 ms. > > I've upgrade my system to the firmware version 21 (21.373438.0) and > Kernel 4.8.0-rc6 in hope that it fixes the issue and to be able to debug > the problem. > > I then found the page about platform noise [1]. I don't have any issue > for several hours now (normally I was hitting the issue every few > minutes) as I've set the cfg80211_disable_40mhz_24ghz parameter. >> We tried a few times to debug those, but they take a very long time to debug since typically we need lots of reproductions and the firmware team doesn't always the time to look at the data immediately so in the end, the people who reported this originally went away. Note that 40MHz on 2.4GHz is not an optimal configuration in crowded environment, but if you live in a place where you are pretty much the only one using those frequencies, then, it can be beneficial. >>> >>> It's at home. I normally see only one other wifi (I need to check which >>> frequency that one is using). >>> >>> What you can try is to disable low power states (by using power_scheme in iwlmvm) and see if it helps. >>> >>> I will try that. >> >> I've set the iwlmvm power_scheme to 1 (and allowed the 40Mhz >> connection). First I thought it's good, but after a while the queue >> still got stuck. Especially after waking up from a suspend (not sure if >> that matters). > > Ok - good to know. > >> >> What are the next steps? > > can you try to unplug the power cord? I had reports that said that > this can help. Again, just a debug step to give us a hint of what you > can be experiencing. Unplug without any module parameters or combined with the cfg80211_disable_40mhz_24ghz or power_scheme one? > Besides this, we need to go for firmware debugging. But as I said, > don't expect this to be fast and easy. Please open a bug in > bugzilla.kernel.org. CC linuxw...@intel.com and we will guide you > there on how to provide the information we need. OK, will do once I did try with unplugging. I've seen previous reports on the issue. As I'm already running a Kernel compiled from source I hope that at least I can move fast :) Cheers, Volker
