Bug 202243
| Summary: | mt76x0u doesn't transmit / receive 802.11 frames using a TP-LINK Archer T2UH | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Michael (ZeroBeat) |
| Component: | network-wireless | Assignee: | drivers_network-wireless (drivers_network-wireless) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | CC: | stf_xl, webproxy |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.20 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
0001-mt76x0-do-not-overwrite-other-MT_BBP-AGC-8-fields.patch
0002-mt76x0-use-band-parameter-for-LC-calibration.patch 0003-mt76x02-run-calibration-after-scanning.patch 0004-mt76x02-assure-we-update-gain-after-scan.patch 0005-mt76x0-do-not-perform-MCU-calibration-for-MT7630.patch 0006-mt76x0-antenna-select-corrections.patc txpower.patch phy_calibrate.patch 0001-mt76x0-always-set-tx-power-when-switch-channel.patch |
||
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 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. 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 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. Created attachment 280463 [details]
0001-mt76x0-do-not-overwrite-other-MT_BBP-AGC-8-fields.patch
Created attachment 280465 [details]
0002-mt76x0-use-band-parameter-for-LC-calibration.patch
Created attachment 280467 [details]
0003-mt76x02-run-calibration-after-scanning.patch
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 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 $ 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. Shall we set "Regression" to yes, because it only affects 4.20? It's regression. We need to identify patches that are needed for 4.20.x . I'll provide you some more patches to test... Created attachment 280489 [details]
0004-mt76x02-assure-we-update-gain-after-scan.patch
Created attachment 280491 [details]
0005-mt76x0-do-not-perform-MCU-calibration-for-MT7630.patch
Created attachment 280493 [details]
0006-mt76x0-antenna-select-corrections.patc
Please test all 6 patches on top of 4.20.2. 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. 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. 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. 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 (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 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.
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. Your idea is excellent. Instead of walking through the current code, I'll try to narrow down the issue by the commits. That one (1163bdb636a1) is ok and works. And that one (cac97ed681db) possible (tested only 1163bdb636a1 and cac97ed681db - maybe there is another commit between this two ones) caused the trouble. (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 ? No. Big mistake. Will check them all. 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. 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. 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? Did this by cloning git repo and doing a checkout on 1163bdb636a1 I'm walking through this commits: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Lorenzo+Bianconi 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 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 So this here (tx.c) is our problem child: if (!txq) continue; 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 ? 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. 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. Started now, using git bisect - that will take a while... 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(-) 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. (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 ? 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?
I'm confused too. Is this working on 4.20 or not ? 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. 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
Do we have additional patches on git stable, which are currently not applied to 4.20.2? 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
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. 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 So, is 2f70b38693ae allready applied to delivered 4.20.2 or will it came with 4.20.3? I'm not a native english speaker, so it's hard to explain for me. 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.
(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 . 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 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(-)
(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! 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 No I download the 5.0-rc2 tarball, and compile this driver against 4.20.3. Let's see what happens... $ 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. 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). 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.
txpower.patch doesn't work on 4.20 dmesg: version magic '... SMP preempt mod_unload modversions' should be '... SMP preempt mod_unload' 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 Does "iw dev wlp0s20f0u3 scan" work or the patch fixed only txpower ? No, only power is fixed. All scan lists remain empty (including wireshark live capture). Also, I have no idea, why some git heads (from the same branch) working, while others don't. 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.... 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 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? 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 ... 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. 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
(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. 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 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. 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 ? 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 Created attachment 280663 [details]
0001-mt76x0-always-set-tx-power-when-switch-channel.patch
This is txpower patch for 5.0-rc, please test.
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 Also checked using a spectrum analyzer. Device transmits with reduced output power. 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. 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 (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 ? 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. 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... 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 ? 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. 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. That does not happen on 4.20.3. Also that doesn't happen on an unpatched 5.0-rc3. (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. 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. 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 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 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 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. 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. (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. (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) 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 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. 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. |
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