Open CORE Kernel & Kext patch for X99/X299 motherboard

[hardcorehenry]

12 hours ago, ITzTravelInTime said:

 

It works, i get the FWHD device into ioregistry explorer but i still got the same kp, i will continue to look at the differences beetwenn the dsdt of my system and the working one and see if there is anything else in need of a patch

 

Wouldn’t be easier to get IOReg from real iMacPro and check/compare device-ids[(device by device) and “fix” them(either with gfxutil(config.plist>DeviceProperties>Add) or SSDT-hotpatches]? Only suggestion, ignore if it doesn’t make sense.

Edited September 17, 2020 by hardcorehenry

[Mike Ranger]

There is actually a IMac Pro 1,1 to compare... not sure if it helps.

iMac Pro - C02VV5RFHX87 - ars180.21.zip

[hardcorehenry]

SSDT-ARTC made from Cclown98’s DSDT.

 

DefinitionBlock ("", "SSDT", 2, "HACK", "ARTC", 0x00000000)
{
    External (_SB_.PCI0.LPC0, DeviceObj)

    Scope (_SB.PCI0.LPC0)
    {
        If (_OSI ("Darwin"))
        {
            Device (ARTC)
            {
                Name (_HID, "ACPI000E" /* Time and Alarm Device */)  // _HID: Hardware ID
                Method (_GCP, 0, NotSerialized)  // _GCP: Get Capabilities
                {
                    Return (0x05)
                }
            }
        }
    }
}

 

[Cclown98]

@ITzTravelInTime Here you have Both original and patched dsdt, i can't really tell you what is what does not let you boot since i've been using this board for almost 1 year and i patched my dsdt on catalina where i didn't have problems to boot but when I do not use my dsdt (disabled) the crashed are related to IOPCIFamily and NVMe M.2 port (which is PCI as well) and also using a Adata S11 Gamix NVMe disk (which is recognized natively by the OS as supported and gets trim without forcing it, i've teste it on a IMac pro using an adapter)

DSDT-ORIGINAL.aml

DSDT.aml

[Mike Ranger]

Letting the folks know....

Just tried the new beta 7 that was released.... still same situation.

Really crazy... X99 seems to be the most problematic hardware at the moment to transition to Big Sur.

Sigh

[byzyn4ik]

Same panic on x79 too.

[jmacie]

1 hour ago, byzyn4ik said:

Same panic on x79 too.

Hopefully vit9696 will help us. He said it wasn't on his list but if it's an end to x99 and x79 then that's gonna have to be noted in Dortania and why not patch them if possible. I wrote it on reddit, but they erased it because they don't allow un-released software support.vit9696 said it was an issue with iopcifamily.kext that we would have to wait for the source code to fix. Maybe so maybe not, these guys may not help

[jmacie]

2 hours ago, byzyn4ik said:

Same panic on x79 too.

@byzyn4ik 
if you don't mind the scorn of not having a new $2000 system, you could post your KP on the Big Sur and opencore discussion threads, and maybe vit or d-fritz might see it and say something.

[ITzTravelInTime]

On 9/17/2020 at 5:02 PM, hardcorehenry said:

SSDT-ARTC made from Cclown98’s DSDT.

 

DefinitionBlock ("", "SSDT", 2, "HACK", "ARTC", 0x00000000)
{
    External (_SB_.PCI0.LPC0, DeviceObj)

    Scope (_SB.PCI0.LPC0)
    {
        If (_OSI ("Darwin"))
        {
            Device (ARTC)
            {
                Name (_HID, "ACPI000E" /* Time and Alarm Device */)  // _HID: Hardware ID
                Method (_GCP, 0, NotSerialized)  // _GCP: Get Capabilities
                {
                    Return (0x05)
                }
            }
        }
    }
}

 

 

tryed this one too and also combined with the other patches but without luck, but since the problems is pci-related i i am thinking about tweaking stuff related to the m.2 nvme ports

[hardcorehenry]

35 minutes ago, ITzTravelInTime said:

 

tryed this one too and also combined with the other patches but without luck, but since the problems is pci-related i i am thinking about tweaking stuff related to the m.2 nvme ports

 

Now at least you needn’t speculate if presence of devices FWHD and ARTC could be a fix

[Ellybz]

3 hours ago, ITzTravelInTime said:

 

tryed this one too and also combined with the other patches but without luck, but since the problems is pci-related i i am thinking about tweaking stuff related to the m.2 nvme ports

Positive way of approaching problem solving..Brick after brick. Good job to all that contribute. 

[Mike Ranger]

Certainly a good idea to look into Nvme PCI related problems.

Maybe booting from USB works when all devices except GPU are removed?

 

[ITzTravelInTime]

2 hours ago, Mike Ranger said:

Certainly a good idea to look into Nvme PCI related problems.

Maybe booting from USB works when all devices except GPU are removed?

 

 

I am looking for some way to disable the m.2 slot since i also don't use it, i am also tryig to disable on-board devices and to leave as much stuff as i can disabled

[ITzTravelInTime]

Some info i gathered about the kernel panic so far:

 

1) an x99 system has 4 pci device trees, and so the [PCI configuration beging] thing happens 4 times

2) the kernel panic happens after the first [PCI configuration begin] but before the second one, so it might probably be an issue with _SM.PCI1 (the 2nd pci device tree) or _SM.PCI0 (the first pci device tree)

3) reading the panic log with -keepsymbs=1 the function that are called into the stack (related to IOPCIFamily) before the system calls the panic are (in order):

IOPCIBridge.start

IOPCIBridge.probeBus

IOPCIBridge.extendedFindCapability (this one seems related to an address space)

IOPCIConfigurator.findPCICapability

 

The last one is the fucntion which triggers the panic, so this is a problem with information gathered by the APCI i think

 

4)AppleACPIPlatform is involved in all of this but it doesn't seem to be the issue

5) if the problem come from the 2nd pci device tree the pateches attempted by far are useless

 

 

Some other in fo from recent tests:

- @Cclown98's original dsdt looks a lot like my original one (with minor changes), but trying to boot with his modded dsdt still results in the same kp happening

- i don't know of any way to disable the m.2 slot or any pcie slot from the bios, but i can still try to remoove stuff from the dsdt

Edited September 20, 2020 by ITzTravelInTime

[ITzTravelInTime]

On 9/17/2020 at 7:11 PM, Cclown98 said:

@ITzTravelInTime Here you have Both original and patched dsdt, i can't really tell you what is what does not let you boot since i've been using this board for almost 1 year and i patched my dsdt on catalina where i didn't have problems to boot but when I do not use my dsdt (disabled) the crashed are related to IOPCIFamily and NVMe M.2 port (which is PCI as well) and also using a Adata S11 Gamix NVMe disk (which is recognized natively by the OS as supported and gets trim without forcing it, i've teste it on a IMac pro using an adapter)

DSDT-ORIGINAL.aml

DSDT.aml

 

About your m.2 ssd i see it being configured inside the modded dsdt, so it's technically not natively recognized since it had been configured via dsdt, and also all my boot attemots have been on sata or usb drives so far

Edited September 21, 2020 by ITzTravelInTime

[ITzTravelInTime]

15 hours ago, Mike Ranger said:

Certainly a good idea to look into Nvme PCI related problems.

Maybe booting from USB works when all devices except GPU are removed?

 

 

I have also already tried that but without any success

[Mike Ranger]

@ITzTravelInTime

First of all thanks for all your work in this so far. Really appreciated.

This really sounds more and more like a fundamental hardware issue... what really concerns me if a kext patch is needed for that in the future... those usually need regular updates with the underlying kext changes, certainly not ideal.

I am happy to support any testing... on the other hand if no solution is found till X-Mas time (year end) I might just upgrade to a recent Z490 board with new CPU, keeping the rest of my system the same. Let's see how things progress. It would be a bit sad.... many people have put a lot of effort into getting these X99 systems run flawless so far.... i hope Big Sur is not going to kill the X99 platform.

 

[AslashA]

8 hours ago, ITzTravelInTime said:

Some info i gathered about the kernel panic so far:

 

1) an x99 system has 4 pci device trees, and so the [PCI configuration beging] thing happens 4 times

2) the kernel panic happens after the first [PCI configuration begin] but before the second one, so it might probably be an issue with _SM.PCI1 (the 2nd pci device tree) or _SM.PCI0 (the first pci device tree)

3) reading the panic log with -keepsymbs=1 the function that are called into the stack (related to IOPCIFamily) before the system calls the panic are (in order):

IOPCIBridge.start

IOPCIBridge.probeBus

IOPCIBridge.extendedFindCapability (this one seems related to an address space)

IOPCIConfigurator.findPCICapability

 

The last one is the fucntion which triggers the panic, so this is a problem with information gathered by the APCI i think

 

4)AppleACPIPlatform is involved in all of this but it doesn't seem to be the issue

5) if the problem come from the 2nd pci device tree the pateches attempted by far are useless

 

 

Some other in fo from recent tests:

- @Cclown98's original dsdt looks a lot like my original one (with minor changes), but trying to boot with his modded dsdt still results in the same kp happening

- i don't know of any way to disable the m.2 slot or any pcie slot from the bios, but i can still try to remoove stuff from the dsdt

You can try removing 3 PCI three (PCI 1, PCI 2, PCI 3) in DSDT, leaving only PCI0 and using this DSDT for the experiment. As you can see in ioreg, no devices are connected to these PCI lines. I can't do this right now because I'm far away from this computer.

Edited September 21, 2020 by AslashA

[ITzTravelInTime]

4 hours ago, AslashA said:

You can try removing 3 PCI three (PCI 1, PCI 2, PCI 3) in DSDT, leaving only PCI0 and using this DSDT for the experiment. As you can see in ioreg, no devices are connected to these PCI lines. I can't do this right now because I'm far away from this computer.

Yes but as you can see in this picture inside the spoiler there is also what seems to be a second pci device three containing a bunch of system devices, do you see the same thing, wiredly it isn't labeld with PCIX, but with UNC0, what is it? can it be renamed to PCIX?

EDIT:

And also if i post my stock DSDT, can you help me getting it to compile?

Spoiler

Edited September 21, 2020 by ITzTravelInTime

[AslashA]

2 hours ago, ITzTravelInTime said:

Yes but as you can see in this picture inside the spoiler there is also what seems to be a second pci device three containing a bunch of system devices, do you see the same thing, wiredly it isn't labeld with PCIX, but with UNC0, what is it? can it be renamed to PCIX?

EDIT:

And also if i post my stock DSDT, can you help me getting it to compile?

  Reveal hidden contents

The problem is not with the device names. I renamed the devices similar to native macpro7,1, but the problem persists. At the same time, catalina with this dsdt worked fine.
I just tried to remove UNCx devices and there is no more panic during installation. But the installation stops at this step.

If you remove nvme ssd, it stops at the same step, but without the nvme error. Therefore, there is a panic for some device on the UNC0 bus. Now you need to determine which device is in conflict. Today I will try to remove the report from Aida64 and, comparing with Ioreg, determine which devices are on the UNC0 bus.
P.S. I apologize for my English)) I use google translator.

Edited September 21, 2020 by AslashA

[Loloflat6]

On 9/17/2020 at 7:11 PM, Cclown98 said:

@ITzTravelInTime Here you have Both original and patched dsdt, i can't really tell you what is what does not let you boot since i've been using this board for almost 1 year and i patched my dsdt on catalina where i didn't have problems to boot but when I do not use my dsdt (disabled) the crashed are related to IOPCIFamily and NVMe M.2 port (which is PCI as well) and also using a Adata S11 Gamix NVMe disk (which is recognized natively by the OS as supported and gets trim without forcing it, i've teste it on a IMac pro using an adapter)

DSDT-ORIGINAL.aml

DSDT.aml

 

For your NVMe M.2 port have you tried this method linked here by ReHabman : Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading  : 

 

Edited September 21, 2020 by Loloflat6

[ITzTravelInTime]

1 hour ago, AslashA said:

The problem is not with the device names. I renamed the devices similar to native macpro7,1, but the problem persists. At the same time, catalina with this dsdt worked fine.
I just tried to remove UNCx devices and there is no more panic during installation. But the installation stops at this step. Therefore, there is a panic for some device on the UNC0 bus. Now you need to determine which device is in conflict. Today I will try to remove the report from Aida64 and, comparing with Ioreg, determine which devices are on the UNC0 bus.
P.S. I apologize for my English)) I use google translator.

 

Also in the dsdt UNCx and PCI0 schare the same _HID so UNC0 is definelly a PCI Bridge, and by the names of the symbols in the panic log i think that the problem can be with either the _PRT or the _CSM methods relative to UNC0, but this is just speculation

Edited September 21, 2020 by ITzTravelInTime

[AslashA]

Found out what devices are on the UNC0 bus. These devices are all on the UNC0 bus.

 

Spoiler

 

I'm out of ideas.

20 minutes ago, ITzTravelInTime said:

Also in the dsdt UNCx and PCI0 schare the same _HID so UNC0 is definelly a PCI Bridge

Yes, most likely it is.

21 minutes ago, ITzTravelInTime said:

and by the names of the symbols in the panic log i think that the problem can be with either the _PRT or the _CSM methods relative to UNC0, but this is just speculation

How to pinpoint the cause of the panic? I have no idea.

[ITzTravelInTime]

1 minute ago, AslashA said:

Found out what devices are on the UNC0 bus. These devices are all on the UNC0 bus.

I'm out of ideas.

 

Same as me, can you send me a picture of your panic? also asus users seems to require the rtc range patch to get at the same point as i get with a gigabyte board, so i leave the rtc patch here (i listed 2 patches, one for clover and one for opencore):

 

Clover:

<dict>
	<key>Find</key>
	<data>X0NSUxEYChVHAXAAcAABAkcBdAB0AAEEIgABeQ==</data>
	<key>Replace</key>
	<data>X0NSUxEYChVHAXAAcAABBEcBdAB0AAEEIgAAeQ==</data>
	<key>Disabled</key>
	<false/>
	<key>Comment</key>
	<string>RTC Bug fix + IRQ 8</string>
</dict>

OpenCore:

<dict>
				<key>Comment</key>
				<string>RTC regions patch</string>
				<key>Count</key>
				<integer>0</integer>
				<key>Enabled</key>
				<false/>
				<key>Find</key>
				<data>X0NSUxEYChVHAXAAcAABAkcBdAB0AAEEIgABeQ==</data>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data></data>
				<key>OemTableId</key>
				<data></data>
				<key>Replace</key>
				<data>X0NSUxEYChVHAXAAcAABBEcBdAB0AAEEIgAAeQ==</data>
				<key>ReplaceMask</key>
				<data></data>
				<key>Skip</key>
				<integer>0</integer>
				<key>TableLength</key>
				<integer>0</integer>
				<key>TableSignature</key>
				<data>RFNEVA==</data>
			</dict>

 

[ITzTravelInTime]

27 minutes ago, AslashA said:

How to pinpoint the cause of the panic? I have no idea.

 

The best way would be to debug IOPCIFamily with a debugger, and also to check the source code relative to the function that makes IOPCIFamily crash and trigger the panic, apple usually releases this source code, but only some time after the final release.

 

If you read the panic log with symbols activated you can clearly see what's going on in the stack, first the kernel calls the IOConfiguration start for some IO device, wich then calls some device matching functions to look for a kext/driver match for the currently inspected device, which in the case of the panic is an acpi device, specifically a PCI bridge, so AppleACPIPlatform (which seems to be a driver extension now in big sur rather than a kext) is called and then attempts to initialize an IOPCIbridge object from IOPCIFamily, and this initialization process fails when IOPCIFamily attempts to get some address space value, after this there is the crash and the kernel debugger handles the kernel panic putting a bunch of kernel functions into the stack

Edited September 21, 2020 by ITzTravelInTime