Chibibowa Posted August 5, 2020 Share Posted August 5, 2020 (edited) Hello folks I'm trying to install MacOS Big Sur from USB and I get an instant kernel panic. MacOS Catalina boots fine (with the same EFI folder). Image and EFI.zip included. Configuration ASUS X99-A (2011-3) Intel Core i7 5960X AMD Radeon VII Latest kexts freshly compiled. OC Version 0.6.0 (Release version). EFI+Logs.zip Edited September 9, 2020 by Chibibowa Link to comment Share on other sites More sharing options...
JahStories Posted August 5, 2020 Share Posted August 5, 2020 Try using NullCPUPowerManagement Link to comment Share on other sites More sharing options...
jmacie Posted August 15, 2020 Share Posted August 15, 2020 @Chibibow did you figure this out? I have the same problem. I tried the nullcoupowermanagement.kext, but it didn't help. Lemme know, Thanks Link to comment Share on other sites More sharing options...
Chibibowa Posted August 19, 2020 Author Share Posted August 19, 2020 I kinda forgot about this post, sorry. I did not manage to fix the issue, nullcpu kext didn't work either. I think it is due to my platform, X99 is a pain in the ass to deal with. The panic is always the same and happens always at the same boot phase. There is definitely something up. Guess I'll have to wait before trying big sur 1 Link to comment Share on other sites More sharing options...
nyu1985 Posted August 19, 2020 Share Posted August 19, 2020 It seems the needed MSR patches to boot X99 are not ready for Big Sur. I have same trouble with both AppleXcpmExtraMsrs or Manual kernel patches. 1 Link to comment Share on other sites More sharing options...
Chibibowa Posted August 29, 2020 Author Share Posted August 29, 2020 But my motherboard is MSR unlocked. I don't need to patch MSR. Maybe there is something wrong in my configuration? EFI Folder (updated since original post) attached. EFI.7z Link to comment Share on other sites More sharing options...
byzyn4ik Posted September 1, 2020 Share Posted September 1, 2020 I have the same issue on friend's ASUS Z10PA-D8 2x2678v3 Xeons, also MSR Unlocked Link to comment Share on other sites More sharing options...
ITzTravelInTime Posted September 1, 2020 Share Posted September 1, 2020 The problems seems to be with the rtc device in the dsdt because oems doesn't map it probperly for big sur, so you need to patch it first Link to comment Share on other sites More sharing options...
Chibibowa Posted September 1, 2020 Author Share Posted September 1, 2020 How can we do that ? Any tutorial somewhere ? 1 Link to comment Share on other sites More sharing options...
jmacie Posted September 1, 2020 Share Posted September 1, 2020 I had to give up. I've asked the opencore devs but they ignore me. I think it's solvable, just gotta wait for BigSur to release then I'm sure someone will solve it, it does suck though. 1 Link to comment Share on other sites More sharing options...
ITzTravelInTime Posted September 3, 2020 Share Posted September 3, 2020 The big sure section of the opencore desktop guide mentions this, i think you shoud take a look Link to comment Share on other sites More sharing options...
jmacie Posted September 3, 2020 Share Posted September 3, 2020 I spent weeks, seriously weeks trying every little combination of things to get my x99 working with BigSur. I read this section, and if you re-read it you will find that the directions are for x299. There are no specific directions for x99. So we wait and hope. I asked @vit9696 for help, but they ignore me. I understand this chipset is old, but there are still many x99s around, so someone will answer this problem definitively when BigSur is released.until then we beg Link to comment Share on other sites More sharing options...
Chibibowa Posted September 3, 2020 Author Share Posted September 3, 2020 In all seriousness tho. If someone is a genius, here is a txt of my exact ACPI tables. You should find all the required info there. DSL code (that is "supposed" to work for X99 systems as well, even if it's not explicitely said): https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-RTC0-RANGE.dsl Kernel panic can be found at the top of this post (CR2 Error: 0x000...20) Hit me up if you need anything else. Because this is beyond my level of expertise, not gonna lie. ACPI Tables - ASUS X99-A.txt (PS: Tables dropped with Read Write Utility: http://rweverything.com/) Here is what I got for RTC (for your convenience): Device(RTC) { Name(_HID, EISAID("PNP0B00")) Name(_CRS, ResourceTemplate() { IO(Decode16, 0x0070, 0x0070, 0x01, 0x02) IO(Decode16, 0x0074, 0x0074, 0x01, 0x04) IRQNoFlags() {8} }) } -- I believe the RTC file from Opencore is incompatible with the X99 platform, hence why we are the last people who need this to be fixed. Even AMD users can get Big Sur to work ! PS: https://github.com/acidanthera/bugtracker/issues/1134 Translation: "Go {censored} yourself" 1 Link to comment Share on other sites More sharing options...
Van06 Posted September 7, 2020 Share Posted September 7, 2020 (edited) Hey Chibibowa, Did you find a solution to install Big Sur Beta? Edited September 7, 2020 by Van06 Link to comment Share on other sites More sharing options...
vit9696 Posted September 7, 2020 Share Posted September 7, 2020 2all, we are aware of X99 issues on Big Sur from b1. They are caused by IOPCIFamily device enumeration changes. It is not clear what exactly is causing the issue without the hardware and the new source code release for IOPCIFamily. At the moment we have no plans to investigate this in the near future. 1 2 Link to comment Share on other sites More sharing options...
ITzTravelInTime Posted September 7, 2020 Share Posted September 7, 2020 What about a kext rollback? better idea: i think that this issue should be solvable using a kext patch on the bootloader side, but this needs someone to do some reverse-engeneering on the kext to at least locate the piece of code causing the system to trigger the kernel panic and then patching that. other idea: About dsdt is there anything we can do inside of it to change device enumeration and related stuff? 1 Link to comment Share on other sites More sharing options...
ITzTravelInTime Posted September 21, 2020 Share Posted September 21, 2020 (edited) Update the problem is with IOPCIFamily after extensive testing and that rtc patch will do extly nothing for this problem, since thereisn't any source code releases for big sur someone need to disassemble IOPCIFamily and look for the symbols that gives us the problem, and also IOPCIFamily needs to be debugged to see which ACPI device triggers those function calls leading to the panic. EDIT: for all the people here try also the actually read the kenrel panic log before starting to reccommend solutions, the cause of the panic is actually there in the panic log most of the time, is especially usefoul to have symbols enbled so you see preciselyh what's going on in the stack Edited September 21, 2020 by ITzTravelInTime 1 Link to comment Share on other sites More sharing options...
hardcorehenry Posted September 21, 2020 Share Posted September 21, 2020 Could you post BigSur last working IOPCIFamily.kext? Link to comment Share on other sites More sharing options...
ITzTravelInTime Posted September 21, 2020 Share Posted September 21, 2020 It never worked, since beta 1, but on catalina it works fine, it also has been changed quite a lot by apple. Anyway what is mostly needed now is a debug of it or of AppleACPIPlatform since the kp is the result of a device initlization made by AppleACPIPlatform which initializes an IOPCIBridge object which then is started and during the start the panic is called reguard one of the function about reding pci registers or pci capabilityes. This is the source code for catalina if you want to take a look https://opensource.apple.com/source/IOPCIFamily/IOPCIFamily-370.141.1/ Link to comment Share on other sites More sharing options...
Schlachtbank Posted September 23, 2020 Share Posted September 23, 2020 Hi, I don't know if this could help, but I have the same kernel panic with Big Sur on an X79. The strange thing is that the same kernel panic occurs also with High Sierra, but every other macOS version supported by my SMBIOS (MacPro6,1) works just fine. I have saved the kernel panic message if someone needs it in a text file, I'm attaching it here. Kernel panic Big Sur.rtf 1 Link to comment Share on other sites More sharing options...
byzyn4ik Posted September 26, 2020 Share Posted September 26, 2020 Have also the same panic on C602 (x79). 3 Link to comment Share on other sites More sharing options...
byzyn4ik Posted October 15, 2020 Share Posted October 15, 2020 I've crated a parch for C602 ,it may works on other X79.DSDT UNC0 _HID to XHIDFind: 554E43 30085F48 4944Replace: 554E43 30085848 4944DSDT UNC1 _HID to XHIDFind: 554E43 31085F48 4944Replace: 554E43 31085848 4944UNC1 related to dual socket but I've think that there is not big problem. For X99 should use ssdt-unc from OpenCore github. 4 Link to comment Share on other sites More sharing options...
ACIDSky Posted October 15, 2020 Share Posted October 15, 2020 X99 work in the BS 2 Link to comment Share on other sites More sharing options...
nyu1985 Posted October 16, 2020 Share Posted October 16, 2020 I already shared my EFI in the kernel patches topics. You can try SSDT-UNC and SSDT-RTCO-RANGE for X99 motherboard in order to pass the kernel panic. It works for me. You can find both ssdt in my OC EFI. EFI.zip 1 Link to comment Share on other sites More sharing options...
Vinicius P. Miranda Posted October 24, 2020 Share Posted October 24, 2020 I Have the Same problem in x79 (Sandy Bridge-E). I'm try a SSDT-UNC in OpenCore 0.6.2 but it didn't solve it. Clover r5125 also did not work. Stuck in: I don't know if this will help anyone, but I realized that in order to have Power Management working well on Catalina, I need the following Patch: both in Clover and OC. I hope there are improvements for the x79 and x99 on BigSur. If anyone knows more news, please tell us. Link to comment Share on other sites More sharing options...
Recommended Posts