Intel 9560NGW - the kext is loaded but no WiFi in Airport menu

[1alessandro1]

Have You Read Our Docs : Yes

Are You Reporting A Bug: Yes, AirportItlwm does not work properly

Environment:

• Kext Version: 2.1.0 stable
• WiFi Card Model: Intel 9560NGW
• PCI Product ID: 8086:34f0
• macOS Version: 12.6.2 (21G320)

Description:

The driver is unable to detect any wireless networks. On linux and windows there is no such issue (on WiFi and bluetooth, everything works with iwlwifi)

Bug Report Archive:

Log_2023-01-04_21-52-34.log

Kext Download Source:

Downloaded from Releases tab here on github.

[1alessandro1]

How do I check if the card is MVM Gen 1 or 2 or 3?

Documentation is unclear to me as the same card is reported both compatible and not compatible

[1alessandro1]

This is an output from dmesg

(Logs in text form) - click this to collapse/fold.

[    3.473256] Intel(R) Wireless WiFi driver for Linux
[    3.473299] iwlwifi 0000:00:14.3: enabling device (0000 -> 0002)
[    3.474389] platform regulatory.0: firmware: direct-loading firmware regulatory.db
[    3.474675] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-72.ucode (-2)
[    3.474679] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[    3.474686] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-72.ucode (-2)
[    3.474688] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-72.ucode failed with error -2
[    3.474699] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-71.ucode (-2)
[    3.474706] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-71.ucode (-2)
[    3.474708] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-71.ucode failed with error -2
[    3.474717] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-70.ucode (-2)
[    3.474725] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-70.ucode (-2)
[    3.474727] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-70.ucode failed with error -2
[    3.474727] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s
[    3.474738] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-69.ucode (-2)
[    3.474752] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-69.ucode (-2)
[    3.474754] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-69.ucode failed with error -2
[    3.474761] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-68.ucode (-2)
[    3.474768] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-68.ucode (-2)
[    3.474769] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-68.ucode failed with error -2
[    3.474778] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-67.ucode (-2)
[    3.474785] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-67.ucode (-2)
[    3.474786] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-67.ucode failed with error -2
[    3.474795] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-66.ucode (-2)
[    3.474801] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-66.ucode (-2)
[    3.474803] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-66.ucode failed with error -2
[    3.474812] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-65.ucode (-2)
[    3.474818] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-65.ucode (-2)
[    3.474820] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-65.ucode failed with error -2
[    3.474828] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-64.ucode (-2)
[    3.474836] iwlwifi 0000:00:14.3: firmware: failed to load iwlwifi-Qu-c0-jf-b0-64.ucode (-2)
[    3.474838] iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-Qu-c0-jf-b0-64.ucode failed with error -2
[    3.476662] iwlwifi 0000:00:14.3: firmware: direct-loading firmware iwlwifi-Qu-c0-jf-b0-63.ucode
[    3.476677] iwlwifi 0000:00:14.3: api flags index 2 larger than supported by driver
[    3.476689] iwlwifi 0000:00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
[    3.477114] iwlwifi 0000:00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    3.477124] iwlwifi 0000:00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    3.477127] iwlwifi 0000:00:14.3: loaded firmware version 63.c04f3485.0 Qu-c0-jf-b0-63.ucode op_mode iwlmvm

[1alessandro1]

I see that iwlwifi-Qu-c0-jf-b0-63.ucode direct link does not fail to load (instead all versions from 72 to 64 are failing).

[1alessandro1]

@dreamwhite and I have tried to load the exact same firmware which gave no issues in Linux dmesg log and had no luck

I will attach here what i have in /lib/firmware from my linux distro (debian based) where iwlwifi works perfectly:

iwlwifi-Qu-c0-jf-b0-63.ucode.zip

For bluetooth (it works perfectly as well)

ibt-19-32-1.ddc.zip
ibt-19-32-1.sfi.zip

[1alessandro1]

@zxystd Any clue on how I might further help providing logs/dumps or anything?

[williambj1]

Sorry for the late reply, both me and zxystd are extremely busy these days.

How do I check if the card is MVM Gen 1 or 2 or 3?

You can use the url provided above in the page that points to the source files and match your adapter's PCI id and sub id to find out the card generation; but that can sometimes be unreliable since Intel reuses the same PCI Id and sub id combinations for different cards, take a look at iwlwifi commits and you'll see that intel themselves also messes up firmware matching because of the id nonsense. We used to have a list in our documentation site but it was way too inaccurate so we ended up dropping it. Gen 1 and Gen 2 can be easily distinguished by checking whether the log says iwm or iwx. It is not very easy to distinguish between Gen 2 and Gen 3, an alternative way would be understanding and checking each and every part of the firmware file's name. I'm 80% certain that you are using a Gen 2 card.

I see that iwlwifi-Qu-c0-jf-b0-63.ucode direct link does not fail to load (instead all versions from 72 to 64 are failing).

That's the normal behavior since older firmware can be loaded on newer versions of iwlwifi and the firmware present in the file system might not always be the latest one supported by iwlwifi. This has nothing to do with itlwm.

itlwm targets the 48 version of the firmware and I can see that iwlwifi-Qu-c0-jf-b0-48.ucode is loaded correctly in the logs. You can replace the firmware with the one from this repo to your linux distro and see if it still works. It shouldn't be a firmware related issue at all.

Ok, so here's the real issue. Your device has RFKILL enabled on Wi-Fi in macOS, it is hard locked by the BIOS firmware. itlwm's code already attempts to unlock the device but if it is locked by the firmware there's nothing that can by done from the kext's side. You might want to try with and without warm rebooting into macOS from other OSes, try having SSDT-XOSI (generally bad practice, but some insane vendors do add OS checks to wireless devices, see #519 (comment)) in the bootloader's config.

[1alessandro1]

Hello, thank you for your response.
I've loaded SSDT-XOSI and the rename as described in the dortania guide:

SSDT present in list:

DSDT rename applied correctly:

Warm reboot done:

No luck so far. Maybe since the laptop I'm using is an HP too (HP 15s-fq1034nl, all ACPI can be found here I should try the same patch @ferdysopian did on his laptop...?

[ferdysopian]

Actually, I am using your EFI with some modifications. Our BIOS is the same. Thank you for sharing your EFI. Currently, you can turn on WiFi by pressing the airplane mode button on the keyboard, but that's not enough for me. So, this is what I changed:

1. Add patch to rename _Q15 to XQ15 ( airplane mode )
2. Add patch to rename WLBT to XLBT
3. Add patch to rename MPTS to XPTS
4. Add patch to rename MWAK to XWAK
   
   I also added all the necessary SSDTs:
   
   SSDT-WLBT.aml ( Always reset WiFi and BT when booting, so it is always on every time the system boots? )
   
   SSDT-PS2.aml ( Make the airplane button force WiFi and BT on, remove the functionality to turn WiFi and BT off )
   
   SSDT-MPTSMWAK.aml ( All outputs turn WiFi and BT on )
   

[1alessandro1]

Thank you for you reply @ferdysopian, it's nice to see that you've used some of the work @dreamwhite and I made.
Can you upload your OC folder so that I can handle those files easily without comping the code by hand? It would be very helpful. Remember to remove the "SMBIOS" section (maybe you use an apple account and you want to hide the serial number you chose)

[ferdysopian]

Sure @1alessandro1 , i've been create new repo for up my OC folder here https://github.com/ferdysopian/14s-dq1013tu-hackintosh

[1alessandro1]

@ferdysopian thank you very much for sharing your work! Now RFKILL is disabled and WiFi and Bluetooth works perfectly in macOS

Does your Airplane mode button work? For me it's not the case, even though I don't think I'll be using it

[1alessandro1]

Small update: as said before, WiFi works correctly but if I put it to sleep it does not come back (RFKILL on)

EDIT: my bad, I forgot to apply MWAK to XWAK and MPTS to XPTS, that's why

[ferdysopian]

Glad to hear that, @1alessandro1 . Hopefully, in the future, the itlwm can override the issue and there will be no need to modify the WLBT, MWAK and MPTS.

Regarding the airplane button, if you want to make it work, you can remove the _Q15 patch but I would recommend using the patch because when you turn on airplane mode and try to turn it off, it only enables WiFi and the Bluetooth remains in airplane mode and need to sleep or restart to trigger the Bluetooth. I don't know how to fix it, but it may be related to some value returned by SGOV in the _Q15

[williambj1]

Glad to hear the issue being solved and thanks for sharing the insights.

Hopefully, in the future, the itlwm can override the issue and there will be no need to modify the WLBT, MWAK and MPTS.

Unfortunately this is out of itlwm's control since it is on the BIOS firmware level. I'm afraid that the only feasible solution might be modifying firmware ACPI tables. The Linux kernel overcomes this issue by hacking _OSI, OSYS, etc, again, unfortunately this is not possible through a IOKit driver.

I'm going to close this issue as it does not appear to be a bug in itlwm's code. Feel free to continue the discussion. I will add a reference to this issue in the docs in case people with similar BIOS firmware run into the same problem. Thanks again for sharing the information.