Bug 202243 - mt76x0u doesn't transmit / receive 802.11 frames using a TP-LINK Archer T2UH
Summary: mt76x0u doesn't transmit / receive 802.11 frames using a TP-LINK Archer T2UH
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-12 10:23 UTC by Michael
Modified: 2019-01-25 15:39 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.20
Tree: Mainline
Regression: Yes


Attachments
0001-mt76x0-do-not-overwrite-other-MT_BBP-AGC-8-fields.patch (1.48 KB, text/plain)
2019-01-14 17:27 UTC, Stanislaw Gruszka
Details
0002-mt76x0-use-band-parameter-for-LC-calibration.patch (2.29 KB, text/plain)
2019-01-14 17:27 UTC, Stanislaw Gruszka
Details
0003-mt76x02-run-calibration-after-scanning.patch (4.14 KB, text/plain)
2019-01-14 17:28 UTC, Stanislaw Gruszka
Details
0004-mt76x02-assure-we-update-gain-after-scan.patch (2.10 KB, text/plain)
2019-01-15 12:27 UTC, Stanislaw Gruszka
Details
0005-mt76x0-do-not-perform-MCU-calibration-for-MT7630.patch (1.85 KB, text/plain)
2019-01-15 12:28 UTC, Stanislaw Gruszka
Details
0006-mt76x0-antenna-select-corrections.patc (4.77 KB, text/plain)
2019-01-15 12:28 UTC, Stanislaw Gruszka
Details
txpower.patch (756 bytes, text/plain)
2019-01-17 14:37 UTC, Stanislaw Gruszka
Details
phy_calibrate.patch (1.97 KB, text/plain)
2019-01-18 14:07 UTC, Stanislaw Gruszka
Details
0001-mt76x0-always-set-tx-power-when-switch-channel.patch (1.50 KB, text/plain)
2019-01-22 13:01 UTC, Stanislaw Gruszka
Details

Description Michael 2019-01-12 10:23:33 UTC
mt76x0u doesn't work like expeted in combination with a WiFi dongle TP-LINK Archer T2UH.

$ lsusb
Bus 001 Device 007: ID 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN 

The device is detected correctly and the firmware is loaded:

$ dmesg
[ 132.682145] usb 1-3: new high-speed USB device number 7 using xhci_hcd
[ 132.838532] usb 1-3: New USB device found, idVendor=148f, idProduct=761a, bcdDevice= 1.00
[ 132.838543] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 132.838550] usb 1-3: Product: WiFi
[ 132.838557] usb 1-3: Manufacturer: MediaTek
[ 132.838563] usb 1-3: SerialNumber: 1.0
[ 133.406147] usb 1-3: reset high-speed USB device number 7 using xhci_hcd
[ 133.557810] mt76x0u 1-3:1.0: ASIC revision: 76100002 MAC revision: 76502000
[ 134.589471] mt76x0u 1-3:1.0: EEPROM ver:02 fae:01
[ 134.593977] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 134.594305] usbcore: registered new interface driver mt76x0u
[ 134.627225] mt76x0u 1-3:1.0 wlp0s20f0u3: renamed from wlan0

The dongle is shown in NetworkManager list and iw can be used to control it or to retrieve device informations.
Unfortunately it doesn't receive and transmit any traffic.
iw scan list remains empty.

It would be nice to have a fix for this issue, because it is one of the first AC drivers and the TP-LINK Archer T2UH is a really good device.


Remarks:
I decided to report this issue separate, because it isn't related to this one:
https://bugzilla.kernel.org/show_bug.cgi?id=202241

you can read more here:
https://github.com/ZerBea/hcxdumptool/issues/42#issuecomment-453474156



BTW:
in usb.c is still the old name of the device:
	{ USB_DEVICE(0x148f, 0x761a) },	/* TP-Link TL-WDN5200 */

https://wikidevi.com/wiki/TP-LINK_TL-WDN5200
https://wikidevi.com/wiki/TP-LINK_Archer_T2UH

Best regards
Mike
Comment 1 Michael 2019-01-12 18:10:43 UTC
BTW:
After plug in, interface is down and must be set up:

$ iw dev
phy#0
	Interface wlp39s0f3u4u1
		ifindex 3
		wdev 0x1
		addr 50:3e:aa:92:e3:26
		type managed
		txpower 0.00 dBm

$ sudo iw wlp39s0f3u4u1 scan
command failed: Network is down (-100)

$ sudo ip link set wlp39s0f3u4u1 up

$ sudo iw wlp39s0f3u4u1 scan
$ 

scan list is empty
Comment 2 Stanislaw Gruszka 2019-01-14 10:03:47 UTC
There are several bugs introduced in 4.20 for MT7610U . They should be now fixed in 5.0-rc1. Please try 5.0-rc1 to confirm the issue you have is now fixed. (I'm going to request patches to be included in 4.20.x stable ). You can also try 4.19.
Comment 3 Michael 2019-01-14 11:08:51 UTC
Tested 4.19.15 and can confirm that the device is working like expected.
iw showing scan results and hcxdumptool stress test is working, too.
Monitor mode works like a charm. It's nice to see a "modern WiFi driver" with enabled monitor mode inside the kernel. 

Will compile 5.0-rc2 right after I got an answer from the iommu folks
(https://bugzilla.kernel.org/show_bug.cgi?id=202241).

Thanks
Mike
Comment 4 Stanislaw Gruszka 2019-01-14 17:26:22 UTC
I'm going to post 3 patches to 4.20-stable. I'll attach them. Please apply them on top of 4.20 and check if they fix the problem for you.
Comment 5 Stanislaw Gruszka 2019-01-14 17:27:03 UTC
Created attachment 280463 [details]
0001-mt76x0-do-not-overwrite-other-MT_BBP-AGC-8-fields.patch
Comment 6 Stanislaw Gruszka 2019-01-14 17:27:35 UTC
Created attachment 280465 [details]
0002-mt76x0-use-band-parameter-for-LC-calibration.patch
Comment 7 Stanislaw Gruszka 2019-01-14 17:28:08 UTC
Created attachment 280467 [details]
0003-mt76x02-run-calibration-after-scanning.patch
Comment 8 Michael 2019-01-14 19:13:05 UTC
Applied the 3 patches on top of 4.20.2, but issue still isn't solved.
Interface is not up, when pluged in
NetworkManager AP list is empty
iw scan list is empty
hcxdumptool rcascan list is empty


plug in:
[  503.247433] usb 1-3: new high-speed USB device number 8 using xhci_hcd
[  503.403905] usb 1-3: New USB device found, idVendor=148f, idProduct=761a, bcdDevice= 1.00
[  503.403917] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  503.403923] usb 1-3: Product: WiFi
[  503.403931] usb 1-3: Manufacturer: MediaTek
[  503.403936] usb 1-3: SerialNumber: 1.0
[  503.531384] usb 1-3: reset high-speed USB device number 8 using xhci_hcd
[  503.681269] mt76x0u 1-3:1.0: ASIC revision: 76100002 MAC revision: 76502000
[  504.623518] mt76x0u 1-3:1.0: EEPROM ver:02 fae:01
[  504.629482] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
[  504.640381] mt76x0u 1-3:1.0 wlp0s20f0u3: renamed from wlan0
[  504.657198] IPv6: ADDRCONF(NETDEV_UP): wlp0s20f0u3: link is not ready
[  504.685467] IPv6: ADDRCONF(NETDEV_UP): wlp0s20f0u3: link is not ready
[  504.712203] IPv6: ADDRCONF(NETDEV_UP): wlp0s20f0u3: link is not ready
[  504.761283] IPv6: ADDRCONF(NETDEV_UP): wlp0s20f0u3: link is not ready

scan:
$ iw wlp0s20f0u3 scan
command failed: Network is down (-100)

$ ip link set wlp0s20f0u3 up
$ sudo iw wlp39s0f3u4u1 scan
$ 

but we have txpower, now:
$ iw dev
phy#3
	Interface wlp0s20f0u3
		ifindex 6
		wdev 0x300000001
		addr be:87:2a:5c:5a:ca
		type managed
		txpower 20.00 dBm


we can retrieve interface information:
$ iw list
Wiphy phy3
	max # scan SSIDs: 4
	max scan IEs length: 2243 bytes
	max # sched scan SSIDs: 0
	max # match sets: 0
	max # scan plans: 1
	max scan plan interval: -1
	max scan plan iterations: 0
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports RSN-IBSS.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CCMP-256 (00-0f-ac:10)
		* GCMP-128 (00-0f-ac:8)
		* GCMP-256 (00-0f-ac:9)
		* CMAC (00-0f-ac:6)
		* CMAC-256 (00-0f-ac:13)
		* GMAC-128 (00-0f-ac:11)
		* GMAC-256 (00-0f-ac:12)
	Available Antennas: TX 0x1 RX 0x1
	Supported interface modes:
		 * managed
		 * monitor
	Band 1:
		Capabilities: 0x17e
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 4 usec (0x05)
		HT TX/RX MCS rate indexes supported: 0-7
		Bitrates (non-HT):
			* 1.0 Mbps (short preamble supported)
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (20.0 dBm)
			* 2417 MHz [2] (20.0 dBm)
			* 2422 MHz [3] (20.0 dBm)
			* 2427 MHz [4] (20.0 dBm)
			* 2432 MHz [5] (20.0 dBm)
			* 2437 MHz [6] (20.0 dBm)
			* 2442 MHz [7] (20.0 dBm)
			* 2447 MHz [8] (20.0 dBm)
			* 2452 MHz [9] (20.0 dBm)
			* 2457 MHz [10] (20.0 dBm)
			* 2462 MHz [11] (20.0 dBm)
			* 2467 MHz [12] (20.0 dBm)
			* 2472 MHz [13] (20.0 dBm)
			* 2484 MHz [14] (disabled)
	Band 2:
		Capabilities: 0x17e
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 4 usec (0x05)
		HT TX/RX MCS rate indexes supported: 0-7
		VHT Capabilities (0x01800120):
			Max MPDU length: 3895
			Supported Channel Width: neither 160 nor 80+80
			short GI (80 MHz)
		VHT RX MCS set:
			1 streams: MCS 0-7
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-7
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 Mbps
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 5180 MHz [36] (23.0 dBm)
			* 5200 MHz [40] (23.0 dBm)
			* 5220 MHz [44] (23.0 dBm)
			* 5240 MHz [48] (23.0 dBm)
			* 5260 MHz [52] (20.0 dBm) (radar detection)
			* 5280 MHz [56] (20.0 dBm) (radar detection)
			* 5300 MHz [60] (20.0 dBm) (radar detection)
			* 5320 MHz [64] (20.0 dBm) (radar detection)
			* 5500 MHz [100] (26.0 dBm) (radar detection)
			* 5520 MHz [104] (26.0 dBm) (radar detection)
			* 5540 MHz [108] (26.0 dBm) (radar detection)
			* 5560 MHz [112] (26.0 dBm) (radar detection)
			* 5580 MHz [116] (26.0 dBm) (radar detection)
			* 5600 MHz [120] (26.0 dBm) (radar detection)
			* 5620 MHz [124] (26.0 dBm) (radar detection)
			* 5640 MHz [128] (26.0 dBm) (radar detection)
			* 5660 MHz [132] (26.0 dBm) (radar detection)
			* 5680 MHz [136] (26.0 dBm) (radar detection)
			* 5700 MHz [140] (26.0 dBm) (radar detection)
			* 5745 MHz [149] (13.0 dBm)
			* 5765 MHz [153] (13.0 dBm)
			* 5785 MHz [157] (13.0 dBm)
			* 5805 MHz [161] (13.0 dBm)
			* 5825 MHz [165] (13.0 dBm)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * new_station
		 * new_mpath
		 * set_mesh_config
		 * set_bss
		 * authenticate
		 * associate
		 * deauthenticate
		 * disassociate
		 * join_ibss
		 * join_mesh
		 * set_tx_bitrate_mask
		 * frame
		 * frame_wait_cancel
		 * set_wiphy_netns
		 * set_channel
		 * set_wds_peer
		 * probe_client
		 * set_noack_map
		 * register_beacons
		 * start_p2p_device
		 * set_mcast_rate
		 * connect
		 * disconnect
		 * set_qos_map
		 * set_multicast_to_unicast
	Supported TX frame types:
		 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * IBSS: 0x40 0xb0 0xc0 0xd0
		 * managed: 0x40 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * mesh point: 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	software interface modes (can always be added):
		 * monitor
	interface combinations are not supported
	HT Capability overrides:
		 * MCS: ff ff ff ff ff ff ff ff ff ff
		 * maximum A-MSDU length
		 * supported channel width
		 * short GI for 40 MHz
		 * max A-MPDU length exponent
		 * min MPDU start spacing
	Device supports TX status socket option.
	Device supports HT-IBSS.
	Device supports SAE with AUTHENTICATE command
	Device supports low priority scan.
	Device supports scan flush.
	Device supports AP scan.
	Device supports per-vif TX power setting
	Driver supports full state transitions for AP/GO clients
	Driver supports a userspace MPM
	Device supports active monitor (which will ACK incoming frames)
	Device supports configuring vdev MAC-addr on create.


we can set interface to monitor mode:
$ iw dev wlp0s20f0u3 set type monitor
Interface wlp0s20f0u3
	ifindex 6
	wdev 0x300000001
	addr 2a:d4:73:39:2e:c9
	type monitor
	wiphy 3
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm

and we can set channels and verify that the channels are really set:
$ hcxdumptool -i wlp0s20f0u3 -C
initialization...
available channels:
1,2,3,4,5,6,7,8,9,10,11,12,13,14,36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,149,153,157,161,165
Comment 9 Michael 2019-01-15 08:09:58 UTC
Some good news:
Just compiled the 5.0-rc2 kernel and run some tests. I can confirm that the driver is working, like expected:

NetworkManager scan list - ok
iw scan list - ok
hcxdumptool packet injection - ok

Also I compiled the 5.0-rc2 included driver for 4.20.1 and can confirm that the driver is working, too

NetworkManager scan list - ok
iw scan list - ok
hcxdumptool packet injection - ok
Comment 10 Michael 2019-01-15 08:17:17 UTC
$ hcxdumptool -i wlp0s20f0u3 --do_rcascan

INFO: cha=6, rx=632, rx(dropped)=0, tx=33, err=0, aps=8
^C
terminated...

tx/rx working like expected.
Comment 11 Michael 2019-01-15 10:43:27 UTC
Shall we set "Regression" to yes, because it only affects 4.20?
Comment 12 Stanislaw Gruszka 2019-01-15 11:44:29 UTC
It's regression. We need to identify patches that are needed for 4.20.x . I'll provide you some more patches to test...
Comment 13 Stanislaw Gruszka 2019-01-15 12:27:55 UTC
Created attachment 280489 [details]
0004-mt76x02-assure-we-update-gain-after-scan.patch
Comment 14 Stanislaw Gruszka 2019-01-15 12:28:20 UTC
Created attachment 280491 [details]
0005-mt76x0-do-not-perform-MCU-calibration-for-MT7630.patch
Comment 15 Stanislaw Gruszka 2019-01-15 12:28:46 UTC
Created attachment 280493 [details]
0006-mt76x0-antenna-select-corrections.patc
Comment 16 Stanislaw Gruszka 2019-01-15 12:29:41 UTC
Please test all 6 patches on top of 4.20.2.
Comment 17 Michael 2019-01-15 15:42:43 UTC
Applied all 6 patches on top of 4.20.2
Scan lists from iw, NetworkManager and hcxdumptool are still empty
but
interface is now up after plugged in.
So we have this two issues fixed, now:
iw dev shows tx power
interface is no longer down, when plugged in

BTW:
This issue still exists in every tested version:
https://bugzilla.kernel.org/show_bug.cgi?id=202241
but I haven't receive a response from the iommu folks, yet
So all of the above tests running on an INTEL core system.
Comment 18 Stanislaw Gruszka 2019-01-15 15:49:15 UTC
Ok, let me check if I can identify some more fixes ... (FTR: my device work well after applying first 3 patches, so can not reproduce this issue by myself) .

For IOMMU issue there are some patches ongoing:
https://marc.info/?l=linux-wireless&m=154755566820071&w=2
You can check them out.
Comment 19 Michael 2019-01-15 16:12:03 UTC
Some additional infos about the test systems:
INTEL and AMD core systems are running Arch Linux.
For 5.0-rc2 tests, I'm using the Arch Linux kernel config from 4.20 and answered all NEW with NO. That's ok, because we do not want to test new functions here.
Firmware is 20181218.0f22c85-1 and should be up to date, too.
XFCE desktop without frills (all systems optimized for speed).


BTW:
1) May I ask, which device do you use? 

2) In this early test stage, I noticed that hcxdumptool doesn't crash the mt76x0u driver, yet - like it does on the rt2800usb driver. The rt2800usb stops receiving and transmitting packets under heavy load (that seems to be a known bug - I read several comments about this issue). So, I really like your work on mt76.

3) It's good to see that iommu will receive some patches, too.
Comment 20 Michael 2019-01-16 10:14:26 UTC
Running more tests on the patched 4.20.2 driver and noticed that the transmit branch is working (we got a signal on a spectrum analyzer) on the selected channel. Tried this using BROADCAST beacons and BROADCAST proberequests.
The frames are delivered via raw packet socket to the driver and transmitted by the device correctly.
Interface wlp0s20f0u3
	ifindex 4
	wdev 0x100000001
	addr 3a:75:51:e5:83:ec
	type monitor
	wiphy 1
	channel 10 (2457 MHz), width: 20 MHz (no HT), center1: 2457 MHz
	txpower 20.00 dBm


$ sudo hcxdumptool -i wlp0s20f0u3 --enable_status=1 -c 10
initialization...

start capturing (stop with ctrl+c)
INTERFACE:...............: wlp0s20f0u3
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: e00db9002770
MAC ACCESS POINT.........: 000e2acaeb79 (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 63101
ANONCE...................: 90b40913d9d4dc21eeac7265281270c8c15f7ff5370ccb35bdc0688f9df3ed2e

INFO: cha=10, rx=0, rx(dropped)=0, tx=450, powned=0, err=0^C
terminated...

So we have only a remaining issue in the receiving branch.


BTW:
looks like we have a new problem (reduced txpower) with the 5.0 driver:

4.20 (patched driver):
Interface wlp0s20f0u3
	ifindex 4
	wdev 0x100000001
	addr 3a:75:51:e5:83:ec
	type monitor
	wiphy 1
	channel 10 (2457 MHz), width: 20 MHz (no HT), center1: 2457 MHz
	txpower 20.00 dBm


5.0 driver:
Interface wlp0s20f0u3
	ifindex 4
	wdev 0x100000001
	addr 72:0a:4b:3f:f6:61
	type monitor
	wiphy 1
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 16.00 dBm
Comment 21 Stanislaw Gruszka 2019-01-16 11:52:35 UTC
(In reply to Michael from comment #19)
> BTW:
> 1) May I ask, which device do you use? 
Asus AC51

> 2) In this early test stage, I noticed that hcxdumptool doesn't crash the
> mt76x0u driver, yet - like it does on the rt2800usb driver. The rt2800usb
> stops receiving and transmitting packets under heavy load (that seems to be
> a known bug - I read several comments about this issue). So, I really like
> your work on mt76.

I'm also rt2800 maintainer :-) I think most of rt2800usb devices work pretty decent, but never tested with hcxdumptool
Comment 22 Stanislaw Gruszka 2019-01-16 12:05:23 UTC
Unfortunately I'm not able to identify a fix . I suspect those but not sure:

1163bdb636a1 mt76x0: phy: unify calibration between mt76x0u and mt76x0
cac97ed681db mt76x2: align mt76x2 and mt76x2u firmware

Can you perform something like manual bisection on mt76 driver (like on instructions below) ? 

On linux git tree switch to v4.20 branch:

git checkout -b b4.20 v4.20

Then cherry pick some mt76 commits:

git log --no-merges --oneline v4.20..v5.0-rc2 -- drivers/net/wireless/mediatek/ | tac | sed -n '1,10p' | while read l ; do echo $l | awk '{print $1}' | xargs git cherry-pick ; done

Then if things work move backward by half of commits i.e:

git reset --hard HEAD~5

Move forward by changing sed lines in cherry-pick command i.e: sed -n '6,8p'   

Repeat until you can point first commit that make things work on top of v4.20.
Comment 23 Michael 2019-01-16 12:06:56 UTC
Thanks for that device info.
Nice to hear, that you are also a rt2800usb maintainer. If we have a fix for the mt76 issue, we can talk about the rt2800usb (wrote something about this in hcxdumptool changelog 20.12.2018), too.
I'm walking through the mt76 code, too, but I'm not able to identify the issue, yet.
Comment 24 Michael 2019-01-16 12:36:38 UTC
Your idea is excellent. Instead of walking through the current code, I'll try to narrow down the issue by the commits.
Comment 25 Michael 2019-01-16 14:37:50 UTC
That one (1163bdb636a1) is ok and works.
Comment 26 Michael 2019-01-16 14:49:04 UTC
And that one (cac97ed681db) possible (tested only 1163bdb636a1 and cac97ed681db - maybe there is another commit between this two ones) caused the trouble.
Comment 27 Stanislaw Gruszka 2019-01-16 15:36:30 UTC
(In reply to Michael from comment #26)
> And that one (cac97ed681db) possible (tested only 1163bdb636a1 and
> cac97ed681db - maybe there is another commit between this two ones) caused
> the trouble.

So you applied:

1163bdb636a1 mt76x0: phy: unify calibration between mt76x0u and mt76x0e
70289adc6af6 mt76x2u: introduce mac workqueue support
73556561ab9f mt76x0: use mt76x02_mac_work as stats handler
63f15d9459db mt76x0: use shared debugfs implementation
760554130852 mt76: move mt76x02_debugfs in mt76x02-lib module
7dd735883dec mt76: move mt76x02_mac_work routine in mt76x02-lib module
6250318694ca mt76x0: pci: add get_survey support
b8defea4b2ee mt76x0: phy: improve code readability in initvals_phy.h
d3caa060e171 mt76x0: phy: simplify rf configuration routines
9c410782472e mt76x0: phy: use proper name convention
989582e50cbf mt76x2u: align channel gain logic to mt76x2 one
cac97ed681db mt76x2: align mt76x2 and mt76x2u firmware

on top of 4.20 and that make things work for you without any other patches ?
Comment 28 Michael 2019-01-16 15:54:47 UTC
No. Big mistake. Will check them all.
Comment 29 Stanislaw Gruszka 2019-01-16 16:13:50 UTC
I'm confused , what actually you have done? If you applied just one commit 1163bdb636a1 and it fixed the problem, that what I wanted to know.
Comment 30 Michael 2019-01-16 16:18:44 UTC
No, I walked through the commits in chronological order until I found a working one. In that case it is 1163bdb636a1.
Now I walk again through the commits until I'll find the first not working one.
Comment 31 Michael 2019-01-16 16:20:56 UTC
I assume that the patches are in chronological order!?
This one is working:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=1163bdb636a1
Date: Mon, 15 Oct 2018 14:18:05 +0200
or am I wrong?
Comment 32 Michael 2019-01-16 16:28:29 UTC
Did this by cloning git repo and doing a checkout on 1163bdb636a1
Comment 34 Michael 2019-01-16 17:05:52 UTC
right now, I'm here:
git checkout 48c76588221b49e7d46e6f3c26bce0318fbea97a
2018-11-30	mt76x0: init: use mt76x02_mac_shared_key_setup in mt76x0_init_hardware
and everything's still fine
Comment 35 Michael 2019-01-16 17:22:00 UTC
Could it narrow down:
This is the last working one:
2018-11-30	mt76: replace sta_add/remove ops with common sta_state function
git checkout e28487ea84a9c081c6d8d7da319427f7fcc32ff5

this is the first not working one:
2018-12-13	mt76: fix potential NULL pointer dereference in mt76_stop_tx_queues
git checkout 7c250f4612ae97aa04500c0d0cff69bb87046e3a

Didn't test the commit between this two ones, because I assume it's correct:
2018-12-01	iio: humidity: hts221: add entry in MAINTAINERS file
Comment 36 Michael 2019-01-16 18:31:00 UTC
So this here (tx.c) is our ‎problem child:

if (!txq)
	continue;
Comment 37 Stanislaw Gruszka 2019-01-17 08:59:22 UTC
Can you double check that? Because you wrote earlier that 5.0-rc2 works for you and it includes commit 7c250f4612ae97aa04500c0d0cff69bb87046e3a 

Also I do not see how it could break things. Do you use any extra patches ?
Comment 38 Stanislaw Gruszka 2019-01-17 09:15:07 UTC
C(In reply to Michael from comment #31)
> I assume that the patches are in chronological order!?

Commits are in chronological order in the log. However I'm not sure if you do "git checkout COMMIT" log order is still kept due to merges. Probably better would be do git bisect. But you have to recompile whole kernel on each step . When you cherry-pick commits like in instructions in comment 22 , you will need only recompile the driver.
Comment 39 Michael 2019-01-17 09:19:51 UTC
I'll check it again. Maybe I' made a big mistake here (perhaps I compiled the driver against the wrong kernel source).  ‎I already thought something like that, when I removed the 7c250f4612ae97aa04500c0d0cff69bb87046e3a patch, but the driver doesn't work as expected. Now I clean up all folders and start with a fresh git clone again.
Comment 40 Michael 2019-01-17 09:21:34 UTC
Started now, using git bisect - that will take a while...
Comment 41 Michael 2019-01-17 09:29:45 UTC
here we go...
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:38:05 2018 +0200
 3 files changed, 4 insertions(+), 7 deletions(-)
[b4.20 1025cbfe9383] mt76x2u: align channel gain logic to mt76x2 one
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 20:27:28 2018 +0200
 8 files changed, 114 insertions(+), 177 deletions(-)
[b4.20 9853a324927c] mt76x0: phy: use proper name convention
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:55:18 2018 +0200
 3 files changed, 113 insertions(+), 113 deletions(-)
[b4.20 69fcf983070e] mt76x0: phy: simplify rf configuration routines
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:55:19 2018 +0200
 2 files changed, 106 insertions(+), 144 deletions(-)
[b4.20 64a8e3f34377] mt76x0: phy: improve code readability in initvals_phy.h
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:55:20 2018 +0200
 1 file changed, 641 insertions(+), 772 deletions(-)
 rewrite drivers/net/wireless/mediatek/mt76/mt76x0/initvals_phy.h (96%)
[b4.20 b9b601a73af3] mt76x0: pci: add get_survey support
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:11 2018 +0200
 8 files changed, 30 insertions(+), 21 deletions(-)
[b4.20 f35dd84ff7f5] mt76: move mt76x02_mac_work routine in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:12 2018 +0200
 8 files changed, 23 insertions(+), 25 deletions(-)
[b4.20 8a8e150348ed] mt76: move mt76x02_debugfs in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:13 2018 +0200
 7 files changed, 17 insertions(+), 16 deletions(-)
 rename drivers/net/wireless/mediatek/mt76/{mt76x2/debugfs.c => mt76x02_debugfs.c} (86%)
[b4.20 f1e25b966a84] mt76x0: use shared debugfs implementation
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:14 2018 +0200
 4 files changed, 3 insertions(+), 92 deletions(-)
 delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/debugfs.c
[b4.20 8f0a89a630bf] mt76x0: use mt76x02_mac_work as stats handler
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:15 2018 +0200
 5 files changed, 20 insertions(+), 81 deletions(-)
Comment 42 Michael 2019-01-17 09:44:10 UTC
But the git checkout way wasn't so bad, because now we know, that the driver works on the Archer device running kernel 4.19, 4.20 and 5.0.
Comment 43 Stanislaw Gruszka 2019-01-17 10:14:16 UTC
(In reply to Michael from comment #42)
> But the git checkout way wasn't so bad, because now we know, that the driver
> works on the Archer device running kernel 4.19, 4.20 and 5.0.

So it works on 4.20 but not on 4.20.2 ?
Comment 44 Michael 2019-01-17 10:54:12 UTC
Now I'm a little bit confused:

did a fresh git clone.
switched to v4.20 branch
did a cherry-pick

git log --no-merges --oneline v4.20..v5.0-rc2 -- drivers/net/wireless/mediatek/ | tac | sed -n '1,33p' | while read l ; do echo $l | awk '{print $1}' | xargs git cherry-pick ; done

compiled the driver against 4.20.2
make -C /lib/modules/`uname -r`/build M=$PWD
copied the driver to
/lib/modules/4.20.2-arch1-1-ARCH/kernel/drivers/net/wireless/mediatek/
plugged in the device and it's working

now moved head back 15
unloaded all modules
cleaned driver source
compiled the driver again against 4.20.2 and copied it to lib/modules/...
plugged in the device and it's working again.

What's going on here? Am I fooled again by git?
Comment 45 Stanislaw Gruszka 2019-01-17 11:09:54 UTC
I'm confused too. Is this working on 4.20 or not ?
Comment 46 Michael 2019-01-17 11:16:59 UTC
Yes, that is working on 4.20.2
I cherry-picked several patches and all off them are working.
Now I'll do a reboot instead of unloading the modules. Maybe one of them was not removed completely.
Comment 47 Michael 2019-01-17 11:20:20 UTC
Ok, now I got the first one which doesn't work:

git log --no-merges --oneline v4.20..v5.0-rc2 -- drivers/net/wireless/mediatek/ | tac | sed -n '1,10p' | while read l ; do echo $l | awk '{print $1}' | xargs git cherry-pick ; done

going up, now
Comment 48 Michael 2019-01-17 11:24:44 UTC
Do we have additional patches on git stable, which are currently not applied to 4.20.2?
Comment 49 Michael 2019-01-17 11:31:54 UTC
Ok, now I'm here:

git log --no-merges --oneline v4.20..v5.0-rc2 -- drivers/net/wireless/mediatek/ | tac | sed -n '1,13p' | while read l ; do echo $l | awk '{print $1}' | xargs git cherry-pick ; done

git reset --hard HEAD~6
HEAD ist jetzt bei 7f80a4250737 mt76: move mt76x02_sw_scan and mt76x02_sw_scan_complete in mt76x02-lib module

That one is not working!
Going up
Comment 50 Stanislaw Gruszka 2019-01-17 11:38:48 UTC
Stop for the moment and just answer the questions.

Does the driver work on 4.20 ?
Does the driver work on 4.20.2 ?

There breakages (already fixed) between 4.20 and 5.0-rc on mainline tree.

The question is, if we need some fixes on 4.20.x stable kernel tree.
Comment 51 Michael 2019-01-17 11:51:20 UTC
Does the driver work on 4.20?
Didn't test it, because I'm running 4.20.2-arch1-1-ARCH

Does the driver work on 4.20.2?
The supplied driver doesn't work.

So I tried this head and newer heads:
2f70b38693ae mt76: introduce mt76x02_init_beacon_config routine
all of them are working

while up to this one
7f80a4250737 mt76: move mt76x02_sw_scan and 
the Archer failed
Comment 52 Michael 2019-01-17 11:53:43 UTC
So, is 2f70b38693ae allready applied to delivered 4.20.2
or will it came with 4.20.3?
Comment 53 Michael 2019-01-17 11:55:06 UTC
I'm not a native english speaker, so it's hard to explain for me.
Comment 54 Michael 2019-01-17 12:16:17 UTC
This is the first head, that makes the Archer working:
a9cde41ab9e5 mt76: move mt76x02_get_txpower in mt76x02_util.c

git log --no-merges --oneline v4.20..v5.0-rc2 -- drivers/net/wireless/mediatek/ | tac | sed -n '1,33p' | while read l ; do echo $l | awk '{print $1}' | xargs git cherry-pick ; done
git reset --hard HEAD~5

HEAD~4,3,2,1 also working, while HEAD~6 isn't working.
Comment 55 Stanislaw Gruszka 2019-01-17 12:24:24 UTC
(In reply to Michael from comment #52)
> So, is 2f70b38693ae allready applied to delivered 4.20.2
> or will it came with 4.20.3?

The HASH is changed after cherry-pick. I don't have this commit in my tree:

git show 2f70b38693ae
fatal: ambiguous argument '2f70b38693ae': unknown revision or path not in the working tree. 
 changed. 

Please also provide commit topic, not just HASH.

(In reply to Michael from comment #51)
> Does the driver work on 4.20?
> Didn't test it, because I'm running 4.20.2-arch1-1-ARCH

You can do 'git checkout -b b4.20 v4.20' , compile this and find out.

> Does the driver work on 4.20.2?
> The supplied driver doesn't work.

Perhaps this is due some ARCH patches, let checkout 4.20 first.

> So I tried this head and newer heads:
> 2f70b38693ae mt76: introduce mt76x02_init_beacon_config routine
> all of them are working
> 
> while up to this one
> 7f80a4250737 mt76: move mt76x02_sw_scan and 
> the Archer failed

This is really strange. I think the issue is not 100% reproducible, so that cause confusion .
Comment 56 Michael 2019-01-17 12:38:58 UTC
Correct and to make it more confusing. Just received an Arch kernel 
update to 4.20.3 after last reboot.
I don't think that Arch patches a driver. Didn't see something like that in the PKGBUILD.

a9cde41ab9e5 mt76: move mt76x02_get_txpower in mt76x02_util.c

2f70b38693ae mt76: introduce mt76x02_init_beacon_config routine
Comment 57 Michael 2019-01-17 12:48:59 UTC
here are the long titles.
The last 5 heads are working, while this one is the last not working:
mt76x02_sw_scan and mt76x02_sw_scan_complete in mt76x02-lib module


$ git checkout -b b4.20 v4.20
$ git log --no-merges --oneline v4.20..v5.0-rc2 -- drivers/net/wireless/mediatek | tac | sed -n '1,33p' | while read l ; do echo $l | awk '{print $1}' | xargs git cherry-pick ; done
[b4.20 3de556200d49] mt76x2: align mt76x2 and mt76x2u firmware
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:38:05 2018 +0200
 3 files changed, 4 insertions(+), 7 deletions(-)
[b4.20 97897cc96a07] mt76x2u: align channel gain logic to mt76x2 one
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 20:27:28 2018 +0200
 8 files changed, 114 insertions(+), 177 deletions(-)
[b4.20 4d7ccc1e6a46] mt76x0: phy: use proper name convention
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:55:18 2018 +0200
 3 files changed, 113 insertions(+), 113 deletions(-)
[b4.20 df0ab2972cf6] mt76x0: phy: simplify rf configuration routines
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:55:19 2018 +0200
 2 files changed, 106 insertions(+), 144 deletions(-)
[b4.20 5b6e187a4869] mt76x0: phy: improve code readability in initvals_phy.h
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sun Oct 14 18:55:20 2018 +0200
 1 file changed, 641 insertions(+), 772 deletions(-)
 rewrite drivers/net/wireless/mediatek/mt76/mt76x0/initvals_phy.h (96%)
[b4.20 28297d36643d] mt76x0: pci: add get_survey support
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:11 2018 +0200
 8 files changed, 30 insertions(+), 21 deletions(-)
[b4.20 80bf6db04209] mt76: move mt76x02_mac_work routine in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:12 2018 +0200
 8 files changed, 23 insertions(+), 25 deletions(-)
[b4.20 3e37f497361e] mt76: move mt76x02_debugfs in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:13 2018 +0200
 7 files changed, 17 insertions(+), 16 deletions(-)
 rename drivers/net/wireless/mediatek/mt76/{mt76x2/debugfs.c => mt76x02_debugfs.c} (86%)
[b4.20 aa4cb66df5ab] mt76x0: use shared debugfs implementation
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:14 2018 +0200
 4 files changed, 3 insertions(+), 92 deletions(-)
 delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/debugfs.c
[b4.20 b11c4363835e] mt76x0: use mt76x02_mac_work as stats handler
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:15 2018 +0200
 5 files changed, 20 insertions(+), 81 deletions(-)
[b4.20 1899e8245bea] mt76x2u: introduce mac workqueue support
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 11:33:16 2018 +0200
 4 files changed, 5 insertions(+), 1 deletion(-)
[b4.20 f19571d7b859] mt76x0: phy: unify calibration between mt76x0u and mt76x0e
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Mon Oct 15 14:18:05 2018 +0200
 4 files changed, 4 insertions(+), 84 deletions(-)
[b4.20 cc41de73b9d3] mt76x0: do not perform MCU calibration for MT7630
 Author: Stanislaw Gruszka <sgruszka@redhat.com>
 Date: Tue Oct 16 09:58:43 2018 +0200
 2 files changed, 8 insertions(+)
[b4.20 b1cc794cdf35] mt76: clean up unused leftover EXPORT_SYMBOLs
 Author: Felix Fietkau <nbd@nbd.name>
 Date: Wed Oct 17 13:10:16 2018 +0200
 6 files changed, 3 insertions(+), 18 deletions(-)
[b4.20 99195c9177c8] mt76: mt76x0: handle chip specific initval differences
 Author: Felix Fietkau <nbd@nbd.name>
 Date: Thu Oct 18 16:09:07 2018 +0200
 2 files changed, 49 insertions(+), 4 deletions(-)
[b4.20 f8d5170efd67] mt76: usb: fix static tracepoints
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Thu Oct 18 00:35:32 2018 +0200
 10 files changed, 38 insertions(+), 347 deletions(-)
 delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/trace.c
 delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/trace.h
[b4.20 1df13fe6ef1e] mt76x0: antenna select corrections
 Author: Stanislaw Gruszka <sgruszka@redhat.com>
 Date: Thu Oct 18 12:15:31 2018 +0200
 2 files changed, 44 insertions(+), 18 deletions(-)
[b4.20 b0ea52dc937e] mt76x0: init: simplify mt76x0_init_mac_registers
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Tue Oct 16 11:42:32 2018 +0200
 1 file changed, 10 insertions(+), 17 deletions(-)
[b4.20 18e3ea75311d] mt76x0: pci: add missing MODULE_FIRMWARE macro
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Fri Oct 19 00:57:32 2018 +0200
 3 files changed, 5 insertions(+), 3 deletions(-)
[b4.20 2e7b940b12ed] mt76x0: mac: remove mt76x0_mac_set_ampdu_factor
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Fri Oct 19 12:47:35 2018 +0200
 2 files changed, 26 deletions(-)
[b4.20 7614a0caee7d] mt76x0: align mt76x0u and mt76x0e fw version
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Fri Oct 19 11:40:48 2018 +0200
 3 files changed, 23 insertions(+), 4 deletions(-)
[b4.20 705ad4e4812d] mt76: move mt76x02_mac_set_short_preamble in mt76x02_mac.c
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Fri Oct 19 14:56:24 2018 +0200
 5 files changed, 11 insertions(+), 10 deletions(-)
[b4.20 2aacf7a1131c] mt76: move mt76x02_init_device in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:24 2018 +0200
 8 files changed, 87 insertions(+), 114 deletions(-)
[b4.20 b33aa9690826] mt76: move mac beacon routines in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:25 2018 +0200
 7 files changed, 185 insertions(+), 179 deletions(-)
 rewrite drivers/net/wireless/mediatek/mt76/mt76x2/pci_mac.c (61%)
[b4.20 61e170e916d4] mt76: move tx beacon routines in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:26 2018 +0200
 6 files changed, 130 insertions(+), 147 deletions(-)
 delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2/pci_tx.c
[b4.20 a406e721254e] mt76x0: pci: add pre_tbtt_tasklet support
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:27 2018 +0200
 5 files changed, 7 insertions(+), 7 deletions(-)
[b4.20 992c20371936] mt76: move mt76x02_sw_scan and mt76x02_sw_scan_complete in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:28 2018 +0200
 8 files changed, 34 insertions(+), 66 deletions(-)
[b4.20 cee93fc677e1] mt76: move mt76x02_get_txpower in mt76x02_util.c
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:29 2018 +0200
 6 files changed, 24 insertions(+), 14 deletions(-)
[b4.20 c4744d62f607] mt76: move mt76x02_sta_ps in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:30 2018 +0200
 6 files changed, 15 insertions(+), 14 deletions(-)
[b4.20 0a49dde62b0f] mt76: introduce mt76x02_init_beacon_config routine
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:31 2018 +0200
 4 files changed, 31 insertions(+), 28 deletions(-)
[b4.20 4a07abac2432] mt76x0: pci: enable AP support
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:13:32 2018 +0200
 4 files changed, 32 insertions(+), 39 deletions(-)
[b4.20 a01e94441c51] mt76: move mt76x02_set_tx_ackto in mt76x02-lib module
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:40:52 2018 +0200
 7 files changed, 39 insertions(+), 34 deletions(-)
[b4.20 00046f2a04a9] mt76x0: update init vals for MT_TX_PROT registers
 Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
 Date: Sat Oct 20 12:40:53 2018 +0200
 1 file changed, 9 insertions(+), 6 deletions(-)
Comment 58 Michael 2019-01-17 13:26:16 UTC
(In reply to Stanislaw Gruszka from comment #55)
> (In reply to Michael from comment #52)
> > So, is 2f70b38693ae allready applied to delivered 4.20.2
> > or will it came with 4.20.3?
> 
> The HASH is changed after cherry-pick. I don't have this commit in my tree:
> 
> git show 2f70b38693ae
> fatal: ambiguous argument '2f70b38693ae': unknown revision or path not in
> the working tree. 
>  changed. 
> 
> Please also provide commit topic, not just HASH.
> 
> (In reply to Michael from comment #51)
> > Does the driver work on 4.20?
> > Didn't test it, because I'm running 4.20.2-arch1-1-ARCH
> 
> You can do 'git checkout -b b4.20 v4.20' , compile this and find out.
> 

No, it doesn't work!
Comment 59 Michael 2019-01-17 13:35:01 UTC
In that case we have no tx output and iw shows this:

$ iw dev
phy#1
	Interface wlp0s20f0u3
		ifindex 4
		wdev 0x100000001
		addr d2:c8:0d:ab:39:de
		type managed
		txpower 2.00 dBm
Comment 60 Michael 2019-01-17 13:39:51 UTC
No I download the 5.0-rc2 tarball, and compile this driver against 4.20.3.
Let's see what happens...
Comment 61 Michael 2019-01-17 13:51:01 UTC
$ iw dev
phy#1
	Interface wlp0s20f0u3
		ifindex 4
		wdev 0x100000001
		addr 36:89:84:df:72:cc
		type managed
		txpower 16.00 dBm
		
NetworkManager -> ok
iw scan -> ok

monitor mode -> ok
Interface wlp0s20f0u3
	ifindex 4
	wdev 0x100000001
	addr 36:89:84:df:72:cc
	type monitor
	wiphy 1
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 16.00 dBm

packet injection -> ok
$ hcxdumptool -i wlp0s20f0u3 --do_rcascan
INFO: cha=6, rx=151, rx(dropped)=0, tx=12, err=0, aps=4
-----------------------------------------------------------------------------------

tx power -> to low, but more then 2.00 dBm as of 4.20 source


and I'm very confused, again.
Comment 62 Michael 2019-01-17 14:33:54 UTC
And to make sure, that the issue is not Arch Linux related, I downloaded the 4.20.3. tarball and compiled the driver. As expected, it doesn't work (scan lists are ampty).
Comment 63 Stanislaw Gruszka 2019-01-17 14:37:53 UTC
Created attachment 280561 [details]
txpower.patch

Let see if this will help. Please test it with 6 already attached patches on top of 4.20.

I can also provide version for 5.0 , to see if it fixes txpower issue there, but let first check 4.20.
Comment 64 Michael 2019-01-17 15:50:17 UTC
txpower.patch doesn't work on 4.20

dmesg:
version magic '... SMP preempt mod_unload modversions' should be '... SMP preempt mod_unload'
Comment 65 Michael 2019-01-17 16:18:06 UTC
Please cancel comment 64 - old mt76_usb wasn't unloaded successfully.
Must check this twice!

txpower.patch working like expected:
$ iw dev
phy#1
	Interface wlp0s20f0u3
		ifindex 4
		wdev 0x100000001
		addr 1a:1a:f8:03:d7:c1
		type managed
		txpower 20.00 dBm
Comment 66 Stanislaw Gruszka 2019-01-17 17:07:42 UTC
Does "iw dev wlp0s20f0u3 scan" work or the patch fixed only txpower ?
Comment 67 Michael 2019-01-17 17:34:06 UTC
No, only power is fixed. All scan lists remain empty (including wireshark live capture).
Comment 68 Michael 2019-01-17 17:35:48 UTC
Also, I have no idea, why some git heads (from the same branch) working, while others don't.
Comment 69 Michael 2019-01-18 08:03:08 UTC
For me, it looks like, that not all patches from here
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Lorenzo+Bianconi
are really applied to 4.20 branch. I walked through this list and tested some of the patches from there - and they work.
Let me give you an example:

Downloaded linux-e28487ea84a9c081c6d8d7da319427f7fcc32ff5.tar.gz
from here
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e28487ea84a9c081c6d8d7da319427f7fcc32ff5
compiled the driver and it work.

But I can't find the patch within the driver from 4.20.3 tarball
The first one, for example:
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c

That is very mysterious - I admit, that I do not really understand the logic within the patching system on kernel git....
Comment 70 Michael 2019-01-18 08:20:44 UTC
Of course, tx power output is false here, because latest txpower.patch isn't applied at this time:
Interface wlp0s20f0u3
	ifindex 4
	wdev 0x100000001
	addr 7a:f7:9d:d7:d9:7d
	type monitor
	wiphy 1
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 16.00 dBm
Comment 71 Michael 2019-01-18 08:35:13 UTC
The I checked the merge
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=519be6995c31005ae3bad5421e09ef99d4eb0b82

For this I downloaded this one:
linux-519be6995c31005ae3bad5421e09ef99d4eb0b82.tar.gz
and the driver is not working.

So, what happened between here
e28487ea84a9c081c6d8d7da319427f7fcc32ff5
and here
519be6995c31005ae3bad5421e09ef99d4eb0b82
and why are not all patches inside the merge?
Comment 72 Stanislaw Gruszka 2019-01-18 12:44:24 UTC
I don't understand this as well. However I think the problem  is that some commits have bugs that are fixed by some other later commits.

And there is firmware change in 

f47301403f11 mt76x0: align mt76x0u and mt76x0e fw version

so if you test after this commit, you use different FW.

I will provide one more patch, which I think could fix the problem you see ...
Comment 73 Michael 2019-01-18 13:20:57 UTC
Well, that's a booby trab, I ran into, because I thought the patches from here
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Lorenzo+Bianconi
are in chronological order. I checked several commits and verified many diffs
between the different commits. Every checked commit is working fine, except the last one (including that one from the 4.20.3 tarball).
The good thing: in the meantime, I understand most parts of the driver code. 
and: its good to check twice, that the modules are really unloaded as expected - especially if the driver crashed.

I'll take a look into "align mt76x0u and mt76x0e fw version"

BTW:
It would be nice, if you can apply the txpower.patch for 5.0, too, until we reach the final merge window in a few weeks.
Comment 74 Stanislaw Gruszka 2019-01-18 14:07:09 UTC
Created attachment 280577 [details]
phy_calibrate.patch

Please test this together with other patches. 

If not work try replace firmware:

cd /lib/firmware/mediatek/
mv mt7610u.bin mt7610u.bin.old
ln -s mt7610e.bin mt7610u.bin
Comment 75 Stanislaw Gruszka 2019-01-18 14:08:54 UTC
(In reply to Michael from comment #73)
> BTW:
> It would be nice, if you can apply the txpower.patch for 5.0, too, until we
> reach the final merge window in a few weeks.

Sure, will do that, but first I'll look if this can be optimized.
Comment 76 Michael 2019-01-18 15:44:34 UTC
the last patch (phy_calibrate.patch) did it (added on top of the other 7 patches on 4.20.3). No need to replace the firmware.
Great job! Thanks!

NetworkManager scan list -> ok
iw scan list -> ok

tx power -> ok 

monitor mode -> ok
packet injection -> ok
wireshark receive packets -> ok
hcxdumptool -> ok

Interface wlp0s20f0u3
	ifindex 5
	wdev 0x200000001
	addr 22:b9:9f:48:66:b3
	type monitor
	wiphy 2
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm
[zerobeat@archbook mediatek]$ hcxdumptool -i wlp0s20f0u3 --do_rcascan
initialization...
INFO: cha=1, rx=251, rx(dropped)=0, tx=14, err=0, aps=4
Comment 77 Michael 2019-01-20 14:25:54 UTC
BTW:

It would be nice, if you can add EEPROM version 0d to the MT7601U driver:
ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter

device: ALLNET ALLWA0150

older version:
mt7601u 1-1:1.0: EEPROM ver:0c fae:00

latest version:
mt7601u 1-1:1.0: EEPROM ver:0d fae:00
Warning: unsupported EEPROM version 0d

wrote this here, because I don't want to open a new issue.
Comment 78 Stanislaw Gruszka 2019-01-22 10:21:35 UTC
Could you compare output of

cat /sys/kernel/debug/ieee80211/phy1/mt7601u/eeprom_param

between 0c and 0d EEPROM version to check if the later show sane values ?
Comment 79 Michael 2019-01-22 10:32:20 UTC
ALLNET EEPROM 0d:

RSSI offset: 0 0
Reference temp: f9
LNA gain: 8
Reg channels: 1-14
Per rate power:
	 raw:05 bw20:05 bw40:05
	 raw:05 bw20:05 bw40:05
	 raw:03 bw20:03 bw40:03
	 raw:03 bw20:03 bw40:03
	 raw:04 bw20:04 bw40:04
	 raw:00 bw20:00 bw40:00
	 raw:00 bw20:00 bw40:00
	 raw:00 bw20:00 bw40:00
	 raw:02 bw20:02 bw40:02
	 raw:00 bw20:00 bw40:00
Per channel power:
	 tx_power  ch1:09 ch2:09
	 tx_power  ch3:0a ch4:0a
	 tx_power  ch5:0a ch6:0a
	 tx_power  ch7:0b ch8:0b
	 tx_power  ch9:0b ch10:0b
	 tx_power  ch11:0b ch12:0b
	 tx_power  ch13:0b ch14:0b

ALLNET EEPROM 0c:
RF freq offset: 78
RSSI offset: 0 0
Reference temp: f9
LNA gain: 0
Reg channels: 1-14
Per rate power:
	 raw:07 bw20:07 bw40:07
	 raw:07 bw20:07 bw40:07
	 raw:04 bw20:04 bw40:04
	 raw:02 bw20:02 bw40:02
	 raw:00 bw20:00 bw40:00
	 raw:00 bw20:00 bw40:00
	 raw:04 bw20:04 bw40:04
	 raw:02 bw20:02 bw40:02
	 raw:00 bw20:00 bw40:00
	 raw:00 bw20:00 bw40:00
Per channel power:
	 tx_power  ch1:1e ch2:1e
	 tx_power  ch3:1e ch4:1e
	 tx_power  ch5:1e ch6:1e
	 tx_power  ch7:1e ch8:1e
	 tx_power  ch9:1e ch10:1e
	 tx_power  ch11:1e ch12:1e
	 tx_power  ch13:1e ch14:1e
TSSI:
	 slope:80
	 offset=00 00 00
	 delta_off:00000000


0d is working with the current driver
Comment 80 Stanislaw Gruszka 2019-01-22 13:01:02 UTC
Created attachment 280663 [details]
0001-mt76x0-always-set-tx-power-when-switch-channel.patch

This is txpower patch for 5.0-rc, please test.
Comment 81 Michael 2019-01-22 13:17:29 UTC
No, patch doesn't work as expected:

phy#1
	Interface wlp0s20f0u3
		ifindex 4
		wdev 0x100000001
		addr a2:26:ff:20:40:74
		type managed
		txpower 16.00 dBm

tested on 5.0-rc3
Comment 82 Michael 2019-01-22 13:20:38 UTC
Also checked using a spectrum analyzer. Device transmits with reduced output power.
Comment 83 Michael 2019-01-22 13:33:18 UTC
Do we have some important changes in 5.0-rc2 and 5.0-rc3?

patching file drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
Hunk #2 succeeded at 1012 with fuzz 2.
Comment 84 Michael 2019-01-22 13:54:54 UTC
mt7601u interesting behaviour:
after plug in in both ALLNET (EEPROM 0d and 0c):

phy#3
	Interface wlp3s0f0u2
		ifindex 6
		wdev 0x300000001
		addr ac:a2:13:11:7f:56
		type managed
		txpower 0.00 dBm
phy#2
	Interface wlp3s0f0u1
		ifindex 5
		wdev 0x200000001
		addr 00:e6:2d:05:13:1a
		type managed
		txpower 0.00 dBm

now accessing the devices using iw set monitor:

Interface wlp3s0f0u2
	ifindex 6
	wdev 0x300000001
	addr ac:a2:13:11:7f:56
	type monitor
	wiphy 3
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm

Interface wlp3s0f0u1
	ifindex 5
	wdev 0x200000001
	addr 00:e6:2d:05:13:1a
	type monitor
	wiphy 2
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm
Comment 85 Stanislaw Gruszka 2019-01-22 14:09:21 UTC
(In reply to Michael from comment #83)
> Do we have some important changes in 5.0-rc2 and 5.0-rc3?
> 
> patching file drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
> Hunk #2 succeeded at 1012 with fuzz 2.

I prepared the patch based on net-next, didn't expect it differ in phy.c with 5.0-rc. However the patch apply correct despite fuzz warning.

We set txpower after we bring up interface, by doing 'ifconfig wlan0 up' or by wpa_supplicant or other command.

What shows output of 'iw phy' for Archer T2UH ?
Comment 86 Michael 2019-01-22 14:44:27 UTC
BTW:
why is 14 disabled on the Archer?
* 2484 MHz [14] (disabled)

ALLNET ALLWA0150 (mt7601u):
* 2484 MHz [14] (20.0 dBm) (no IR)

Tenda W311U+ (rt2800usb)
* 2484 MHz [14] (20.0 dBm) (no IR)


Archer T2UH:
Wiphy phy1
	max # scan SSIDs: 4
	max scan IEs length: 2243 bytes
	max # sched scan SSIDs: 0
	max # match sets: 0
	max # scan plans: 1
	max scan plan interval: -1
	max scan plan iterations: 0
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports RSN-IBSS.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CCMP-256 (00-0f-ac:10)
		* GCMP-128 (00-0f-ac:8)
		* GCMP-256 (00-0f-ac:9)
		* CMAC (00-0f-ac:6)
		* CMAC-256 (00-0f-ac:13)
		* GMAC-128 (00-0f-ac:11)
		* GMAC-256 (00-0f-ac:12)
	Available Antennas: TX 0x1 RX 0x1
	Supported interface modes:
		 * managed
		 * monitor
	Band 1:
		Capabilities: 0x17e
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 4 usec (0x05)
		HT TX/RX MCS rate indexes supported: 0-7
		Bitrates (non-HT):
			* 1.0 Mbps (short preamble supported)
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (20.0 dBm)
			* 2417 MHz [2] (20.0 dBm)
			* 2422 MHz [3] (20.0 dBm)
			* 2427 MHz [4] (20.0 dBm)
			* 2432 MHz [5] (20.0 dBm)
			* 2437 MHz [6] (20.0 dBm)
			* 2442 MHz [7] (20.0 dBm)
			* 2447 MHz [8] (20.0 dBm)
			* 2452 MHz [9] (20.0 dBm)
			* 2457 MHz [10] (20.0 dBm)
			* 2462 MHz [11] (20.0 dBm)
			* 2467 MHz [12] (20.0 dBm)
			* 2472 MHz [13] (20.0 dBm)
			* 2484 MHz [14] (disabled)
	Band 2:
		Capabilities: 0x17e
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 4 usec (0x05)
		HT TX/RX MCS rate indexes supported: 0-7
		VHT Capabilities (0x01800120):
			Max MPDU length: 3895
			Supported Channel Width: neither 160 nor 80+80
			short GI (80 MHz)
		VHT RX MCS set:
			1 streams: MCS 0-7
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-7
			2 streams: not supported
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 Mbps
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 5180 MHz [36] (23.0 dBm)
			* 5200 MHz [40] (23.0 dBm)
			* 5220 MHz [44] (23.0 dBm)
			* 5240 MHz [48] (23.0 dBm)
			* 5260 MHz [52] (20.0 dBm) (radar detection)
			* 5280 MHz [56] (20.0 dBm) (radar detection)
			* 5300 MHz [60] (20.0 dBm) (radar detection)
			* 5320 MHz [64] (20.0 dBm) (radar detection)
			* 5500 MHz [100] (26.0 dBm) (radar detection)
			* 5520 MHz [104] (26.0 dBm) (radar detection)
			* 5540 MHz [108] (26.0 dBm) (radar detection)
			* 5560 MHz [112] (26.0 dBm) (radar detection)
			* 5580 MHz [116] (26.0 dBm) (radar detection)
			* 5600 MHz [120] (26.0 dBm) (radar detection)
			* 5620 MHz [124] (26.0 dBm) (radar detection)
			* 5640 MHz [128] (26.0 dBm) (radar detection)
			* 5660 MHz [132] (26.0 dBm) (radar detection)
			* 5680 MHz [136] (26.0 dBm) (radar detection)
			* 5700 MHz [140] (26.0 dBm) (radar detection)
			* 5745 MHz [149] (13.0 dBm)
			* 5765 MHz [153] (13.0 dBm)
			* 5785 MHz [157] (13.0 dBm)
			* 5805 MHz [161] (13.0 dBm)
			* 5825 MHz [165] (13.0 dBm)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * new_station
		 * new_mpath
		 * set_mesh_config
		 * set_bss
		 * authenticate
		 * associate
		 * deauthenticate
		 * disassociate
		 * join_ibss
		 * join_mesh
		 * set_tx_bitrate_mask
		 * frame
		 * frame_wait_cancel
		 * set_wiphy_netns
		 * set_channel
		 * set_wds_peer
		 * probe_client
		 * set_noack_map
		 * register_beacons
		 * start_p2p_device
		 * set_mcast_rate
		 * connect
		 * disconnect
		 * set_qos_map
		 * set_multicast_to_unicast
	Supported TX frame types:
		 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * IBSS: 0x40 0xb0 0xc0 0xd0
		 * managed: 0x40 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * mesh point: 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	software interface modes (can always be added):
		 * monitor
	interface combinations are not supported
	HT Capability overrides:
		 * MCS: ff ff ff ff ff ff ff ff ff ff
		 * maximum A-MSDU length
		 * supported channel width
		 * short GI for 40 MHz
		 * max A-MPDU length exponent
		 * min MPDU start spacing
	Device supports TX status socket option.
	Device supports HT-IBSS.
	Device supports SAE with AUTHENTICATE command
	Device supports low priority scan.
	Device supports scan flush.
	Device supports AP scan.
	Device supports per-vif TX power setting
	Driver supports full state transitions for AP/GO clients
	Driver supports a userspace MPM
	Device supports active monitor (which will ACK incoming frames)
	Device supports configuring vdev MAC-addr on create.
Comment 87 Michael 2019-01-22 14:50:14 UTC
we can set this channels on the Archer T2UH:
$ hcxdumptool -i wlp0s20f0u3 -C
initialization...
available channels:
1,2,3,4,5,6,7,8,9,10,11,12,13,14,36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,149,153,157,161,165 
terminated...
Comment 88 Stanislaw Gruszka 2019-01-22 15:51:05 UTC
Channel 14 is for Japan, Archer is most likely dedicated for EU or US.

If you do not bring up interface (i.e. NetworkManager or other net daemon is disabled) and you unplug and plug the device, does txpower change randomly ?

If you set channels, does txpower correspond to limitations showed in iw phy ?
Comment 89 Michael 2019-01-22 16:22:37 UTC
If you do not bring up interface (i.e. NetworkManager or other net daemon is disabled) and you unplug and plug the device, does txpower change randomly ?
yes, sometimes iw dev shows 0.00 dBm
Sometimes that happened also if I bring down/up the interface or change mode (managed/monitor).

If you set channels, does txpower correspond to limitations showed in iw phy ?
No, but txpower correspond to info shown in iw dev (16.0 dBm)

Channel 14 is for Japan, Archer is most likely dedicated for EU or US.
The device transmit and receive on ch. 14 (running hcxdumptool).

Looks like the Archer T2UH is a nasty little thing.
Comment 90 Michael 2019-01-22 16:26:11 UTC
If you do not bring up interface (i.e. NetworkManager or other net daemon is disabled) and you unplug and plug the device, does txpower change randomly ?
yes, sometimes iw dev shows 0.00 dBm
Sometimes that happened also if I bring down/up the interface or change mode (managed/monitor).
If that happened, the driver crashed completely and I have to power-off/power-on the system (INTEL core) by switch.
Comment 91 Michael 2019-01-22 16:29:35 UTC
That does not happen on 4.20.3.
Comment 92 Michael 2019-01-22 16:42:54 UTC
Also that doesn't happen on an unpatched 5.0-rc3.
Comment 93 Stanislaw Gruszka 2019-01-23 09:10:03 UTC
(In reply to Michael from comment #92)
> Also that doesn't happen on an unpatched 5.0-rc3.

It's very unlikely that patch from comment 80 cause crash.

(In reply to Michael from comment #82)
> Also checked using a spectrum analyzer. Device transmits with reduced output
> power.

How did you measure that, did you compare with 4.19 driver ?

I can reproduce printing txpower problem, I had to update iw tool (my old did not show txpower). But wish to confirm if printed lowered txpower is not an issue by itself and indeed device transmit at lowered power.
Comment 94 Michael 2019-01-23 16:21:59 UTC
How did you measure that, did you compare with 4.19 driver ?

Testrange:
rx antenna TPLINK TLANT2409 9 dBi
tx antenna DELOCK 88452 2.5 dBi

1) tested T2UH tx power using supplied WINDOWS driver running on a WINDOWS 7 system
2) compared T2UH tx power (4.20.3 and 5.0-rc3) with
   TENDA W311U+ (~100mW)
   LOGILINK WL0151 (~100mW)
   TPLINK TL-WN722N V1 (~100mW)

T2UH tx power is lower on a Linux system, than on a WINDOWS system.
Tx power is also lower compared to the other devices.

Lower tx power on 4.20.3 can be a cause of the old firmware, but I didn't this test, yet.
Comment 95 Michael 2019-01-23 16:24:20 UTC
Also I didn't use channel 12, 13, 14 during the tests.
Also I didn't test 5 GHz tx power, because my test equipment ends at 3 GHz
Comment 96 Stanislaw Gruszka 2019-01-23 17:56:24 UTC
Ok, this is legit issue. Please report to Lorenzo who did txpower changes in mt76x0 . You can add comments here:

https://github.com/openwrt/mt76/issues/216

or open a new issue at github.

I'm going to close this bz , since original bug was fixed. Patches for 4.20 were posted:

https://marc.info/?l=linux-wireless&m=154816072514023&w=2
Comment 97 Michael 2019-01-23 18:31:25 UTC
Thank you very much for your work. At least we have a working driver for 4.20.x
and we removed the ugly EEPROM 0d warning on mt7601u.
That is very good.
I know the OpenWRT git (hcxtools/hcxdumptool got many fixes for OpenWRT. But first I have to do some further going investigations about that issue. Maybe I can find the cause. First of all, I'll buy some other mt76x0 devices to make sure that it isn't a hardware bug of the T2UH.

Again, thank you for your effort.
Cheers
Mike
Comment 98 Stanislaw Gruszka 2019-01-23 18:53:07 UTC
You welcome. Note that issue can be T2UH specific, i.e. driver do not behave correctly for T2UH EEPROM settings. Moreover I think it can be similar problem as already reported in github for MT7610E.
Comment 99 Stanislaw Gruszka 2019-01-23 18:55:03 UTC
Also would be good to discover if 4.19 txpower is fine or not. There were quite big changes in this area between 4.19 and 4.20, so is possible this is regression.
Comment 100 Michael 2019-01-24 08:12:20 UTC
(In reply to Stanislaw Gruszka from comment #98)
> You welcome. Note that issue can be T2UH specific, i.e. driver do not behave
> correctly for T2UH EEPROM settings. Moreover I think it can be similar
> problem as already reported in github for MT7610E.

I think so, too and referenced this issue on 
https://github.com/ZerBea/hcxdumptool/issues/42#issuecomment-457078058
Also I tested some iommu patches, without success.
Comment 101 Michael 2019-01-24 09:06:13 UTC
(In reply to Stanislaw Gruszka from comment #99)
> Also would be good to discover if 4.19 txpower is fine or not. There were
> quite big changes in this area between 4.19 and 4.20, so is possible this is
> regression.

Running some tests on 4.19 (4.19.15-1-lts Arch Linux / INTEL core system / 2.4 GHz ch 1 ... 11 only).
Everything is working like expected (incl. correct tx power)
Comment 102 Michael 2019-01-24 10:02:27 UTC
Also tested ch 14 running kernel 4.19:

* 2467 MHz [12] (20.0 dBm) (no IR)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (20.0 dBm) (no IR)

I've already thought something like that, because hcxdumptool is able to set channel 14:
https://bugzilla.kernel.org/show_bug.cgi?id=202243#c87
Comment 103 webproxy 2019-01-25 14:04:05 UTC
from txpower of different devices had different random power level,
tplink Archer-C2 -> 11dBm
TP-Link Archer C20 v4 ->13dBm
https://github.com/openwrt/mt76/issues/227

I think maybe this bug had been for a long time, but it wasn't appeared because the number was over 20 so legal limit throttled it at 20dBM.
Comment 104 Stanislaw Gruszka 2019-01-25 15:39:17 UTC
There is no point to comment here on closed ticket for different bug,  
please report your findings on proper github ticket:

https://github.com/openwrt/mt76/issues/216

Please comment there if txpower is the same for you on 4.19 and 4.20 i.e. if it is regression or not.

Note You need to log in before you can comment on or make changes to this bug.