[Request Test] New rate adaption algorithm for gen1 devices.
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.
What should be tested? That it just works without crashes/disconnections or connection speed improvement?
@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.
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?
What improvements this will bring to the table?
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
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.
@Overc1ocker Is it reproducible? And the same panic info?
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
@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
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
@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?
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.
Been using this for 2 days, it's quite stable on my AC9560.
@zxystd upload the latest kext so I can finally test the new algorithm
@zxystd could you give us a Ventura version for this please? Or perhaps itlwm, if that will work?
@KenDxD Please file a separate issue report.
@zxystd Can you pls provide a Ventura version? many thanks.
@zxystd - Ré https://github.com/OpenIntelWireless/itlwm/issues/898#issuecomment-1633723854
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:
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)
Already merged, thank you for the testing. 2637e9014b7af098974c8d6db69230f75fb20a90
Wifi works great on Sonoma with AX210, but bluetooth not working :-( how to fix?
Wifi works great on Sonoma with AX210, but bluetooth not working :-( how to fix?
I'm also trying to fix it also on my Sonoma build but no luck, It's the only one that didn't work on Sonoma, I'm going back to Ventura because I fixed all of the issue even sleep. Here's what I did to fix it on Ventura and trying to do it on Sonoma, I get the BluetoolFixup.kext from acidanthera/BrcmPatchRAM then IntelBluetoothFirmware.kext and IntelBTPatcher.kext from OpenIntelWireless/IntelBluetoothFirmware, try it if does work on your build.
Edit: Hiding this comment because it's off-topic
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