Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request Test] New rate adaption algorithm for gen1 devices. #764

Closed
zxystd opened this issue Mar 31, 2022 · 23 comments
Closed

[Request Test] New rate adaption algorithm for gen1 devices. #764

zxystd opened this issue Mar 31, 2022 · 23 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@zxystd
Copy link
Collaborator

zxystd commented Mar 31, 2022

Hi,

I have ported the Linux iwlwifi driver native rate adaption algorithm which called iwl-mvm-rs . This amins to make a stable and reliable connection for gen1 devices.

Now we can enable these features:

  • LDPC
  • STBC
  • BEAMFORMEE

Affected devices:

  • 3160
  • 3165
  • 7260
  • 7265
  • 8260
  • 8265
  • 9260
  • 9462(gen1)
  • 9560(gen1)

These changes haven't merge into master yet, Please help to test it, any issues happened please attach logs here, thank you.

2022-3-31
Monterey.zip
Catalina.zip
Big Sur.zip


2022-4-2

  • Upgrade firmwares for gen1 devices(8260 8265 9260 9560 9462).
  • open BA session only when the tx traffic exceeds 10 frames per second.
  • hardcoded BT state as LOW_TRAFFIC.

Monterey.zip
Catalina.zip
Big Sur.zip

@zxystd zxystd added the help wanted Extra attention is needed label Mar 31, 2022
@usr-sse2
Copy link
Contributor

usr-sse2 commented Apr 2, 2022

What should be tested? That it just works without crashes/disconnections or connection speed improvement?

@zxystd
Copy link
Collaborator Author

zxystd commented Apr 2, 2022

@usr-sse2 For daily use or do some speed benchmarks test, roam, AP compatible, 11n on 2.4GHz/5GHz, 11ac on 20/40/80/160, all test conditions mentioned are welcome. Now I have upload new build files, maybe more stable.

@Overc1ocker
Copy link

Seems to have issues on wake from sleep intermittently. Disconnecting and reconnecting wifi fixes it. Seems to be more likely to happen if reconnecting to the same wifi network. Works well otherwise. How can I obtain logs?

@singhalrishi27
Copy link

What improvements this will bring to the table?

@Overc1ocker
Copy link

Overc1ocker commented Apr 25, 2022

Kernel panic sometimes occurs when moving the laptop around and streaming video

CR0: 0x000000008001003b, CR2: 0x0000000000000006, CR3: 0x0000000035f2a000, CR4: 0x00000000003626e0
RAX: 0xffffff904714e03d, RBX: 0x0000000000004005, RCX: 0x0000000000000000, RDX: 0x0000000000000006
RSP: 0xffffffd053b1b9c0, RBP: 0xffffffd053b1b9c0, RSI: 0xffffff904714e03d, RDI: 0x0000000000000006
R8:  0x0000000000000080, R9:  0x0000000000000000, R10: 0x0000000000000006, R11: 0x0000000000000000
R12: 0x00000f098a3018e5, R13: 0x0000000837bf521b, R14: 0x0000000000000000, R15: 0x0000000000000001
RFL: 0x0000000000010246, RIP: 0xffffff801e3c9530, CS:  0x0000000000000008, SS:  0x0000000000000000
Fault CR2: 0x0000000000000006, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 1

Panicked task 0xffffff99e20e2670: 185 threads: pid 0: kernel_task
Backtrace (CPU 0), panicked thread: 0xffffff99e20b2aa0, Frame : Return Address
0xffffffd053b1b3f0 : 0xffffff801e285ffd mach_kernel : _handle_debugger_trap + 0x41d
0xffffffd053b1b440 : 0xffffff801e3e6035 mach_kernel : _kdp_i386_trap + 0x145
0xffffffd053b1b480 : 0xffffff801e3d5803 mach_kernel : _kernel_trap + 0x533
0xffffffd053b1b4d0 : 0xffffff801e225a60 mach_kernel : _return_from_trap + 0xe0
0xffffffd053b1b4f0 : 0xffffff801e2863cd mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffd053b1b610 : 0xffffff801e285b86 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffffd053b1b670 : 0xffffff801eb16409 mach_kernel : _panic + 0x54
0xffffffd053b1b6e0 : 0xffffff801e3d5bf3 mach_kernel : _sync_iss_to_iks + 0x2c3
0xffffffd053b1b860 : 0xffffff801e3d58d8 mach_kernel : _kernel_trap + 0x608
0xffffffd053b1b8b0 : 0xffffff801e225a60 mach_kernel : _return_from_trap + 0xe0
0xffffffd053b1b8d0 : 0xffffff801e3c9530 mach_kernel : _memcmp + 0x10
0xffffffd053b1b9c0 : 0xffffff80221e4373 com.zxystd.AirportItlwm : __Z19ieee80211_find_nodeP12ieee80211comPKh + 0x43
0xffffffd053b1b9f0 : 0xffffff80221e412c com.zxystd.AirportItlwm : __Z25ieee80211_node_switch_bssP12ieee80211comP14ieee80211_node + 0x7c
0xffffffd053b1ba50 : 0xffffff80221e6880 com.zxystd.AirportItlwm : __Z22ieee80211_release_nodeP12ieee80211comP14ieee80211_node + 0xc0
0xffffffd053b1ba80 : 0xffffff8022258f32 com.zxystd.AirportItlwm : __ZN6ItlIwm12iwm_rx_frameEP9iwm_softcP6__mbufijiijP16ieee80211_rxinfoP9mbuf_list + 0x202
0xffffffd053b1bb20 : 0xffffff8022237de4 com.zxystd.AirportItlwm : __ZN6ItlIwm11iwm_rx_mpduEP9iwm_softcP6__mbufPvmP9mbuf_list + 0x344
0xffffffd053b1bc00 : 0xffffff8022239de9 com.zxystd.AirportItlwm : __ZN6ItlIwm10iwm_rx_pktEP9iwm_softcP11iwm_rx_dataP9mbuf_list + 0x7a9
0xffffffd053b1be00 : 0xffffff8022261d4e com.zxystd.AirportItlwm : __ZN6ItlIwm14iwm_notif_intrEP9iwm_softc + 0xde
0xffffffd053b1be60 : 0xffffff80222623b4 com.zxystd.AirportItlwm : __ZN6ItlIwm8iwm_intrEP8OSObjectP22IOInterruptEventSourcei + 0x5c4
0xffffffd053b1bed0 : 0xffffff801ea58c53 mach_kernel : __ZN22IOInterruptEventSource12checkForWorkEv + 0x163
0xffffffd053b1bf20 : 0xffffff801ea574ae mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x13e
0xffffffd053b1bf60 : 0xffffff801ea56ad7 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x37
0xffffffd053b1bfa0 : 0xffffff801e22518e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.zxystd.AirportItlwm(2.2)[A8C3F29D-DED1-3887-9827-1569438E8F4A]@0xffffff80221ab000->0xffffff80228ccfff
            dependency: com.apple.iokit.IO80211FamilyLegacy(1200.12.2b1)[210E54A5-E336-3882-B54C-16D88FD128FB]@0xffffff801ffee000->0xffffff8020134fff
            dependency: com.apple.iokit.IONetworkingFamily(3.4)[58A9BF44-6CDC-3A24-A588-5D72E2378E2A]@0xffffff8020b4d000->0xffffff8020b63fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[897B72E0-B98F-30BA-8CB2-4E5E469CE4B6]@0xffffff8020de7000->0xffffff8020e11fff

Process name corresponding to current thread (0xffffff99e20b2aa0): kernel_task
Boot args: -v keepsyms=1 debug=0x100 alcid=15 chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
21D62

Kernel version:
Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64
Kernel UUID: 93729D02-FE6F-355B-BA76-BA930AA7103F
KernelCache slide: 0x000000001e000000
KernelCache base:  0xffffff801e200000
Kernel slide:      0x000000001e010000
Kernel text base:  0xffffff801e210000
__HIB  text base: 0xffffff801e100000
System model name: MacBookPro15,4 (Mac-53FDB3D8DB8CA971)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 16533648444199
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x00000f098a3e0e5a
  Sleep   : 0x00000ddf4aaeacc3 0x000000003fa51a07 0x00000bac631279d3
  Wake    : 0x00000ddf4cdc6191 0x000000003edaf8ab 0x00000ddf4b74e544
Zone info:
Foreign   : 0xffffff8036347000 - 0xffffff8036354000
Native    : 0xffffff80489b0000 - 0xffffffa0489b0000
Readonly  : 0xffffff851567c000 - 0xffffff86af010000
Metadata  : 0xffffffd4661da000 - 0xffffffd486301000
Bitmaps   : 0xffffffd486301000 - 0xffffffd48ab01000


@zxystd
Copy link
Collaborator Author

zxystd commented Apr 25, 2022

What improvements this will bring to the table?

aims to make a more stable connection, so just use it for daily using to see if it have issues.

@zxystd
Copy link
Collaborator Author

zxystd commented Apr 25, 2022

@Overc1ocker Is it reproducible? And the same panic info?

@Overc1ocker
Copy link

I'm not sure. I'll post if it happens again. I wanted to drop it in case you were able to find something immediately wrong

@zxystd
Copy link
Collaborator Author

zxystd commented Apr 25, 2022

@Overc1ocker It would be most likely happened on ROAM routine. If you find a way to reproduce it, please let me know, and you can try this one to see if it is fixed.
Big Sur.zip
Catalina.zip
Monterey.zip

@usr-sse2
Copy link
Contributor

One time it gave this panic when waking from sleep on Monterey (it's 2022-4-2 version). It was when moving (in sleep state) from one building to another which has the second part of the same wireless network.

panic(cpu 2 caller 0xffffff8018bd38f3): Kernel trap at 0xffffff8018bc7140, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0x0000000000000006, CR3: 0x0000000026db3000, CR4: 0x00000000003626e0
RAX: 0xffffff903ad2503d, RBX: 0x0000000000004214, RCX: 0x0000000000000000, RDX: 0x0000000000000006
RSP: 0xffffffd0528239a0, RBP: 0xffffffd0528239a0, RSI: 0xffffff903ad2503d, RDI: 0x0000000000000006
R8:  0x0000000000000098, R9:  0xffffff80190a7f30, R10: 0x0000000000000005, R11: 0x0000000000002000
R12: 0x00000505c14c39f8, R13: 0x00000001a727f973, R14: 0x0000000000000000, R15: 0x0000000000000001
RFL: 0x0000000000010246, RIP: 0xffffff8018bc7140, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x0000000000000006, Error code: 0x0000000000000000, Fault CPU: 0x2, PL: 0, VF: 1

Panicked task 0xffffff99d95af670: 186 threads: pid 0: kernel_task
Backtrace (CPU 2), panicked thread: 0xffffff950cbbcaa8, Frame : Return Address
0xffffffd052823350 : 0xffffff8018a83e2d mach_kernel : _handle_debugger_trap + 0x41d
0xffffffd0528233a0 : 0xffffff8018be3cb6 mach_kernel : _kdp_i386_trap + 0x116
0xffffffd0528233e0 : 0xffffff8018bd350d mach_kernel : _kernel_trap + 0x51d
0xffffffd052823430 : 0xffffff8018a23a60 mach_kernel : _return_from_trap + 0xe0
0xffffffd052823450 : 0xffffff8018a841fd mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffd052823570 : 0xffffff8018a839b6 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffffd0528235d0 : 0xffffff80193164bf mach_kernel : _panic + 0x84
0xffffffd0528236c0 : 0xffffff8018bd38f3 mach_kernel : _sync_iss_to_iks + 0x2c3
0xffffffd052823840 : 0xffffff8018bd35e2 mach_kernel : _kernel_trap + 0x5f2
0xffffffd052823890 : 0xffffff8018a23a60 mach_kernel : _return_from_trap + 0xe0
0xffffffd0528238b0 : 0xffffff8018bc7140 mach_kernel : _memcmp + 0x10
0xffffffd0528239a0 : 0xffffff801d4eea93 com.zxystd.AirportItlwm : __Z19ieee80211_find_nodeP12ieee80211comPKh + 0x43
0xffffffd0528239d0 : 0xffffff801d4ee84c com.zxystd.AirportItlwm : __Z25ieee80211_node_switch_bssP12ieee80211comP14ieee80211_node + 0x7c
0xffffffd052823a30 : 0xffffff801d4f0fa0 com.zxystd.AirportItlwm : __Z22ieee80211_release_nodeP12ieee80211comP14ieee80211_node + 0xc0
0xffffffd052823a60 : 0xffffff801d564f82 com.zxystd.AirportItlwm : __ZN6ItlIwm12iwm_rx_frameEP9iwm_softcP6__mbufijiijP16ieee80211_rxinfoP9mbuf_list + 0x202
0xffffffd052823b00 : 0xffffff801d543624 com.zxystd.AirportItlwm : __ZN6ItlIwm11iwm_rx_mpduEP9iwm_softcP6__mbufPvmP9mbuf_list + 0x344
0xffffffd052823be0 : 0xffffff801d545750 com.zxystd.AirportItlwm : __ZN6ItlIwm10iwm_rx_pktEP9iwm_softcP11iwm_rx_dataP9mbuf_list + 0x8d0
0xffffffd052823e00 : 0xffffff801d56e09e com.zxystd.AirportItlwm : __ZN6ItlIwm14iwm_notif_intrEP9iwm_softc + 0xde
0xffffffd052823e60 : 0xffffff801d56e704 com.zxystd.AirportItlwm : __ZN6ItlIwm8iwm_intrEP8OSObjectP22IOInterruptEventSourcei + 0x5c4
0xffffffd052823ed0 : 0xffffff8019247454 mach_kernel : __ZN22IOInterruptEventSource12checkForWorkEv + 0x114
0xffffffd052823f20 : 0xffffff8019245d0e mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x13e
0xffffffd052823f60 : 0xffffff8019245337 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x37
0xffffffd052823fa0 : 0xffffff8018a2318e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.zxystd.AirportItlwm(2.2)[BE6B41FA-BE58-3B83-989B-14195B64F72C]@0xffffff801d4b5000->0xffffff801dafdfff
            dependency: com.apple.iokit.IO80211FamilyLegacy(1200.12.2b1)[3D7E24FF-CEF0-3208-91F9-7FF6B620FCB5]@0xffffff801a810000->0xffffff801a954fff
            dependency: com.apple.iokit.IONetworkingFamily(3.4)[62888EF4-277C-35B5-B9FA-DF8008BC5D28]@0xffffff801b36b000->0xffffff801b381fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[A436E92C-DE10-3718-AEF4-ED2A788A466A]@0xffffff801b603000->0xffffff801b62efff

Process name corresponding to current thread (0xffffff950cbbcaa8): kernel_task
Boot args: keepsyms=1 -noht40 brcmfx-delay=10000 chunklist-security-epoch=0 -chunklist-no-rev2-dev chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
21E258

Kernel version:
Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64
Kernel UUID: B6F8637B-0844-355F-8C82-60FA06149384
KernelCache slide: 0x0000000018800000
KernelCache base:  0xffffff8018a00000
Kernel slide:      0x0000000018810000
Kernel text base:  0xffffff8018a10000
__HIB  text base: 0xffffff8018900000
System model name: MacBookPro15,4 (Mac-53FDB3D8DB8CA971)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 5522278029784
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x00000505c16ba384
  Sleep   : 0x000004f6d93a0cdb 0x000000009dc9251a 0x0000043c0dcfdcb6
  Wake    : 0x000004f6ddd0e065 0x000000009dbe9342 0x000004f6d9b240ee
Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Zone info:
  Foreign : 0xffffff80275b5000 - 0xffffff80275c3000
  Native  : 0xffffff803fdfa000 - 0xffffffa03fdfa000
  Readonly: 0xffffff850cac6000 - 0xffffff86a645f000
  Metadata: 0xffffffd079f34000 - 0xffffffd09a0bd000
  Bitmaps : 0xffffffd09a0bd000 - 0xffffffd0a00bd000

@zxystd
Copy link
Collaborator Author

zxystd commented Apr 27, 2022

@Overc1ocker It would be most likely happened on ROAM routine. If you find a way to reproduce it, please let me know, and you can try this one to see if it is fixed.
Big Sur.zip
Catalina.zip
Monterey.zip

@usr-sse2 Thank you, can you try this one? and have you also seen this panic on master version?

@usr-sse2
Copy link
Contributor

No, I have seen this panic only today, and it's the first time I've been in the second building.
I can test it but I will need to go there specially for testing.

@Mahasvan
Copy link

Been using this for 2 days, it's quite stable on my AC9560.

@zxystd zxystd added the enhancement New feature or request label May 15, 2022
@singhalrishi27
Copy link

@zxystd upload the latest kext so I can finally test the new algorithm

@Mahasvan

This comment was marked as off-topic.

@williambj1

This comment was marked as off-topic.

@Human79
Copy link

Human79 commented Jul 13, 2022

@zxystd Can you pls provide a Ventura version?
many thanks.

@mikebeaton
Copy link

mikebeaton commented Jul 16, 2023

@zxystd - Ré #898 (comment)

Many thanks for all your work on this project.

This version of the driver does basically fix the issue. Thank you!

There is a minor remaining issue (?), or at least difference between OSes, which I think is just about worth reporting, as below.

As before, all OSes (Windows, Linux (Fedora, current) and macOS Monterey with this version of itlwm) are achieving exactly the same download speed (maybe 480Mbps on first run of Google speed test, 500Mbps+ on second run). But there remains a (much smaller then before) difference in upload behaviour. macOS seems slightly slower than Linux, and is definitely somewhat slower than Windows, for upload speed. The speed differences I am seeing, though I think real (i.e. repeatable on multiple tests), are small enough that I would not have felt them significant enough to report, if I did not already have an issue open.

The behaviour on upload (using Google speed test) for each OS is as follows, each value that I list is shown on screen during the test for maybe 0.1-0.5s; the final value value given is then sustained, with minor variations, to end of test:

  • Windows: 70Mbps-280Mbps
  • Fedora: 50Mbps-70Mbps-250Mbps
  • Monterey: 20Mbps-30Mbps-50Mbps-70Mbps-230Mbps

i.e. Monterey takes noticeably longer to reach full speed, and does not reach quite as high a full speed.

Attached is a log, taken while connecting then running the speed test (with results more or less exactly as given above), with the 2022-4-2 Monterey version of the driver from OP of this thread:

Log_2023-07-16_08-52-12.log

@Inconn
Copy link

Inconn commented Jul 26, 2023

I did some brief testing, and, running on 8260, it's much better. Old kext would vary from super slow to 300Mbps (maximum) during speed tests, and during actual usage it would be too slow to actually be usable.
With this kext, I consistently get around 150-200Mbps on speed tests. I could download a 150Mb app from the App Store in 1-2m, and I can stream 1080p60 video from YouTube without buffering. (other kext would make it switch to 144p)

@zxystd
Copy link
Collaborator Author

zxystd commented Oct 18, 2023

Already merged, thank you for the testing. 2637e90

@zxystd zxystd closed this as completed Oct 18, 2023
@vampirexx78
Copy link

Wifi works great on Sonoma with AX210, but bluetooth not working :-( how to fix?

@KenDxD

This comment was marked as off-topic.

@vampirexx78
Copy link

Thank you buddy, yes i tried put all these three kexts you mention into opencore kext folder but not luck... even adding bluetooth strings on boot-args didn't solve the problem... i'm waiting for any fix or porting from ventura kext to sonoma...thanx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Development

No branches or pull requests