Pavo

The reason you guys are seeing huge increase in speed is because the TSC timing is set to a higher rate than the CPU frequency. It is similar to not using invariant timing, each tick of the timer gets mutiplied against itself.  Most of the stuff related to the Datahub is related to timing and frequency settings, by disabling it you basically take what is in your ACPI tables which are only for machine startup, then the kernel suppose to recalculate those, which doesn't happen in macOS because it doesn't support AMD CPUs natively.

7 hours ago, iGPU said:

 

I did change config slightly. When DisableLinkeditJettison was enabled, ß7 would not boot (as it would into ß6), so I disabled and added keepsysms to boot-arg:

B7 is booting fine for me with DisableLinkeditJettison enabled and no boot-args.

AMD hacks are now working with beta 7 using new kernel patches, thanks to Algrey from AMD discord server https://github.com/AMD-OSX/AMD_Vanilla/tree/experimental-opencore

9 hours ago, fabiosun said:

Who do not believe in your testing?

in my case as I said you and others in discord channel I have used Penryn because my vm config has always worked in this way with Big Sur installation step
After installation I can always use my usual vm config

but as you know also host cpu in vm does not mean it is the same as bare metal.

I hope it does not need of many efforts in kernel patching.

 

 

Howewer algrey asked to try a new one on discord (AMD ones)

:

try to bypass the function : 
FIND : E8 5C 61 01 00
REPLACE : 0F 1F 44 00 00

or this
FIND : E8 E3 7B FF FF 48 85 C0 0F 99 05 B9 89 A0 00 48 8D 35 B2 89 A0 00 48 8D 3D 68 C9 74 00 BA 01 00 00 00 31 C9 E8 3F 67 6B 00
REPLACE : 66 66 66 0F 1F 84 00 00 00 00 00 66 66 66 0F 1F 84 00 00 00 00 00 66 66 66 0F 1F 84 00 00 00 00 00 0F 1F 84 00 00 00 00 00

 

Been working with Algrey on discord.... The first one gets past the sticking point but kernel panics and instant reboots after ACPI tables load and can not get a good video of the panic itself, have tried multiple times.

FIND : E8 5C 61 01 00
REPLACE : 0F 1F 44 00 00

The second one does not get found at all.. Algrey is aware.

Ok.... was about to update without issues using UnRAID, cpu is set to host and no issues. Tried to boot back into bare metal after update was complete, nogo. So.. its gotta be a kernel patch that needs to be updated. Going to test each kernel patch while in UnRAID to see if I can identify which patch needs to be updated. Also just too prove that CPU is set as host and booting without issues, here is a pic (not photoshopped like some people think I might do).

In my opinion we shouldn't be putting EFIs or snippets in the thread itself but use a GitHub repo so everyone can collaborate with forks and merges or if there is major differences, have configs to specific systems in the repo. This would eliminate anything in the past to present issue.

The config structure is the same for all systems and change on OC updates, which can be maintained on the repo itself.

1 hour ago, iGPU said:

 

Aquantia is supported natively through Mojave (and I thought ok in Catalina), but Big Sur requires a kernel patch. The inactivation has nothing to do with SSDT or MmioWhitelist.

 

Pavo has provided this on another forum. Here it is below (as written this will work on HS thru BS; if you only want for Catalina-BS, change 17.0.0 to 19.0.0):

 

That was a typo at the time I posted a screenshot of that. That patch only works with BigSur beta 3 and above.

55 minutes ago, fabiosun said:

1) Without patch 

2) proxmox

3)with patch

Thought you said on discord yesterday that removing the Fix PAT effected Bare Metal in HS heavily?

10 hours ago, iGPU said:

 

I'd already removed this when reducing the patch list down to 13 total patches. The GPU performance on C15 increased from a very low 67 to 97 FPS without Fix PAT.

 

When I added the modified DSDT file, the GPU further increased to 140 FPS.

 

Did you try the modified DSDT file?  It should work since we use the same mobo. I derived it with Above 4G enabled, and did not check if this setting affects the DSDT file.

I did not because I do not used custom DSDTs, if you can provide the exact modifications you did I can replicate them with a SSDT. I also created a ACPI delete entry to remove the ACPI error that we were getting see below in the pic. This removes the ShakTooth table that is trying to overwrite the WMI1 device that already exist in the DSDT and causes the ACPI error.

Just wanted to give everyone an update on the GPU performance fix, it is 100% the last kernel patch, Fix PAT. Disable it and see if you can still boot and if you can, your GPU performance will be like it should be. Currently trying to get the AMD devs to re-work the patch so all AMD systems can benefit from it using the PAT fix without hindering the GPU performance.

You should not use a custom patched DSDT from a different system, not even if you applied common patches. Every patch that can be done in a DSDT can be converted to a SSDT.

14 minutes ago, iGPU said:

 

Really? I thought the range is contiguous, so that min 17.00 and max 20.99 would be as fabiosun said (HS, Mojave, Catalina and Big Sur). The only way to isolate a patch is to duplicate.

 

Example, this will exclude Catalina, and only be active for HS, Mojave and Big Sur (if both enabled):

 

one patch set to:     : min 17.00, max 18.99

duplicate patch set:  min 20.00, max 20.99.

This is correct, I was saying that Min 17.x.x with Max 20.x.x would be applied to High Sierra, Mojave, Catalina and Big Sur. It would not stop with just Catalina. Maybe I misinterpreted what he was saying. 

12 minutes ago, fabiosun said:

for others:

17 mean high sierra

18 means mojave

19 means catalina

20 means big sur

This is correct. 

13 minutes ago, fabiosun said:

so min 17

max 20.xx

means used if set to yes from high Sierra to Catalina 

This is incorrect Min 17.x.x with a Max of 20.x.x means used if set to enabled (yes) from High Sierra to BigSur. Not Catalina

@fabiosun I would agree with you but the kernel patches they provided are based off what they added back in the day to compile a kernel for AMD specifically when they were using Clover. It is always good to validate what patches are needed or not needed in my opinion. I have had tons of discussions this with algrey and Shaneee before to get a better understanding of exactly what each individual kernel patch is doing. There are quite a few patches that are applied simply to avoid a kernel panic on certain function calls that was being produced back in 10.12 era. They simply apply the same methodology on every update instead of going through each new kernel to get the bare minimum kernel patches needed.

15 minutes ago, meina222 said:

Here is the VM score. VM EFI booting into the bare metal NVMe installation. Consistent with previous marks, except for the outlier scored in the Bare Metal with "reduced" patches (dark orange vs bright orange). The 144 fps score seems anomalous. What is the story with the set of reduced patches and why are they "not recommended"?

The story is from me, I decided to try and reduce the amount of kernel patches applied for AMD system and simply did a test of disabling one patch at a time and seeing if I could boot and checking my WoW game performance. Once I got to the point of my WoW game performance was like it should have been from the beginning I stopped reducing the patches. The reason they are not recommended is because it is not consistent across all AMD systems on what patches can be removed and provide the GPU gaming performance increase.

On 8/30/2020 at 4:36 PM, Jaidy said:

Is there anyone using an external audio DAC (preferably connected via USB) on this forum? 

Using Sound BlasterX G6 USB DAC, working perfectly fine.

Yeah, update went smooth as a baby's ass.

27 minutes ago, meina222 said:

The origin of this custom frame buffer dates back to Catalina VM and my attempts to figure why 5700XT shows really poor OpenCL and Metal scores (e.g. 38K for Metal), where it should be closer to 70. I clearly didn't come up with this "solution" myself, but with this in place Catalina's scores would go back up to 75K where they should be. This is a pretty opaque and useless benchmark - Geekbench, and I guess the effect of this is similar to what a boost kext used to do for Radeon VII.

Yeah I figure this much, but you can do all that in your GFX SSDT and it only requires 3 of the 40+ settings you currently have in the Device properties section of the config. The performance gain is not from the frame buffer settings but from the `ATY,EFIVersion`and `ATY,EFIRom` values, if you look at the ACPI folder I uploaded from mine, my GFX SSDT has those as well. The RX 5700 XT can not use the `PP_WorkLoadPolicyMask` settings of my SSDT though, so do not include that into your SSDT.

1 hour ago, meina222 said:

MyMacPro.zipEFI.zipAttaching both EFI and IOReg file.

 

I made some attempts to streamline my SSDT's using your config.plist as reference as you have a stable setup. But some of them are different (AIC disables my zfs raid NVMEs, ETH is iGPU's ETH rename, I also added SBUS - not sure if it's helping).

 

Definitely my system requires DummyPowerManagement in its current form. Any attempt to disable causes a panic 1 min into a session (after a successful login). It's almost deterministic in the way it fails and always with 1 min or so delay causing reboot:

A few things I notice you really shouldn't be doing.... You should not be specifying a specific frame buffer (see pic of highlighted below) for the dGPU, RX 5700 XT works perfectly fine when using the default frame buffer. Also do not need all these other properties in the Device Properties section of your config for the GPU. Nor do you need to add a property or `built-in` to any devices using Device properties section of the config. If you want a device to show as `built-in` you simply create a SSDT and give said device a ACPI name and add it to the appropriate scope that the devices falls under and the device will by default be assigned as `built-in`.  Have you tried booting without the `npci=0x2000` boot-arg? I do not need this boot-arg and don't think any other TRX40 system needs it either.

What exactly is the SSDT-AIC for? I am not tracking anything the about a `class-code` change needed for a pci-bridge on our systems at all.

Method (_SB.S0D2.D2B1.D0D1._DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
    {
        If (LNot (Arg2))
        {
            Return (Buffer (One)
            {
                 0x03                                           
            })
        }

        Return (Package (0x04)
        {
            "class-code", 
            Buffer (0x04)
            {
                 0xFF, 0x08, 0x01, 0x00                         
            }, 

            "built-in", 
            Buffer (One)
            {
                 0x00                                           
            }
        })
    }

1 hour ago, meina222 said:

@Pavo - Here it is. Thank you!

 

System DSDT.zip 14.71 kB · 0 downloads

So... your HPET is exactly like mine and @iGPU system.  Here is yours....

Device (HPET)
    {
        Name (_HID, EisaId ("PNP0103"))  // _HID: Hardware ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (LEqual (HPEN, One))
            {
                If (LGreaterEqual (OSVR, 0x0C))
                {
                    Return (0x0F)
                }

                Store (Zero, HPEN)
                Return (One)
            }

            Return (One)
        }

        Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
        {
            Name (BUF0, ResourceTemplate ()
            {
                IRQNoFlags ()
                    {0}
                IRQNoFlags ()
                    {8}
                Memory32Fixed (ReadOnly,
                    0xFED00000,         // Address Base
                    0x00000400,         // Address Length
                    )
            })
            Return (BUF0)
        }
    }

Here is mine....

Device (HPET)
    {
        Name (_HID, EisaId ("PNP0103"))  // _HID: Hardware ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (LEqual (HPEN, One))
            {
                If (LGreaterEqual (OSVR, 0x0C))
                {
                    Return (0x0F)
                }

                Store (Zero, HPEN)
                Return (One)
            }

            Return (One)
        }

        Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
        {
            Name (BUF0, ResourceTemplate ()
            {
                IRQNoFlags ()
                    {0}
                IRQNoFlags ()
                    {8}
                Memory32Fixed (ReadOnly,
                    0xFED00000,         // Address Base
                    0x00000400,         // Address Length
                    )
            })
            Return (BUF0)
        }
    }

So... I am not sure why you are having HPET issues, please upload your entire EFI Folder.

Below is an example of changing a ACPI method of a device.

DefinitionBlock ("", "SSDT", 2, "APPLE ", "HPET", 0x00001000)
{
    External (HPET._STA, UnknownObj)

    Scope (_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            \HPET._STA = 0x0F
        }
    }
}

now... the \HPET._STA depends on the location of HPET in your original DSDT. This is what I used on my MSI MPG X570 Gaming Edge WiFi when I was using a 3950X. It is not needed on my MSI Creator TRX40 system. @meina222 If you upload your DSDT I can modify this to meet your system needs.

9 hours ago, meina222 said:

The last 4 turned off, everything else checked works for my MMIO (shutdown + NVRAM). So I think I will stick to that scheme given everybody's findings.

 

Something I noticed in @Pavo's config.plist (and I believe @fabiosun mentioned that he has it too) is that DummyPowerManagement is OFF. If I leave it OFF my system starts to exhibit instability and reboots 1-2 min into a session with the following dump. Since @Driftwood has it ON, it doesn't seem it affects sleep (my last problematic area, monitor sleeps but not PC and fans), I wonder what is the guidance on that, and how do those who have it OFF not experience issues similar to the dump below.

 

panic(cpu 0 caller 0xffffff800b6cea11): CPU 63 has no HPET assigned to it

Backtrace (CPU 0), Frame : Return Address

0xffffffa3c7d6bc60 : 0xffffff800a2be6ad mach_kernel : _handle_debugger_trap + 0x3dd

0xffffffa3c7d6bcb0 : 0xffffff800a3fef13 mach_kernel : _kdp_i386_trap + 0x143

0xffffffa3c7d6bcf0 : 0xffffff800a3ef96a mach_kernel : _kernel_trap + 0x55a

0xffffffa3c7d6bd40 : 0xffffff800a263a2f mach_kernel : _return_from_trap + 0xff

0xffffffa3c7d6bd60 : 0xffffff800a2bdf4d mach_kernel : _DebuggerTrapWithState + 0xad

0xffffffa3c7d6be80 : 0xffffff800a2be238 mach_kernel : _panic_trap_to_debugger + 0x268

0xffffffa3c7d6bef0 : 0xffffff800aab9f1a mach_kernel : _panic + 0x54

0xffffffa3c7d6bf60 : 0xffffff800b6cea11 com.apple.driver.AppleIntelCPUPowerManagement : _pmInitThread + 0x2c0

0xffffffa3c7d6bfa0 : 0xffffff800a26313e mach_kernel : _call_continuation + 0x2e

      Kernel Extensions in backtrace:

         com.apple.driver.AppleIntelCPUPowerManagement(222.0)[A5C47275-91D0-3F66-8C16-DE6FE6DA5701]@0xffffff800b6c8000->0xffffff800b6e5fff

 

Process name corresponding to current thread: kernel_task

Boot args: -v -wegbeta agdpmod=pikera npci=0x2000 alcid=1 keepsyms=1

 

Mac OS version:

20A5354i

 

Kernel version:

Darwin Kernel Version 20.0.0: Fri Aug 14 00:25:13 PDT 2020; root:xnu-7195.40.44.151.1~4/RELEASE_X86_64

Kernel UUID: F29B97A1-72E4-3D36-863F-8ADCCB731F78

KernelCache slide: 0x000000000a000000

KernelCache base:  0xffffff800a200000

Kernel slide:      0x000000000a010000

Kernel text base:  0xffffff800a210000

__HIB  text base: 0xffffff800a100000

System model name: MacPro7,1 (Mac-27AD2F918AE68F61)

System shutdown begun: NO

Panic diags file available: YES (0x0)

Hibernation exit count: 0

 

System uptime in nanoseconds: 91199401734

Last Sleep:           absolute           base_tsc          base_nano

  Uptime  : 0x000000153be871eb

  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000

  Wake    : 0x0000000000000000 0x000000279ec5219c 0x0000000000000000

 

 

Some AMD systems has HPET issues, and this KP is exactly that.  The DummyPowerManagement quirk does nothing for AMD, I have proven this time and time again with previous AMD systems like X570 and now TRX40 but some of the AMD discord people don't listen and have given vit9696 suggestions that aren't needed. You can create an SSDT to change the _STA method to turn HPET on, let me look through previous SSDTs I have made and I can post it.

Ok... so after doing a little more testing it would seem the first 0x10400 address enabled cause some side effect issues with USB controllers. Started having random disconnects from varies devices.

19:131 00:019 OCABC: MMIO devirt 0x2040000000 (0x10400 pages, 0x8000000000000001) skip 0

So.. I changed mine to disable that first address from the 0x10400 section. Will report anymore findings.

Just now, Driftwood said:

Not using your addresses. I am using my MMIO, just switching off last 3

Ok.... just wanted to make sure you understood what I wanted to be tested.

26 minutes ago, Driftwood said:

Keyboard and mouse go off (USB) when using Pavo's last three only in Catalina. Last four =NO for me, and keyboard and mouse stay on 🙂

 

Last 4 NO seems to agree with insanelyMac vit9696 guy then?!

 

I didn't mean for you to use my addresses, I meant for you to disable only the last 3 addresses of your MMIO list.