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

[livacore]

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 :

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 :

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.

To be an engineer. Read post #1. To be honest, I debug this card sine 2016, one thing I were teached: find the root of the problem, and solve it.
From your states, it may need ferther hacking...

 

[txx1219]

To be an engineer. Read post #1. To be honest, I debug this card sine 2016, one thing I were teached: find the root of the problem, and solve it.
From your states, it may need ferther hacking...

Well, I have read your 1st post, but don't get me wrong, you never resolved the issue with the driver, so you are not also this engineer. I'm sharing you my discover in order to get also yours, but well I see you are not the right person to collaborate for that.

Thanks anyway.

Other thing I discover guys is that a "AXI Timeout" is triggering this fatal_error which reinit the card and triggers another fatal_error behind, which makes the kernel to be completely outrun because of this anormal behavior.

 

[livacore]

Well, I have read your 1st post, but don't get me wrong, you never resolved the issue with the driver, so you are not also this engineer. I'm sharing you my discover in order to get also yours, but well I see you are not the right person to collaborate for that.

Thanks anyway.

Other thing I discover guys is that a "AXI Timeout" is triggering this fatal_error which reinit the card and triggers another fatal_error behind, which makes the kernel to be completely outrun because of this anormal behavior.

Using boot args in post #1, looking at pci register dump. I think the output is useful for you.
I am not a native English speaker.
Be patient. I know all details about de1820a.

 

[dloprios97]

Well, I have read your 1st post, but don't get me wrong, you never resolved the issue with the driver, so you are not also this engineer. I'm sharing you my discover in order to get also yours, but well I see you are not the right person to collaborate for that.

Thanks anyway.

Other thing I discover guys is that a "AXI Timeout" is triggering this fatal_error which reinit the card and triggers another fatal_error behind, which makes the kernel to be completely outrun because of this anormal behavior.

What about when is used the vanilla 4360 driver in Mojave. After spoofing the card with a compatible id.
In Mojave, 4360 is, at least, the only driver that works best for this card for almost two hours before blocking the system. No kernel panics whatsoever...

 

[livacore]

What about when is used the vanilla 4360 driver in Mojave. After spoofing the card with a compatible id.
In Mojave, 4360 is, at least, the only driver that works best for this card for almost two hours before blocking the system. No kernel panics whatsoever...

I found IO80211Family.kext in 10.10.5 (see attached file) can works on 10.11.6, 10.12.6, 10.13.5, 10.14, but it may cause panic.

As I mentioned in post #1, driver changed after 10.11.x.
One should install as older version as you can. Using boot args in post #1, to collect panic log, then post here.

 

[livacore]

https://en.m.wikipedia.org/wiki/PCI_configuration_space
Have you read this?

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

Do you mean a random event is pci config operation?

Other thing I discover guys is that a "AXI Timeout" is triggering this fatal_error which reinit the card and triggers another fatal_error behind, which makes the kernel to be completely outrun because of this anormal behavior.

Have you search the relationship between AXI and Pcie configurations space?

call _osl_pci_read_config

Have you noticed this line: there are some osl pci read/write operations before driver initialization. They operate pci configuration space.

I'm pretty sure this is the culprit. I have tried to avoid this calls but I get kernel panic with kernel traps.

I found IO80211Family.kext in 10.10.5 (see attached file) can works on 10.11.6, 10.12.6, 10.13.5, 10.14, but it may cause panic.

As I mentioned in post #1, driver changed after 10.11.x.
One should install as older version as you can. Using boot args in post #1, to collect panic log, then post here.

To reach the goal, one need little OS X kernel programming, debugging, and high level disassemble tools may need.

Non English speaking people hard to express the well logical using English, but all above is all I know.
I also have other experience which may not help directly. If you have questions, I’d like to answer.

 

[ameeno]

I have this card, suprised wifi worked out of the box flawlessly without mods. but sometimes i cant boot my system. do you think it is related to card?

When i put in the old drivers, My system freezed up!!!!

 

[dloprios97]

I have this card, suprised wifi worked out of the box flawlessly without mods. but sometimes i cant boot my system. do you think it is related to card?

When i put in the old drivers, My system freezed up!!!!

That is amazing.. It really is.. Many people have had success with this card due to the way different laptop brands handle PCI requests.
If you what to know why your build is crashing. Just boot with verbose activated.

 

[ameeno]

That is amazing.. It really is.. Many people have had success with this card due to the way different laptop brands handle PCI requests.
If you what to know why your build is crashing. Just boot with verbose activated.

Hi.

My investigations have shown that Apple makes .__ files inside CLOVER folder.

Also other Kexts didnt work such as AirportFixup caused problems.

And also the latest version of Brcm from rehabman did not working, i had to use a specific version in this repository.

The patch i have settled with so far is: Using the Brcm patch files from this enclosed Zip, The kernel patches from the 1st post, and i have left the standard IO80211 Kexts from apple (The less mods the better.)


Anyway, now i have bluetooth working which is great!

 

[midi1996]

@livacore

idk if this thread is still maintained, the waitq patch isnt working for 10.14.3 and later.

Attached panic log for 10.14.3