Contribute
Register

M.2 (single-sided type) Wi-Fi/Bluetooth Solution

Status
Not open for further replies.
Further update, I managed to patch my Clover's config.plist with the patch from OP, I still get some KPs mainly while restarting/shutting down or on logins.
 
Further update, I managed to patch my Clover's config.plist with the patch from OP, I still get some KPs mainly while restarting/shutting down or on logins.
who is OP?
 
who is OP?

It's the Original Poster, i.e. you :)

https://www.lifewire.com/what-does-o-p-stand-for-2483372

On another note, I am curious to understand more about the relationship between the standard MacOS kexts (i.e. IO80211Family.kext) and AirportBrcmFixup.kext.

The readme for AirportBrcmFixup seems to imply this card (DW1820a) is natively supported, so I wonder whether there is a way to bypass the native kexts to avoid the KPs...

Anywhere I can read more about this?

Thanks
 
Further update, I managed to patch my Clover's config.plist with the patch from OP, I still get some KPs mainly while restarting/shutting down or on logins.
As you were noticed, using my workaround, you only have problems when booting/shutting down, not when you’re using the WiFi connection, eg: downloading file.
To be honest, I haven’t test my patch when machine sleep/wake up, since I never sleeping my laptop.
Other methods for dw1820a do not better then mine, eg those are crash randomly.
 
It's the Original Poster, i.e. you :)

https://www.lifewire.com/what-does-o-p-stand-for-2483372

On another note, I am curious to understand more about the relationship between the standard MacOS kexts (i.e. IO80211Family.kext) and AirportBrcmFixup.kext.

The readme for AirportBrcmFixup seems to imply this card (DW1820a) is natively supported, so I wonder whether there is a way to bypass the native kexts to avoid the KPs...

Anywhere I can read more about this?

Thanks
Before asking questions, read post #1 carefully.
 
As you were noticed, using my workaround, you only have problems when booting/shutting down, not when you’re using the WiFi connection, eg: downloading file.
To be honest, I haven’t test my patch when machine sleep/wake up, since I never sleeping my laptop.

Yes thank you very much for this patch. It is definitely the most usable, even sleep works properly, the KPs only happen on loading up or shutting down which is not such a big issue.

Before asking questions, read post #1 carefully.

My questions were generic and not related to this patch. Obviously it would be much better if there was a solution which did not involve changing any kext in /S/L/E replacing them with an older version. It could also become a problem with newer version of MacOS.
 
The readme for AirportBrcmFixup seems to imply this card (DW1820a) is natively supported, so I wonder whether there is a way to bypass the native kexts to avoid the KPs...

Anywhere I can read more about this?
My questions were generic and not related to this patch. Obviously it would be much better if there was a solution which did not involve changing any kext in /S/L/E replacing them with an older version. It could also become a problem with newer version of MacOS.
To reach your goal, many technical skills were needed, and your stated question and the method you take for that question may be changed after you learning the foundamental infomation related. So go a further research, and try to understand what cause KP happen, why it happens, and so on....
After doing those, you can finally decide whether a /S/L/E hack were enough or it really need programming / hacking something.
Post #1 containing info I were explored sine the year 2016... One can learn from it, then spread his mind into other related article in this forum....
 
To reach your goal, many technical skills were needed, and your stated question and the method you take for that question may be changed after you learning the foundamental infomation related. So go a further research, and try to understand what cause KP happen, why it happens, and so on....
After doing those, you can finally decide whether a /S/L/E hack were enough or it really need programming / hacking something.
Post #1 containing info I were explored sine the year 2016... One can learn from it, then spread his mind into other related article in this forum....

Thanks for your help, we are lucky to have people like you on the forum. I'll keep reading and researching.
 
10.14.2 goes unstable because the IO80211Family kext for Mojave gets reinstalled you have to disable the card then update and remove the io80211family kext once again. Especially if you put the io80211family kext from Yosemite into the /L/E/ folder because it remains there after the upgrade. Im currently running 10.14.2 with the card still and it works fine. I found the mavericks IO80211family kext works as well and it doesn't cause forced reboots. Ill post it when I get a moment. Or just look on the internet for it Not mavericks Im sorry El Capitain 10.11

Yes I did that thanks

BTW I also got the card working with the Mojave APBCM4360 kext by adding the subset vendor and id number in place of the normal one. So on my card the main string is pci14e4,43a3 and the sub vendor is 1028 with the sub ID being 0023 and if I add it to the plist file of the Mojave 4360 kext in place of 43a3 as pci1028,23 (dropping the zeros) then the card begins working but then experiences a complete takeover of my cpu usage after a half hour or so. Its weird.

I tried that too and got the same issue. I think the poster who proposed this also reported the same issue as the system crawling to an halt.

For me the best configuration is using the Yosemite Kext with @livacore patch from the first post. The system is stable and fast and the only KPs happen on shutdown which I can live with so I'll keep this card for now as it works well in Windows too.

Thanks again for your help
 
Hey @livacore, I have tried to reverse engineering both Yosemite and Mojave version of IO80211Family in order to get DW1820A working.

After observing the logs and many tries, what I have found out it's that a fatal error is trigged at some point after some time with Mojave version and this is triggering another fatal error. When a fatal error is been processed, it causes the device to be reinitialize. The issue is that the device is been already on a reinitialization because of the first fatal error and the second one triggers another full reinitialization but because the device is already busy to be reinitialize, the device freezes and it completely outrun the CPU because it try to fully reinitialize the device until it's done. So I have found out exactly where happens this fatal error triggering. On wlcStart function, on Yosemite, we have at some point :

Code:
mov       rdi, [r12+0EC0h]
xor       r14d, r14d
xor       esi, esi        ; unsigned __int64
call      __ZN11IOPCIDevice20extendedConfigRead16Ey ;
mov       bx, ax
mov       rdi, [r12+0EC0h] ; this
mov       esi, 2          ; unsigned __int64
call      __ZN11IOPCIDevice20extendedConfigRead16Ey ;
mov       r9, [r12+280h]
lea       rcx, [rbp+var_84]
mov       [rsp+0E0h+var_C0], rcx
mov       qword ptr [rsp+0E0h+var_E0], r15 ; char
mov       [rsp+0E0h+var_C8], 0
mov       [rsp+0E0h+var_D0], 0
mov       dword ptr [rsp+0E0h+var_D8], 1
movzx     esi, bx
movzx     edx, ax
xor       ecx, ecx
xor       r8d, r8d
mov       rdi, r12
call      _wlc_attach
mov       [r12+270h], rax
test      rax, rax
jz        loc_FF42


And on Mojave :

Code:
mov       rdi, [r12+9B0h]
xor       r14d, r14d
xor       esi, esi
mov       edx, 2
call      _osl_pci_read_config
mov       r13d, eax
mov       rdi, [r12+9B0h]
mov       esi, 2
mov       edx, 2
call      _osl_pci_read_config
mov       ebx, eax
mov       rdi, [r12+9B0h]
xor       ecx, ecx
cmp       dword ptr [r12+2268h], 0
setnz     cl
lea       rdx, _wl_fatal_error
mov       rsi, r12
call      _osl_set_wl
mov       r9, [r12+9B0h]
sub       rsp, 8
lea       rax, [rbp+var_88]
movzx     esi, r13w
movzx     edx, bx
mov       ecx, 0
mov       r8d, 0
mov       rdi, r12
push      rax
push      r14
push      r14
push      1
push      r15
call      _wlc_attach
add       rsp, 30h
mov       [r12+9A0h], rax
test      rax, rax
jz        loc_16E48


As you see, when the function wlcStart is been running, it's triggering _wl_fatal_error and _osl_set_wl. A random event at some point when the laptop is running triggers again a wlcStart which causes the trigger of the fatal error and _osl_set_wl and I'm pretty sure this is the culprit. I have tried to avoid this calls but I get kernel panic with kernel traps.
 
Status
Not open for further replies.
Back
Top