X299 Big Sur Support

[Loloflatsix]

Ok. I added all of that, but I still get the same hang....any ideas?

Strange : in case it is not an ethernet problem : put your original USB.kext , in config.plist name the section as before ( with your previous : copy /past ) remove the new kext to see if it's wrong.

 

[patrickfogle]

Strange : in case it is not an ethernet problem : put your original USB.kext , in config.plist name the section as before ( with your previous : copy /past ) remove the new kext to see if it's wrong.

The highlighted line is not the issue is it? All of the other kexts have a string in the "Executable Path" field...

 

[Loloflatsix]

The highlighted line is not the issue is it? All of the other kexts have a string in the "Executable Path" field...

No just Bundlepath (if wrong OC will tell you at boot )
I'll be busy until the end of the afternoon but will come back later.

 

[patrickfogle]

Strange : in case it is not an ethernet problem : put your original USB.kext , in config.plist name the section as before ( with your previous : copy /past ) remove the new kext to see if it's wrong.

Ok, I got rid of the USBASUSX299SAGE.kext and added back the X299USB.kext and switched out the names in the config.plist file. Unfortunately, still the same hang on DK: Driverkit......

 

[P1LGRIM]

I still get the same hang....any ideas?

Maybe this ?

Try a forum Search for 1689.

 

[patrickfogle]

Maybe this ?

View attachment 489127

Try a forum Search for 1689.

I did a search and I am not sure how to use what I have seen. Most of the solved posts relate to the SSDT-EC.aml, which is not in my ACPI folder (and it has not been in there previously when it did boot successfully). I do have SSDT-EC-USBX.aml. Is that the same file or different?

 

[P1LGRIM]

Is that the same file or different?

Probably serves the same function.

 

[patrickfogle]

Strange : in case it is not an ethernet problem : put your original USB.kext , in config.plist name the section as before ( with your previous : copy /past ) remove the new kext to see if it's wrong.

We have not found a solution here yet and I thought I would mention 3 things that @@djlild7hina helped with previously that might be relevant:

1. The X299USB.kext I have been using is one that @djlild7hina built/mapped for this board...see here from the X299 - Open Core Support Forum: (Post #717).
2. @djlild7hina also had tweaked the SSDT-X299-TB3HP.aml to give me functionality where it did not function before...see here from the X299 - Open Core Support Forum: (Post #742).
3. @djlild7hina also previously said that the SSDT-X299-Vega64.aml is outdated and should no longer be used...see here from the X299 - Open Core Support Forum: (Post #751).

Please let me know if any of that effects the changes you are trying to help me make. So far, obviously, with your EFI not booting, the original EFI is working better, but the crashes are very annoying. Thanks for all of your assistance @Loloflatsix & @P1LGRIM! Anything we can do to keep troubleshooting this is so helpful! I just do not want to hit a brick wall!!

 

[patrickfogle]

Probably serves the same function.

Thanks, @P1LGRIM, unfortunately, I still don't know what to do with that. I have never worked on this problem or this SSDT before. The current SSDT-EC-USBX.aml worked with the previous EFI. Does the presence of the "apfs_module_start:1689" in the verbose messages always indicate a problem? There seem to be other things that come later before the hang, but what do I know? If anyone has ideas on this, please share.

 

[P1LGRIM]

Does the presence of the "apfs_module_start:1689" in the verbose messages always indicate a problem?

No, it's part of everyone's boot sequence but when the boot stalls at or close to that line then it may point to a missing EC device.