Re: [EXTERNAL] [PATCH] ath9k_htc: add fw 1.4.1

[Tom Psyborg]

Every build attempt of the firmware without modifying the code results
in same checksum of the built file. So I guess this should be easy to
verify.

Re: [PATCH 0/5] rt2800mmio txdone/interrupts/flush rework

[Tom Psyborg]

On 05/11/2018, Craig Matsuura  wrote:
> Tom,
>
>
> I see my name and email in some urls but could not see what you are
> referring too?
>
>
> Craig
>
>
> Craig Matsuura • Technical Director, Embedded Software Architecture
>
> cmatsu...@vivint.com • P: 801.229.6005
>
>
>
> simply smarter • vivint.com
>
> 3401 N Ashton Blvd. Lehi, UT 84043
>
>
>
> [1497369905956_vivint-logo-orange.png]
>
> 
> From: linux-wireless-ow...@vger.kernel.org
>  on behalf of Tomislav Požega
> 
> Sent: Thursday, October 4, 2018 5:51:42 PM
> To: sgrus...@redhat.com
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH 0/5] rt2800mmio txdone/interrupts/flush rework
>
> Hi
>
> As suspected this changeset causes throughput regression.
>
> Below screenshots show iperf test from MS150N (RF5370) device connected to
> RT3070 adapter running AP mode:
>
> This is with standard openwrt build without any rt2x00 changes:
>
> [url=https://postimg.cc/BtYQLf6r][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FBtYQLf6r%2Fshot-2018-10-04_17-23-56.jpg%5B%2Fimg%5D%5B%2Furldata=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0sdata=Fsq5PtjbTx3vuXrNyicoVMVyk59dlXin0SecZTKCcOY%3Dreserved=0]
>
> And this printscreen show iperf test with your changes:
>
> [url=https://postimg.cc/D8Sf1p48][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FD8Sf1p48%2Fshot-2018-10-04_17-42-09.jpg%5B%2Fimg%5D%5B%2Furldata=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0sdata=w9eslvFB%2F13VBHGG7n48C2KH4ceyk1Acb5G3wEoPdEc%3Dreserved=0]
>
> Atheros card connected to RT3070 iperf test difference was negligible (1Mbps
> or less) on bodhi system, but
> it started to throw out reorder messages on my standard ubuntu after your
> changes:
>
> [url=https://postimg.cc/SjJbP2SP][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FSjJbP2SP%2FScreenshot.png%5B%2Fimg%5D%5B%2Furldata=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0sdata=7AfQGKReywwEYrVZzYOxpLqbmg8kBdCbNE6Mj0%2BmGRM%3Dreserved=0]
>
> My advice: stop sending low-quality patches and do some testing before
> submission.
>

Hi

No idea where did you got that message from, some safelink protection
seem to be added somewhere in the mailing process. You can check my
original mail here:
https://www.mail-archive.com/linux-wireless@vger.kernel.org/msg49652.html
. If interested in links you should open them manually as the URL
formating seems inappropriate.

Re: ath9k driver may be broken on ARM64 ?

[Tom Psyborg]

if your system is read-only then you should make a build with debug
option enabled:

inside your buildroot create this path: files/etc/modules.d/ and put
file named ath9k there which should contain "ath9k debug=0x"
(more info: 
https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#custom_files)

rebuild and try boot again capturing bootlog

Re: ath9k driver may be broken on ARM64 ?

[Tom Psyborg]

Hi

Try selecting config option ATH9K_SUPPORT_PCOEM (Support chips used in
PC OEM cards) and rebuild your image.

I'm not familiar with your architecture but it seems you're not
getting debug output. It should print a lot of info right after the:
ath: phy0: WB335 2-ANT card detected

dynack slows down network when enabled on AR9462 card

[Tom Psyborg]

Hi

Running several tests with dynack enabled on AR9462 card I can see
throughput drop in 10-30Mbps range.

The card is running on 4.9.135 kernel (same issue was present on
3.2.11 with backports4.4.2) while QCA9531 router is running 4.9.111.

Distance between the two is less than 1m. Results:

QCA9531 auto distance + AR9462 default -> 10Mbps higher RX bandwidth
on client (AR9462), RX bandwidth remain unchanged

QCA9531 default + AR9462 auto distance -> at least 10Mbps lower RX
bandwidth and up to 30Mbps (depending on window size) lower TX
bandwidth on client

QCA9531 auto distance + AR9462 auto distance -> at least 10Mbps lower
RX bandwidth and up to 30Mbps (depending on window size) lower TX
bandwidth on client

Given that the bandwidth improves when executed iw phy0 set distance
auto on router and degrades in any case same command is executed on
client PC running AR9462 seems like there are some timers
misconfiguration in ath9k regarding this card. Any thoughts on this?

Regards, Tom

Re: ath9k driver may be broken on ARM64 ?

[Tom Psyborg]

Hi

There was similar issue reported in forum recently:
https://forum.openwrt.org/t/wireless-card-atheros-ar9565/23608

Could you enable ath9k debug and post output?

Re: Handling user regdom hints while having intersected world regdom

[Tom Psyborg]

Hi

After this change, on interface reconfig regdomains for both int. and
usb radio are no longer 98. instead they are both set to US (int.
radio regdomain) while usb should be set to GB. I am not sure if there
is an easy way to handle this.
Bad thing is that regdomains still intersect for few seconds on usb
card insert and during that time int. radio resets it's txpower to
max->described in this bug issue:
https://bugs.openwrt.org/index.php?do=details_id=1745

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

On 19/10/2018, Stanislaw Gruszka  wrote:
>
> I tried to do this, but somehow after update BUILD1 image into device
> my configuration was wiped out :-( and I have to reconfigure the
> device now. Anyway I'm going to test and provide dmesg , but this
> will take some time.
>
> Regards
> Stanislaw
>

that's because these builds were done on 4.4 that i had in my system
and there are config differences between these builds and current
snapshot. to save you time i need only bootlogs not wifi performance
tests.

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

On 16/10/2018, Stanislaw Gruszka  wrote:
> Hello
>
> On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
>> I am sending you two builds privately so please check if there are any
>> differences between the two builds and report back. Thanks.
>
> I extracted rt2800lib.ko module from provided images, did disassembly via:
>
> ./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump
> \
>  -d -r --prefix-addresses ~/rt2800lib-BUILDn.ko  > ~/BUILDn.dump.txt
>
> command and compered disassembled code. Here is difference:
>
> $ diff -up  BUILD1.dump.txt BUILD2.dump.txt
> --- BUILD1.dump.txt   2018-10-16 16:40:34.834220838 +0200
> +++ BUILD2.dump.txt   2018-10-16 16:40:40.187219211 +0200
> @@ -1,5 +1,5 @@
>
> -/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
> +/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
>
>
>  Disassembly of section .text:
> @@ -9374,7 +9374,7 @@ Disassembly of section .text:
>  7f80  jalrv0
>  7f84  movea0,s0
>  7f88  lhu v1,732(s0)
> -7f8c  li  v0,21392
> +7f8c  li  v0,25426
>  7f90  bne v1,v0,810c
> 
>  7f94  li  a2,1025
>  7f98  lw  v0,4(s0)
>
> There is no difference in init_registers (which is inlined in
> rt2800_enable_radio). The only difference is in some number
> rt2800_clear_beacon() function.
>
> Regards
> Stanislaw
>

hi

i rechecked this and your debug procedure seems to be unreliable.

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

On 16/10/2018, Stanislaw Gruszka  wrote:
> Hello
>
> On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
>> I am sending you two builds privately so please check if there are any
>> differences between the two builds and report back. Thanks.
>
> I extracted rt2800lib.ko module from provided images, did disassembly via:
>
> ./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump
> \
>  -d -r --prefix-addresses ~/rt2800lib-BUILDn.ko  > ~/BUILDn.dump.txt
>
> command and compered disassembled code. Here is difference:
>
> $ diff -up  BUILD1.dump.txt BUILD2.dump.txt
> --- BUILD1.dump.txt   2018-10-16 16:40:34.834220838 +0200
> +++ BUILD2.dump.txt   2018-10-16 16:40:40.187219211 +0200
> @@ -1,5 +1,5 @@
>
> -/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
> +/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
>
>
>  Disassembly of section .text:
> @@ -9374,7 +9374,7 @@ Disassembly of section .text:
>  7f80  jalrv0
>  7f84  movea0,s0
>  7f88  lhu v1,732(s0)
> -7f8c  li  v0,21392
> +7f8c  li  v0,25426
>  7f90  bne v1,v0,810c
> 
>  7f94  li  a2,1025
>  7f98  lw  v0,4(s0)
>
> There is no difference in init_registers (which is inlined in
> rt2800_enable_radio). The only difference is in some number
> rt2800_clear_beacon() function.
>
> Regards
> Stanislaw
>

i meant you try it on your nexx device. and post dmesg if you can boot them

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

On 16/10/2018, Stanislaw Gruszka  wrote:
> On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
>> On 12/10/2018, Stanislaw Gruszka  wrote:
>> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> >> > On upstream tree where this patch is intended
>> >> > additional registers where never programmed as proper branch
>> >> > were never used, because of additional check in RT5390 branch.
>> >> >
>> >>
>> >> on my hardware additional registers were programmed in regardless of
>> >> redundant check. that why i opened whole thread on forum since i
>> >> couldn't understand how's that happening
>> >
>> > I don't understand how that possible either.
>>
>> i'd assume because device use external lna
>
> I have no idea how this could be related. But I think I found
> somewhat reasonable explenation where the problem is.
> I think below code :
>
>   if (a || b || c) {
>   CODE1();
>   } else if (c) {
>   CODE2();
>   }
>
> can not be deterministic and can be compiled differently depending
> on compiler version and used options. Sometimes it could result
> in this
>
>   if (a || b || c) {
>   CODE1();
>   }
>
> and sometimes in this:
>
>   if (a || b) {
>   CODE1();
>   } else if (c) {
>   CODE2();
>   }
>
> So that would explain the problems you see. And indeed patch
> could cause regression on systems where second variant of
> initalizing RT6352 registers was used.
>
> Thanks
> Stanislaw
>

Hi

I am sending you two builds privately so please check if there are any
differences between the two builds and report back. Thanks.

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

On 12/10/2018, Stanislaw Gruszka  wrote:
> On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> > On upstream tree where this patch is intended
>> > additional registers where never programmed as proper branch
>> > were never used, because of additional check in RT5390 branch.
>> >
>>
>> on my hardware additional registers were programmed in regardless of
>> redundant check. that why i opened whole thread on forum since i
>> couldn't understand how's that happening
>
> I don't understand how that possible either.

i'd assume because device use external lna
>
>> > Patch does only change TX_SW_CFG* regs values for RT6352.
>> >
>>
>> i'd still prefer that we include CONFIG_RT2800SOC, and if required
>> move rest of the registers to that check, because at least on my
>> hardware driver would still recognize chip as RT5390 despite the
>> RT6352 defines
>
> As I pointed before you should add additional printk's and provide
> dmesg to make us see what is going on.

sorry,my hardware is broken, maybe somebody else could provide us with
additional printks

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

On 12/10/2018, Stanislaw Gruszka  wrote:
> Please stop top-posting.
>
> On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
>> it will cause regression on other devices
>
> How exactly ?

the same way your wifi works without TX_SW_CFG entries and mine
doesn't, while both are RT6352

> On upstream tree where this patch is intended
> additional registers where never programmed as proper branch
> were never used, because of additional check in RT5390 branch.
>

on my hardware additional registers were programmed in regardless of
redundant check. that why i opened whole thread on forum since i
couldn't understand how's that happening

> Patch does only change TX_SW_CFG* regs values for RT6352.
>

i'd still prefer that we include CONFIG_RT2800SOC, and if required
move rest of the registers to that check, because at least on my
hardware driver would still recognize chip as RT5390 despite the
RT6352 defines

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

it will cause regression on other devices

On 12/10/2018, Stanislaw Gruszka  wrote:
> On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
>> chip version support exist in daniel's tree since a long time ago. so
>> don't disable registers initialization but try to upstream his
>> changes.
>
> I do not see reason for for blocking this change because some other
> changes are not unstreamed yet. When chip version support will
> be unstreamed, the register initialization will be unblocked.
>
> Regards.
> Stanislaw
>

Re: [PATCH v4 6/8] rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620

[Tom Psyborg]

is there some specific reason to read TX_PIN_CFG register on RT6352,
rather than just null it before programming in tx values like in other
chips?

On 12/10/2018, Stanislaw Gruszka  wrote:
> The TX_PIN_CFG_RFRX_EN bit was not set on other devices than MT7620,
> restore old behavaviour since setting this bit maight not be
> correct for older devices.
>
> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> Signed-off-by: Stanislaw Gruszka 
> ---
>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index bf0d12c5b2db..d0af0d9d2550 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -3856,10 +3856,12 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
>   if (rt2x00_rt(rt2x00dev, RT3572))
>   rt2800_rfcsr_write(rt2x00dev, 8, 0);
>
> - if (rt2x00_rt(rt2x00dev, RT6352))
> + if (rt2x00_rt(rt2x00dev, RT6352)) {
>   tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
> - else
> + rt2x00_set_field32(_pin, TX_PIN_CFG_RFRX_EN, 1);
> + } else {
>   tx_pin = 0;
> + }
>
>   switch (rt2x00dev->default_ant.tx_chain_num) {
>   case 3:
> @@ -3914,7 +3916,6 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
>
>   rt2x00_set_field32(_pin, TX_PIN_CFG_RFTR_EN, 1);
>   rt2x00_set_field32(_pin, TX_PIN_CFG_TRSW_EN, 1);
> - rt2x00_set_field32(_pin, TX_PIN_CFG_RFRX_EN, 1); /* mt7620 */
>
>   rt2800_register_write(rt2x00dev, TX_PIN_CFG, tx_pin);
>
> --
> 2.7.5
>
>

Re: [PATCH v4 4/8] rt2800: fix registers init for MT7620

[Tom Psyborg]

chip version support exist in daniel's tree since a long time ago. so
don't disable registers initialization but try to upstream his
changes.

changing TX_SW_CFG* entries did not make any noticeable difference in
my tests either, besides small RX improvement with configured
TX_SW_CFG2.

waiting for more of your test results

On 12/10/2018, Stanislaw Gruszka  wrote:
> There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
> causes we do not perform register initialization for RT6352 (MT7620
> SOCs) in correct branch. Fix this and disable registers initialization
> that is specific to particular MT7620 revision.
>
> Signed-off-by: Stanislaw Gruszka 
> ---
>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index daf20d7424ac..16d6d99b1d44 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -5451,8 +5451,7 @@ static int rt2800_init_registers(struct rt2x00_dev
> *rt2x00dev)
> 0x);
>   }
>   } else if (rt2x00_rt(rt2x00dev, RT5390) ||
> -rt2x00_rt(rt2x00dev, RT5392) ||
> -rt2x00_rt(rt2x00dev, RT6352)) {
> +rt2x00_rt(rt2x00dev, RT5392)) {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
> @@ -5466,6 +5465,10 @@ static int rt2800_init_registers(struct rt2x00_dev
> *rt2x00dev)
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0401);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x000C0408);
> + /* TODO add chip version support and init registers
> +  * according to the version.
> +  */
> +#if 0
>   rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
>   rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
>   rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
> @@ -5480,6 +5483,7 @@ static int rt2800_init_registers(struct rt2x00_dev
> *rt2x00dev)
>   reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_1);
>   rt2x00_set_field32(, TX_ALC_CFG_1_ROS_BUSY_EN, 0);
>   rt2800_register_write(rt2x00dev, TX_ALC_CFG_1, reg);
> +#endif
>   } else {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
> --
> 2.7.5
>
>

Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620

[Tom Psyborg]

so this is RX test where I assume your 7265 card is sending data. is
that HT20 or HT40 mode and do you get regression on TX too?

can you try same case 2 test but with registers set to:

TX_SW_CFG0, 0x0401
TX_SW_CFG1, 0x000C
TX_SW_CFG2, 0x (or 0x000C0408)

did you ever notice any tx power difference between nexx fw and openwrt fw?

On 11/10/2018, Stanislaw Gruszka  wrote:
> On Wed, Oct 10, 2018 at 10:03:12PM +0200, Tom Psyborg wrote:
>> ok, that is strange. do you see any performance differences without
>> TX_SW_CFG regs? iperf test is a good pointer.
>>
>> this was a problem on xiaomi mini with old DD trunk builds on 4.4
>> kernel and LEDE builds from last year. i ain't got no chance to try
>> this on 18.06. which device you tried this on? if ipa/ilna it might
>> make no difference
>
> No diffrence for me. I have nexx wt3020 8M.
>
> However I notice this set couse performance regression for me.
> When connecting to iwl 7265 . Without the set I have:
>
> root@LEDE:~# iperf3 -c 192.168.10.243
> Connecting to host 192.168.10.243, port 5201
> [  5] local 192.168.10.1 port 59304 connected to 192.168.10.243 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec  5.37 MBytes  44.9 Mbits/sec0279 KBytes
>
> [  5]   1.00-2.00   sec  5.80 MBytes  48.8 Mbits/sec0494 KBytes
>
> [  5]   2.00-3.00   sec  6.03 MBytes  50.5 Mbits/sec0513 KBytes
>
> [  5]   3.00-4.01   sec  5.90 MBytes  49.2 Mbits/sec0513 KBytes
>
> [  5]   4.01-5.01   sec  5.90 MBytes  49.5 Mbits/sec0515 KBytes
>
> [  5]   5.01-6.00   sec  5.78 MBytes  48.9 Mbits/sec0515 KBytes
>
> [  5]   6.00-7.00   sec  5.66 MBytes  47.4 Mbits/sec0515 KBytes
>
> [  5]   7.00-8.00   sec  6.03 MBytes  50.6 Mbits/sec0515 KBytes
>
> [  5]   8.00-9.00   sec  6.09 MBytes  50.9 Mbits/sec0515 KBytes
>
> [  5]   9.00-10.00  sec  5.72 MBytes  48.2 Mbits/sec0515 KBytes
>
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-10.00  sec  58.3 MBytes  48.9 Mbits/sec0
> sender
> [  5]   0.00-10.00  sec  58.3 MBytes  48.9 Mbits/sec
> receiver
>
> With the set I have:
>
> root@LEDE:~# iperf3  -c 192.168.10.243
> Connecting to host 192.168.10.243, port 5201
> [  5] local 192.168.10.1 port 45824 connected to 192.168.10.243 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec  3.78 MBytes  31.7 Mbits/sec0197 KBytes
> [  5]   1.00-2.00   sec  3.71 MBytes  31.0 Mbits/sec0369 KBytes
> [  5]   2.00-3.00   sec  3.51 MBytes  29.5 Mbits/sec0484 KBytes
> [  5]   3.00-4.00   sec  3.36 MBytes  28.1 Mbits/sec0519 KBytes
> [  5]   4.00-5.00   sec  4.10 MBytes  34.4 Mbits/sec0519 KBytes
> [  5]   5.00-6.00   sec  3.73 MBytes  31.2 Mbits/sec0519 KBytes
> [  5]   6.00-7.00   sec  4.29 MBytes  36.0 Mbits/sec0519 KBytes
> [  5]   7.00-8.00   sec  4.16 MBytes  34.9 Mbits/sec0519 KBytes
> [  5]   8.00-9.00   sec  4.35 MBytes  36.5 Mbits/sec0519 KBytes
> [  5]   9.00-10.00  sec  4.41 MBytes  37.0 Mbits/sec0519 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-10.00  sec  39.4 MBytes  33.0 Mbits/sec0
> sender
> [  5]   0.00-10.00  sec  39.4 MBytes  33.0 Mbits/sec
> receiver
>
>
> Stanislaw
>
>

Re: [PATCH 4/4] rt2800: comment and simplify AGC init for RT6352

[Tom Psyborg]

it's 6352 dude

On 10/10/2018, Stanislaw Gruszka  wrote:
> We do not need separate lines for calculating register values.
> Also add comment that value is different than in vendor driver.
>
> Suggested-by: Daniel Golle 
> Signed-off-by: Stanislaw Gruszka 
> ---
>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index a2cdd3a5034a..7b6effaa0740 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -3986,9 +3986,12 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
>   rt2800_bbp_write(rt2x00dev, 195, 141);
>   rt2800_bbp_write(rt2x00dev, 196, reg);
>
> - /* AGC init */
> - reg = rf->channel <= 14 ? 0x1c : 0x24;
> - reg += 2 * rt2x00dev->lna_gain;
> + /* AGC init.
> +  * Despite the vendor driver using different values here for
> +  * RT6362 chip, we use 0x1c for now. This may have to be changed
> +  * once TSSI got implemented.
> +  */
> + reg = (rf->channel <= 14 ? 0x1c : 0x24) + 2*rt2x00dev->lna_gain;
>   rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, reg);
>
>   rt2800_iq_calibrate(rt2x00dev, rf->channel);
> --
> 2.7.5
>
>

Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620

[Tom Psyborg]

ok, that is strange. do you see any performance differences without
TX_SW_CFG regs? iperf test is a good pointer.

this was a problem on xiaomi mini with old DD trunk builds on 4.4
kernel and LEDE builds from last year. i ain't got no chance to try
this on 18.06. which device you tried this on? if ipa/ilna it might
make no difference

On 10/10/2018, Stanislaw Gruszka  wrote:
> On Wed, Oct 10, 2018 at 04:11:12PM +0200, Tom Psyborg wrote:
>> case 1:
>>
>>  } else if (rt2x00_rt(rt2x00dev, RT5390) ||
>> rt2x00_rt(rt2x00dev, RT5392)) {
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
>>  } else if (rt2x00_rt(rt2x00dev, RT5592)) {
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x);
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
>>  } else if (rt2x00_rt(rt2x00dev, RT5350)) {
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>>  } else if (rt2x00_rt(rt2x00dev, RT6352)) {
>>  rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
>>  rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
>>  rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
>>  rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
>>  rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
>>  rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN, 0x6C6C666C);
>>  rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN, 0x6C6C666C);
>>
>> does your 6352 wifi work?
>>
>> case 2:
>>
>>  } else if (rt2x00_rt(rt2x00dev, RT5390) ||
>> rt2x00_rt(rt2x00dev, RT5392)) {
>>  } else if (rt2x00_rt(rt2x00dev, RT5592)) {
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x);
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
>>  } else if (rt2x00_rt(rt2x00dev, RT5350)) {
>>  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>>  } else if (rt2x00_rt(rt2x00dev, RT6352)) {
>>  rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
>>  rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
>>  rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
>>  rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
>>  rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
>>  rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN, 0x6C6C666C);
>>  rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN, 0x6C6C666C);
>>
>> does your 6352 wifi still work?
>
> I checked 'case 2' (on my 'rt2x00' branch on top of 'openwrt-18.06'):
>
> https://github.com/sgruszka/openwrt/commit/8abecc22605bd0221022673a3671201256cff72b
>
> wifi still does work on my MT7620 router with above change and print
> is correct.
>
> If it does not work for you, we have to figure this out. Maybe there are
> extra patches that broke things or there are some race conditions when
> setting "rt =" . Hard to tell. Perhaps you could provide dmesg
> from router where is does not work ?
>
> Thanks
> Stanislaw
>

Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620

[Tom Psyborg]

case 1:

} else if (rt2x00_rt(rt2x00dev, RT5390) ||
   rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
} else if (rt2x00_rt(rt2x00dev, RT5592)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
} else if (rt2x00_rt(rt2x00dev, RT5350)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
} else if (rt2x00_rt(rt2x00dev, RT6352)) {
rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN, 0x6C6C666C);
rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN, 0x6C6C666C);

does your 6352 wifi work?

case 2:

} else if (rt2x00_rt(rt2x00dev, RT5390) ||
   rt2x00_rt(rt2x00dev, RT5392)) {
} else if (rt2x00_rt(rt2x00dev, RT5592)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
} else if (rt2x00_rt(rt2x00dev, RT5350)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
} else if (rt2x00_rt(rt2x00dev, RT6352)) {
rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x0002);
rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN, 0x6C6C666C);
rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN, 0x6C6C666C);

does your 6352 wifi still work?


On 10/10/2018, Stanislaw Gruszka  wrote:
> Hello
>
> On Wed, Oct 10, 2018 at 02:06:58PM +0200, Daniel Golle wrote:
>> > > https://github.com/psyborg55/linux/commit/24b46d482590a87553df1de0b5c8032f363cb7cf
>> > >  ?
>> > >
>> > >  using this code to determine 7620 soc
>> > >
>> > >  if (rt == RT5390 && rt2x00_is_soc(rt2x00dev))
>> > >  rt = RT6352;
>> > >
>> > >  somehow did not work in rt2800_init_registers routine. i could
>> > > verify
>> > >  that by removing tx_sw_cfg registers from rt6352 and the wifi would
>> > >  still work, unless removed them from rt5390 also
>> >
>> > I tested by adding additional printk("Init RT6352 registers\n"); in
>> > if (rt2x00_rt(rt2x00dev, RT6352)) branch. The message was printed:
>> >
>> > [   68.049946] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 6352,
>> > rev 0500 detected
>> > [   68.065392] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 7620
>> > detected
>> > [   68.079777] ieee80211 phy0: Selected rate control algorithm
>> > 'minstrel_ht'
>> > [   68.177760] kmodloader: done loading kernel modules from
>> > /etc/modules.d/*
>> > [   68.825758] urandom_read: 5 callbacks suppressed
>> > [   68.825768] random: jshn: uninitialized urandom read (4 bytes read)
>> > [   77.792400] 8021q: adding VLAN 0 to HW filter on device eth0
>> > [   77.825045] br-lan: port 1(eth0.1) entered blocking state
>> > [   77.836032] br-lan: port 1(eth0.1) entered disabled state
>> > [   77.847156] device eth0.1 entered promiscuous mode
>> > [   77.856739] device eth0 entered promiscuous mode
>> > [   77.931043] br-lan: port 1(eth0.1) entered blocking state
>> > [   77.941861] br-lan: port 1(eth0.1) entered forwarding state
>> > [   77.953171] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
>> > [   78.849852] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes
>> > ready
>> > [   82.302306] Init RT6352 registers
>> >
>> > Perhaps rt2x00_is_soc(rt2x00dev) does not work on this particular
>> > system
>> > that you have and device is configured as RT5390 ? I.e. maybe this is
>> > PCIe device. This should be printed in :
>> >
>> > ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 6352, rev 0500
>> > detected
>> >
>> > line, you should have 'RT chipset 5390' instead.
>>
>> RT6352 is the pre-mediatek-merge name of MT7620A/N. It is always a SoC.
>> The RF part of both MT7620A and MT7620N identifies as RT5390. The
>> vendor driver also uses an equivalent check to destinguish between the
>> actual PCIe/USB RT5390xx and RT6352, see
>>
>> 

Re: [PATCH v3 4/4] rt2800: fix registers init for MT7620

[Tom Psyborg]

On 09/10/2018, Stanislaw Gruszka  wrote:
> There is dupliceted 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that couses
> we do not perform proper register initaliztion for RT6352 (MT7620 SOCs).
>
> Reported-by: Tomislav Požega 
> Signed-off-by: Stanislaw Gruszka 
> ---
>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index daf20d7424ac..170e7c87f7bc 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -5451,8 +5451,7 @@ static int rt2800_init_registers(struct rt2x00_dev
> *rt2x00dev)
> 0x);
>   }
>   } else if (rt2x00_rt(rt2x00dev, RT5390) ||
> -rt2x00_rt(rt2x00dev, RT5392) ||
> -rt2x00_rt(rt2x00dev, RT6352)) {
> +rt2x00_rt(rt2x00dev, RT5392)) {
>   rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x0404);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
>   rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x);
> --
> 2.7.5
>
>


have you got chance to test
https://github.com/psyborg55/linux/commit/24b46d482590a87553df1de0b5c8032f363cb7cf
 ?

 using this code to determine 7620 soc

 if (rt == RT5390 && rt2x00_is_soc(rt2x00dev))
 rt = RT6352;

 somehow did not work in rt2800_init_registers routine. i could verify
 that by removing tx_sw_cfg registers from rt6352 and the wifi would
 still work, unless removed them from rt5390 also

Re: [PATCH 1/5] rt2x00: set registers based on current band

[Tom Psyborg]

On 09/10/2018, Stanislaw Gruszka  wrote:
> Patches 3-5 looks ok to me, I'll rebase and resend them.
>
> Thanks
> Stanislaw
>

and what about patches 1-2 ? did you find any regression?

Re: [PATCH 1/5] rt2x00: set registers based on current band

[Tom Psyborg]

On 19/09/2018, Stanislaw Gruszka  wrote:
> On Wed, Sep 19, 2018 at 02:47:18PM +0200, Stanislaw Gruszka wrote:
>> > Can you show us how will the problem trigger on dual band devices?
>>
>> When you switch from some 2.4GHz channel to 5GHz channel (or vice versa)
>> ->curr_band will point to old band not the new one. To fix that you
>> have to move curr_band assignemt before ->config() in
>> rt2x00lib_config() i.e:
>>
>> rt2x00dev->curr_band = conf->chandef.chan->band;
>> rt2x00dev->ops->lib->config(rt2x00dev, , ieee80211_flags);
>>
>> However I do not see the point of replacyng rf->channel check
>> to ->curr_band check. What you can do is oposite thing, replace
>> wrong usage of ->curr_band in very few places in rt2800_config()
>> subroutines to rf->channel check.
>
> Actually ->curr_band is used in rt2800_config_ant() subroutines
> not in rt2800_config() subroutines so things looks ok.
>
> Stanislaw
>

Things should be ok, still if you have some of these cards, it'd be
better to verify that.
At least my MS150N usb card would panic when I did the very same
change in rf53xx channel config, probably because of the way the
btcoex idx value has been set.
Luckily I figured that chipset is single-band only and the patch3 was
enough to handle that:
https://www.spinics.net/lists/linux-wireless/msg177430.html

Re: [PATCH 0/5] ath9k: FFT fixes and improvements

[Tom Psyborg]

compiles OK, no interfere with normal card operations (IBSS) so it
should be merged.

On 19/09/2018, Simon Wunderlich  wrote:
> During FFT evaluation on an AR9462 adapter, we noticed that there were
> way less FFT samples received than we would expect. This patchset adds
> some counters to be able to check for received (and discarded) FFT
> samples, and fixes a variety of issues I found while debugging.
>
> Cheers,
>  Simon
>
> Simon Wunderlich (5):
>   ath9k: add counters for good and errorneous FFT/spectral frames
>   ath9k: return when short FFT frame was handled
>   ath9k: fix and simplify FFT max index retrieval
>   ath9k: FFT magnitude check: don't consider lower 3 data bits
>   ath9k: fix reporting calculated new FFT upper max
>
>  drivers/net/wireless/ath/ath9k/common-debug.c|  2 +
>  drivers/net/wireless/ath/ath9k/common-debug.h|  4 ++
>  drivers/net/wireless/ath/ath9k/common-spectral.c | 83
> +---
>  drivers/net/wireless/ath/ath9k/common-spectral.h | 17 +
>  4 files changed, 55 insertions(+), 51 deletions(-)
>
> --
> 2.11.0
>
>

Re: ath9k and 16 VAP interfaces?

[Tom Psyborg]

this is how i enabled it on htc target:
https://github.com/torvalds/linux/pull/574

On 30 July 2018 at 16:34, Ben Greear  wrote:

>
>
> On 07/30/2018 04:13 AM, Matthias May wrote:
>
>> On 30/07/18 11:40, michael-...@fami-braun.de wrote:
>>
>>> Do you mean AP interfaces as required for multiple BSS/SSIDs?
>>>
>>> I'm running a patched ath9k to have hostapd run >8 BSS on a single radio.
>>> It works fine since years.
>>>
>>
> Yes, I'd love to see any patches you can share on this as well.
>
> Thanks,
> Ben
>
>
>
>>> Regards,
>>> M. Braun
>>>
>>>
>>> Am 27. Juli 2018 15:35:28 MESZ schrieb Ben Greear <
>>> gree...@candelatech.com>:
>>>
 Hello,

 Has anyone tried making ath9k able to support 16 vAP interfaces on a
 single
 radio?  I seem to recall that there were limitations regarding beacon
 timers and such, and that is why the current limit is 8?

 Thanks,
 Ben

 --
 Ben Greear 
 Candela Technologies Inc  http://www.candelatech.com

>>>
>>>
>> Are these patches available somewhere?
>> I'm interested to play with them :)
>>
>> BR
>> Matthias
>>
>>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>

ath9k_htc: ANI debug with RX errors output

[Tom Psyborg]

Hi

Doing some throughput tests I've noticed there are many CCK errors which
mainly occur while receiving data. OFDM errors counted are far less in
numbers than CCK ones, also appearing more often while receiving data. When
transmitting data, the amount of these errors is almost insignificant.

debug output:

ANI: ENABLED
ANI RESET: 82
OFDM LEVEL: 0
CCK LEVEL: 0
SPUR UP: 0
SPUR DOWN: 0
OFDM WS-DET ON: 0
OFDM WS-DET OFF: 0
MRC-CCK ON: 0
MRC-CCK OFF: 0
FIR-STEP UP: 485
FIR-STEP DOWN: 487
INV LISTENTIME: 0
OFDM ERRORS: 83944
CCK ERRORS: 1119852

While receiving data at 16Mbps CCK LEVEL was 0, receiving data at
24Mbps CCK LEVEL was 8! Transmitting data at 24Mbps CCK LEVEL was 0, but
receiving at 16Mbps and transmitting at 8Mbps CCK LEVEL was again 8! Does
that mean the remote AP is creating a lot of CCK noise for some reason? It
does run in g-only mode and OFDM levels stayed at 0 during whole time of
data transfers.

How efficient it would be to patch htc driver so it runs in OFDM mode only?

Re: ath9k and 16 VAP interfaces?

[Tom Psyborg]

some people claim it is hardware limit

On 27 July 2018 at 15:35, Ben Greear  wrote:

> Hello,
>
> Has anyone tried making ath9k able to support 16 vAP interfaces on a single
> radio?  I seem to recall that there were limitations regarding beacon
> timers and such, and that is why the current limit is 8?
>
> Thanks,
> Ben
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>

Re: mt76x2e MCU message 31 timed out

[Tom Psyborg]

Do they sell dual-band version with ext amplifiers? I saw there is
5GHz version with 25dBm power modification...

On 22/06/2018, Janusz Dziedzic  wrote:
> 2018-06-22 16:48 GMT+02:00 Stanislaw Gruszka :
>> Hi
>>
>> On Fri, Jun 22, 2018 at 10:37:35AM +0200, Janusz Dziedzic wrote:
>>> Have this card in my laptop:
>>> 02:00.0 Network controller: MEDIATEK Corp. Device 7612
>>>
>>> [8.478104] mt76x2e :02:00.0: ASIC revision: 76120044
>>> [8.489582] mt76x2e :02:00.0: ROM patch already applied
>>> [8.833476] mt76x2e :02:00.0: Firmware Version: 0.0.00
>>> [8.833477] mt76x2e :02:00.0: Build: 1
>>> [8.833479] mt76x2e :02:00.0: Build Time: 201507311614
>>> [8.856115] mt76x2e :02:00.0: Firmware running!
>>> [9.558075] mt76x2e :02:00.0 wlp2s0: renamed from wlan1
>>
>> I'm just curious. Does the card was installed in the laptop by default?
>> If so what is the model of the laptop?
>>
> No, I just buy this card on aliexpress and put into some dell (MTK
> MT7612 2x2 half miniPCIE).
>
>>> Linux test4 4.17.0-rc7+ #5 SMP Mon May 28 12:35:22 CEST 2018 x86_64
>>> GNU/Linux
>>>
>>> Seems iw scan works correctly and first assoc. After will run some
>>> traffic (iperf in such case) get:
>>>
>>> [  432.372081] wlp2s0: associate with 52:b4:f7:f0:16:c2 (try 2/3)
>>> [  432.375255] wlp2s0: RX AssocResp from 52:b4:f7:f0:16:c2
>>> (capab=0x511 status=0 aid=2)
>>> [  432.375336] wlp2s0: associated
>>> [  432.451097] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
>>> [  522.562157] mt76x2e :02:00.0: MCU message 31 (seq 13) timed out
>>> [  524.610281] mt76x2e :02:00.0: MCU message 31 (seq 14) timed out
>>> [  526.658384] mt76x2e :02:00.0: MCU message 31 (seq 15) timed out
>>> [  528.258455] mt76x2e :02:00.0: MCU message 30 (seq 1) timed out
>>> [  529.282499] mt76x2e :02:00.0: MCU message 30 (seq 2) timed out
>>> [  530.402544] mt76x2e :02:00.0: MCU message 30 (seq 3) timed out
>>> [  531.426587] mt76x2e :02:00.0: MCU message 30 (seq 4) timed out
>>> [  531.427444] wlp2s0: authenticate with 52:b4:f7:f0:14:ac
>>> [  532.450624] mt76x2e :02:00.0: MCU message 30 (seq 5) timed out
>>> [  533.474666] mt76x2e :02:00.0: MCU message 30 (seq 6) timed out
>>> [  534.498709] mt76x2e :02:00.0: MCU message 30 (seq 7) timed out
>>> [  535.522736] mt76x2e :02:00.0: MCU message 30 (seq 8) timed out
>>> [  535.522807] wlp2s0: send auth to 52:b4:f7:f0:14:ac (try 1/3)
>>> [  535.726740] wlp2s0: send auth to 52:b4:f7:f0:14:ac (try 2/3)
>>> [  535.930742] wlp2s0: send auth to 52:b4:f7:f0:14:ac (try 3/3)
>>> [  536.134747] wlp2s0: authentication with 52:b4:f7:f0:14:ac timed out
>>
>> I observed quite similar issue on some rt2800 devices when
>> I applied  this patch:
>> https://github.com/sgruszka/wireless-drivers-next/commit/846d205edd8c36d1b7828fee54bf4cf40bf8cb1a
>> It works on some devices and does not work on others with similar
>> symptoms - correctly associate but stop to work as soon as some
>> data traffic is performed.
>>
>> So, I would check if send IEEE80211_TX_CTL_RATE_CTRL_PROBE frames
>> with qsel = MT_QSEL_EDCA would help.
>>
> Thanks, will check this.
>
>> Another thing to try is checkout vendor driver and see if there is need
>> to add extra code if device is_mt7612() .
>>
>> Regards
>> Stanislaw
>
>
>
> --
> Janusz Dziedzic
>

Re: Atheros AR9462 - 5Ghz not working

[Tom Psyborg]

with mPCIe version i got one could only read eeprom but not write, or
the information presented were wrong..

On 21/06/2018, mgre...@cinci.rr.com  wrote:
>
>  Arend van Spriel  wrote:
>> + Martin
>>
>> On 6/18/2018 3:53 PM, mgre...@cinci.rr.com wrote:
>> >
>> >  Tom Psyborg  wrote:
>> >> Hi
>> >>
>> >> Your log only show attemps on ch 2447, Can you try connecting to 5GHz
>> >> AP? Connect to Hidden Wireless Network option at the bottom of the
>> >> nm-applet? Running airodump in monitor mode to see if it captures
>> >> anything? Maybe your laptop's antennas were designed for 2.4G card
>> >> only but this just dumb guessing...
>> >>
>> >
>> > It won't connect to any 5GHz AP.
>> > I don't run network manager or Gnome, in fact X11 is not installed on
>> > this machine at all.
>> > I don't think there is such a thing as 2.4GHz vs 5GHz antennas.
>>
>> Actually there is. At least there are 2.4G specific antennas and
>> dual-band antennas.
>>
>> In 4.11 there have been a couple eeprom related changes dealing with
>> endianness of fields in eeprom. Could be those cause a regression for
>> you. I don't have the exact sha id of those commits, but I added the
>> author to this thread.
>>
>> Regards,
>> Arend
>>
>
> An interesting new development:
>
> I've confirmed it's not the antenna as I was able to acquire some more cards
> from a different source which work fine.
>
> Ostensibly they are the same card:  Atheros AR9462 : QCNFA222 reference
> design.
>
> The output from lspci for both working and non-working cards is: "03:00.0
> Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter".
>
> However the Subsystem listed in lspci is different. I don't have the exact
> value at the moment for the working cards, but it lists Dell and the part
> number DW1802. The non-working cards are AzureWave.
>
> I've seen a lot of similar cards on ebay that I suspect are the AzureWave. A
> few offers on ebay are for the genuine Dell parts.
>
> What would be the best way to compare and contrast these cards to determine
> if there is a way to make them work?
>
> Inspect EEPROM? Someone previously mentioned calibration data, but I have no
> idea if it's possible to inspect or alter that.
>

Re: [PATCH 2/2] rt2x00: check against flushing empty queue

[Tom Psyborg]

does it fix mt7620 bug?

On 02/05/2018, Stanislaw Gruszka  wrote:
> Hi
>
> On Tue, May 01, 2018 at 06:27:17AM -0600, Kofi Agor wrote:
>> I haven't had a chance to test your patch yet, but does it resolve the tx
>> queue flush issues? What platform are you developing/testing on?
>
> I'm not sure about the issue, but most likely the patch
> does not fix it. I tested the patch on RT3062 pcie device an
> RT3071 usb dongle.
>
> Regards
> Stanislaw
>

Re: Atheros AR9462 - 5Ghz not working

[Tom Psyborg]

Hi

Your log only show attemps on ch 2447, Can you try connecting to 5GHz
AP? Connect to Hidden Wireless Network option at the bottom of the
nm-applet? Running airodump in monitor mode to see if it captures
anything? Maybe your laptop's antennas were designed for 2.4G card
only but this just dumb guessing...

On 17/06/2018, mgre...@cinci.rr.com  wrote:
>
>  "Michał Kazior"  wrote:
>> On 15 June 2018 at 19:23,   wrote:
>> >  mgre...@cinci.rr.com wrote:
>> >>  "Michał Kazior"  wrote:
>> >> > Your noise floor readout in survey dump is terribly bad for 5GHz. It
>> >> > ain't stellar for 2.4GHz either but within reason nonetheless.
>> >> >
>> >> > Did you try using the card in a different device? I wonder if the
>> >> > device you're trying to use it in has some sort of internal noise on
>> >> > those frequencies and/or ath9k's ANI isn't able to deal with it.
>> >> >
>> >> >
>> >> > Michał
>> >> >
>> >> > On 15 June 2018 at 15:31,   wrote:
>> >>
>> >> I did.
>> >> I took it out of the Penguin-Z notebook and put it in a Dell XPS15 9560
>> >> running Windows 10. Only 2.4Ghz networks were visible from there as
>> >> well. Not exactly apples-to-apples, but consistent results.
>>
>> This reduces likeliness this is tied to a os/driver issue. Maybe
>> calibration data on the device eeprom is broken? Or maybe it's a
>> hardware defect?
>
>
>
>
> I have three of these cards all with the same problem, so if it's a hardware
> defect then it's pretty much game over and these cards are all useless.
> Forgive my ignorance, but is there any way to check/fix calibration data?
>
>
>
>
>>
>>
>> > Could it be antenna related (in multiple devices)?
>>
>> Antennas can be designed to work better on certain frequency ranges. I
>> wouldn't expect such a dramatic effect though.
>>
>>
>> > On wikidevi.com I see some M.2 cards listed with an antenna connector of
>> > U.FL and others with MHF4. I can't find anything describing the
>> > difference, if any. The connectors seemed to fit OK. Also, what's the
>> > deal with 'main' and 'aux' antenna connectors? I've seen people suggest
>> > swapping them has helped in some cases with poor signal, while others
>> > insist that it makes no difference. I have not tried swapping the
>> > connectors.
>>
>> I think it's not a connector problem because 2.4GHz scan results
>> report reasonable signal strength for found APs (-60dBm). My
>> experience is that if you use a wrong (but seemingly fitting)
>> connector you'd get near 0 results or below -90dBm across the board.
>>
>>
>> Michał
>
>