meina222

They are massive on paper and I'm sure AMD will have a hard time matching that. AMD's advantage will be Zen3 + their new cards as package. Apple's ultimate goal is to completely seal themselves off hardware-wise - they will slowly start dropping AMD in the low energy space 1st and in 5-7 years aim to move the entire line up to Apple silicon both CPU and graphics. They will still have a very hard time competing with Nvidia, but I don't think their goal is do that. I have no idea what personal animosity exists between the two companies / CEOs though, but clearly they need AMD still, but once ready will drop both and achieve their pipe dream from the 80s/90s of having again a vertically integrated proprietary stack. And I gotta say I can't fault them for that - it works very well as a model when you execute it the way they do.

Yean on paper. But I think Driftwood meant that the 2TB rocket might still be faster than the lower rocket+ depending on cache sizes. I haven't seen any benchmarks anywhere yet.

I presume you have to compare 4 plus 2TB and 4 2TB as apples to apples. It's possible 4 plus 1TB is practically not as fast as regular 2TB. Not sure it matters though, I was just joking. I do need another NVMe though so I'll wait for the plus to hit and maybe get 2TB.

@fabiosun - I cracked the sleep issue. Or rather - I determined that sleep is impossible for 3990x. The reason is SMT off. Even under Linux (Ubuntu 20.04 with latest kernel 5.8.5) sleep doesn't work with SMT off - the disabled logical cores can't be turned off. MacOS actually behaves nicer since after it fails to sleep the CPU, it does sleep the monitor and can wake it up. Linux just goes dark and refuses to wake up and has to be power cycled. On the other hand Linux sleep works perfectly with SMT on as it should. This of course doesn't mean that if I had 3970x sleep would work - I hope @Ploddles will find out for the benefit of the other GB mobo owners.

@fabiosun - I actually did check ioreg, but not before I applied the SSDT. For example, I could not find anywhere the EFI version (doesn't mean it isn't there). And I did not see any difference in benchmarking between having the SSDT and not having it. So by "understood" - in my own standard of what that means, no I have not understood yet what it did. Edit: ATY,EFIVersionB is there, could not locate primary.

@Pavo - I adapted my vbios to your GFX0 SSDT minus the PP_WorkLoadPolicyMask. Boots and works fine. GeekBench benchmark is definitely affected - 75K in device properties frame buffer vs 58K with SSDT but not too concerned about it (2 tries so not variance in measurement). Also removed npci=0x2000. All good, so this matches your experience. The simpler the better (right now I'm above 4G off, CSM off, no npci) Sleep still doesn't work unfortunately. But the issue is elsewhere. Either USB, BIOS or AIC NVME card, or the 3rd party BCM94360CD. Attached updated GFX for you to check. Not sure if the Package and Buffer values need to be changed. How do I know the SSDT is working? SSDT-GFX.zip

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. SSDT-AIC is for my GB AIC 4x4x4x4 splitter card. I have 4 NVMEs running software raid on zfs. I use them for VM pools (my MacOS VMs are there). MacOS tries to mount these and zfs is not recognizable. I wanted a way to disable this in SSDT tables as if the disks didn't exist. Again found this solution and adapted PCI id's from somewhere (can dig out reference if needed). I guess an alternative would be to not auto mount via some MacOS setting, but I don't know how to do it and I'd rather have it as if the devices are disabled in firmware. The built-in is for my 211 cards. Didn't know how to do it via SSDT. Not tried w/out npc=0x2000. Will do when I get off work.

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: 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

@Pavo - Here it is. Thank you! System DSDT.zip

Can someone explain to me "DummyPowerManagement" and how do you guys leave it OFF. My system becomes very unstable. Can this "CPU xx has not HPET assigned to it" error be fixed with SSDT? I thought HPET is on by default in BIOS (I couldn't find any option to set it or turn it on/off).

5) no all AMD platform need of devirtualizemmio stuff I think I meant AMD TRX40. I wouldn't know about others as I never did Hackintosh on other AMD.

Off-topic. Now that this is out, I need to buy it 🙂 https://www.sabrent.com/rocket-4-plus/

@fabiosun, these are excellent questions. I feel that we need to post more of those with hopefully insightful answers that deepen our understanding and reduce trial and error. I will take a very crude stab at what "I think" this MMIO devirtualise (definitely not spelled by an American) refers to, but this is a very superficial attempt as I don't know well the memory mapping of hardware. 1st one needs to understand MMIO (I actually never read that article myself until now but pasting it anyways) https://en.wikipedia.org/wiki/Memory-mapped_I/O Notice how there's a table in there that has memory address ranges. Computer memory can be pictures as a tape with a list of contiguous addresses that are just hexadecimal numbers separated by a fixed distance dependent on the architecture (e.g. 8 bytes). Some of this memory is allocated to hardware devices and this is where MMIO (memory mapped IO) comes in. Now, it gets a bit more complicated. "Virtual memory" refers to the fact that a system can see "fake" logical addresses that have some sort of translation to real physical addresses that can be read from or written to. Why do that - because it's convenient for software to think of memory as 1 tape, but in reality memory has many levels such as CPU registers, caches, main memory, disks etc (you can even insert magnetic tapes here). The "fake" logical addresses are called "virtual" and the real one "physical". Physical addresses are complicated to deal with as they can be spread among different types of hardware, so logic exists to translate between the 2. This concept is "central" to OS-es (every modern OS really) - this allows your software to fancy it has this large tape of memory where in reality there's a complex bookkeeping system to manage many devices behind that fake tape. You can read about this here: https://en.wikipedia.org/wiki/Page_table So far we haven't really said how the concept of "virtual memory" applies to MMIO and what does this have to do with the MacOS kernel. It seems that the memory ranges given as examples in https://en.wikipedia.org/wiki/Memory-mapped_I/O are also virtual. This is an educated guess on my part - I can only makes sense of it this way. What this means is that besides the address ranges in these tables, you have to store bookkeeping information on how to translate these "virtual" addresses to "physical" ones. Such info in the form of lookup tables itself takes memory. Seems that as the MacOS kernel grew, and also KASLR (randomized loading) was introduced (itself a complicated topic I know little of), it became harder for it to fit into certain restricted memory areas where a kernel is supposed to load as it couldn't find space among these MMIO bookkeeping ranges. By "de-virtualizing" OC is able to prevent / bypass such bookkeeping info for certain address ranges, thus saving memory and allowing the kernel to fit. I'd love for someone to give more detail on that or let me know if I'm being inaccurate. What I don't know is how this "bypassing" translates to corruption such as Shutdown not working or other issues not observed. If you "devirtualize" too much, you free more memory but you mess the OS interacting with these ranges when it loads. If you don't devirtualize you can't fit the kernel. So to answer your questions (as an educated guess, I must admit): 1) Means that virtual addresses are not used for certain MMIO ranges saving memory on lookup/bookkeeping to translate virtual addresses to physical ones 2) When I use the term "on" I refer to the config.plist MMIO whitelist ENABLED boolean checkbox - "on" is same as ENABLED=YES. I would think that if you select "DevirtualiseMmio" and don't provide any addresses, then the entire range is implicitly "skip=0" (ENABLED=NO). This means we do not skip devirtualizing, which is a very twisted way of saying that we devirtualize and free up the max amount of memory. But then we mess with hardware / OS interaction later on. 3) skip 0 is just OC logging that you instructed ENABLED=NO. skip 1 is opposite. If you skip=1 everywhere you skip devirtualization, leaving everything virtual. If you set ENABLED=NO everywhere you devirtualize everywhere. 5) As this is my 1st Hackintosh project, the answer is "I don't know" - seems to depends on the firmware and memory map. Clearly the VM didn't need it. TRX40 seems to need it. My guess that all boards followed a reference AMD template, which would need it.

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

Thank you. No, I didn't know. I have quite a few gaps in various topics including how the EC works on a real Mac. The Proxmox VM I started 2 months ago is my 1st Hackintosh project and now this is the 2nd. I collect knowledge in bits and pieces and a lot of it is by pattern matching, and not always (sadly) having deeper understanding.

@Pavo, @fabiosun - do you mind also sharing your ACPI folders? I want to match mine - I see potential differences based on Pavo's config.plist My EC file now looks like below. Is this correct or is there too much ? /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20200110 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * * Disassembling to symbolic ASL+ operators * * Disassembly of iASLCTFB6U.aml, Mon Aug 31 15:03:10 2020 * * Original Table Header: * Signature "SSDT" * Length 0x000001AE (430) * Revision 0x02 * Checksum 0xA2 * OEM ID "ACDT" * OEM Table ID "EC-SBRG" * OEM Revision 0x00001000 (4096) * Compiler ID "INTL" * Compiler Version 0x20200110 (538968336) */ DefinitionBlock ("", "SSDT", 2, "ACDT", "EC-SBRG", 0x00001000) { External (_SB_.PCI0, DeviceObj) External (_SB_.PCI0.SBRG, DeviceObj) Scope (\_SB) { Device (USBX) { Name (_ADR, Zero) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If ((Arg2 == Zero)) { Return (Buffer (One) { 0x03 // . }) } Return (Package (0x08) { "kUSBSleepPowerSupply", 0x13EC, "kUSBSleepPortCurrentLimit", 0x0834, "kUSBWakePowerSupply", 0x13EC, "kUSBWakePortCurrentLimit", 0x0834 }) } } Device (SLPB) { Name (_HID, EisaId ("PNP0C0E") /* Sleep Button Device */) // _HID: Hardware ID Name (_STA, 0x0B) // _STA: Status } } Scope (\_SB.PCI0.SBRG) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If ((Arg2 == Zero)) { Return (Buffer (One) { 0x03 // . }) } Return (Package (0x06) { "device-id", Buffer (0x04) { 0xC1, 0x9C, 0x00, 0x00 // .... }, "vendor-id", Buffer (0x04) { 0x86, 0x80, 0x00, 0x00 // .... }, "compatible", Buffer (0x0D) { "pci8086,9cc1" } }) } } Scope (_SB.PCI0) { Device (EC) { Name (_HID, "ACID0001") // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { Return (0x0F) } Else { Return (Zero) } } } Device (MCHC) { Name (_ADR, Zero) // _ADR: Address } } }

@Pavo - I just tried your proposed address scheme. My 0x10400 pages addresses are different but the rest are the same. It boots. No slide required, Nvram works, Shutdown works. Sleep still doesn't - but I suspect this is due to my own hardware or USB. I certainly don't have USB mapping although that is by no means the reason for the sleep not working. I no longer get any kernel log message about sleep being prevented though.

Btw, your proposed schema for me from yesterday also worked. But I tried 1 boot only. Let me compare all the schemas and I could change to one of the above that best matches so I can move back to no special slide from slide=80. With my current schema slide=80 is needed for consistent boot success. Also, just like @Ploddles, above 4G was problematic for me on Catalina but I didn't do much testing since I don't need it enabled.

My remark was more general - that sleep seems to be "opaque" issue, not so much comparing forums. I am not a member of any other forum btw, this is my 1st Hackintosh effort. Who is "fighting the TRX40 success"? I haven't seen anyone here. Maybe elsewhere? Thanks, @Pavo. You have quite a different set of SSDT's. You also have some power management kexts that I don't have right now - NVMeFix and AGPMInjector. Also never used -lilubetaall, not sure what it does, will look it up. @fabiosun, I moved to non-debug version, I have some older bug logs I can re-share, but I don't think anything there will shed light on sleep.

@Pavo - good to hear. So far sleep is the only thing not working on GB boards. It's unclear to me yet if this is due to the board itself. Did sleep work w/out any special SSDT's for you? Which MMIO scheme did you apply? I don't question it - and quoted him too. That makes 3. But I think this could be evidence that the sleep issue is caused by PCI hardware or USB mapping and not the board itself (or could be a board quirk but I haven't seen any clear cut thing anywhere in these Hackintosh forums that says - this is what you need to do to make sleep work)

I am not a fan of Gigabyte so far, not because of Mac OS difficulty but because of their slowness on BIOS updates and rather incompetent and not customer-friendly support. I still have an RMA pending and thinking if I should replace it. Aside from that, I don't think GB is any harder - MMIO list matches other boards in "difficulty". The only problem is sleep, but so far I have seen only 2 examples of sleep working - @fabiosun and @Driftwood and it's unclear if the problem for the rest are caused by the boards or the hardware attached. If I recall @iGPU has the shutdown problem and the sleep problem as well and haven't seen him say they are working on his MSI. The Aorus Master, Designare, MSI Creator are feature-laden boards and that may work against them as they probably have more complicated BIOS-es.

Debugging the sleep problem. I have some leads from the kernel log, it's a PCI device on my mobo, don't know which one yet.

@iGPU - something in BIOS must be the preventer for shutdown. It's worthwhile playing with those settings if you consider this issue serious enough to warrant the time spent. Wanted to look at sleep again. Looking at the kernel logs I found this suspicious entry. Any ideas if this could be the issue? 2020-08-30 23:01:05.576075-0400 0x74 Default 0x0 0 0 kernel: PMRD: System sleep prevented by kPMCPUAssertion 2020-08-30 23:36:20.248221-0400 0xab99 Default 0x0 0 0 kernel: PMRD: System sleep prevented by kPMPCIUnsupported Ok so apple open sources the xnu kernel I see references to these in the code although I don't really know how up-to-date this code is. It seems that it doesn't like neither the CPU nor one of my PCI devices sleep capabilities. Makes me wonder how anyone else's is working if CPU itself is an issue. Maybe because GB is still running old AGESA 1.0.0.3B ? Anyways, not the biggest issue but I don't think I can do anything. I am curious to know though if these messages show in your logs @fabiosun and @Driftwood. You can check by sleeping and then e.g. looking at result of terminal command log show --predicate 'processID == 0' | grep prevented Update: after I changed to latest daily build 8/30/2020 version of OC (including making the structural changes suggested by @iGPU in the config.plist) the kPMCPUAssertion error is gone and I only get the kPMPCIUnsupported one. So there is hope - I need to find out which device is the culprit. Could be a USB controller. https://opensource.apple.com/source/xnu/xnu-6153.81.5/iokit/Kernel/IOPMrootDomain.cpp.auto.html if (getPMAssertionLevel( kIOPMDriverAssertionCPUBit ) == kIOPMDriverAssertionLevelOn) { err = kPMCPUAssertion; // 5. CPU assertion break; } if (pciCantSleepValid) { if (pciCantSleepFlag) { err = kPMPCIUnsupported; // 6. PCI card does not support PM (cached) } break; } else if (sleepSupportedPEFunction && CAP_HIGHEST(kIOPMSystemCapabilityGraphics)) { IOReturn ret; OSBitAndAtomic(~kPCICantSleep, &platformSleepSupport); ret = getPlatform()->callPlatformFunction( sleepSupportedPEFunction, false, NULL, NULL, NULL, NULL); pciCantSleepValid = true; pciCantSleepFlag = false; if ((platformSleepSupport & kPCICantSleep) || ((ret != kIOReturnSuccess) && (ret != kIOReturnUnsupported))) { err = 6; // 6. PCI card does not support PM pciCantSleepFlag = true; break; } }

Thank you! Seems you don't have Wake on LAN. I need to step away now but will study these tonight. WEG is required for me. Confirmed no WEG boots to black screen for me :(.

@Driftwood, I am also interested in smbios 7,1. All my Proxmox VMs (BS and Cat) run on it great. Did you have to change MMIO between 1,1 and 7,1? On the other hand, @iGPU provides great feedback on 1,1 so maybe it's best to stick with that till I get it stable. I want to transition and stay on BS, so my bare metal is BS. I really like the experience and performance. I think it's going in the right direction (other than the Apple-built chip architecture which doesn't affect us yet).