Pavo Posted August 31, 2020 Share Posted August 31, 2020 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. Link to comment Share on other sites More sharing options...
Driftwood Posted August 31, 2020 Share Posted August 31, 2020 (edited) 1 hour ago, Pavo said: 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. Not using your addresses. I am using my MMIO, just switching off last 3 So after testing out Big Sur (with Pavo's EFI + MY Addresses, last 4 is better than last 3. Last three set to NO turns off keyboard and mouse and can't bring it back to life. Shutdown clicks and reboots. So this is my HAPPY MMIO w'list so far: Edited September 1, 2020 by Driftwood Link to comment Share on other sites More sharing options...
Pavo Posted August 31, 2020 Share Posted August 31, 2020 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. Link to comment Share on other sites More sharing options...
Pavo Posted September 1, 2020 Share Posted September 1, 2020 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. Link to comment Share on other sites More sharing options...
Supervisor fabiosun Posted September 1, 2020 Author Supervisor Share Posted September 1, 2020 I think now you have understood what I am saying from a bit also for the sake of testing all of this should be apply also on different OSX to be proved solid rock combinations 😊 Link to comment Share on other sites More sharing options...
Driftwood Posted September 1, 2020 Share Posted September 1, 2020 (edited) 25 minutes ago, fabiosun said: I think now you have understood what I am saying from a bit also for the sake of testing I'm just trying out Big Sur with our Catalina MMIO. Things don't work so good and I even tried without SSDTs (ie DISABLED) on this BS test drive. There seems to be a lot more to do to find the ideal combination. Just gonna try out the complete Catalina EFI on BS to just put something to bed...RESULT: Ok, my working well Catalina EFI wont boot Big SurBM. Testing goes on... Edited September 1, 2020 by Driftwood Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 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 Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 7 hours ago, fabiosun said: Test: 1) what does devirtualizemmio quirk does? 2) which means to on or to off it? 3) skip 0 what does it mean in the debug? 4) skip1 what does it mean in the debug? 5) a system that does not need of that quirks use or not those mmio area/pages? starting from here imho should be a common task😊 @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. 2 Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 Off-topic. Now that this is out, I need to buy it 🙂 https://www.sabrent.com/rocket-4-plus/ 1 2 Link to comment Share on other sites More sharing options...
Supervisor fabiosun Posted September 1, 2020 Author Supervisor Share Posted September 1, 2020 @meina222 idk if they are excellent questions or not but it should be the questions all users should do to theirself before starting to play with those areas about your point 5) no all AMD platform need of devirtualizemmio stuff and often if you use in a system that does not neet it, system hangs Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 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. 1 Link to comment Share on other sites More sharing options...
Supervisor fabiosun Posted September 1, 2020 Author Supervisor Share Posted September 1, 2020 @meina222i like your programmer way to explain and to try to solve problem also @iGPU way is similar and i think you have given a bit to improve this thread thank you now a simple way to explain and sorry to all if sometimes i seems to be rude..it is only my english... more 1 we have in our debug better is because all that area are in OSX avaibility when an ‘area’ is on 0 in debug and OSX try to write there or use it for its tasks..system hangs about @Driftwood problem i have always said i am testing high sierra, mojave, catalina and for this when you reach your gold situation no problem at all gold situation means nvram ok sip ok bios ok config ok if one of this fails problem happens and to solve you have to be more drastic And you have to reset sip, in recovery and in config..to achieve and optimal condition this is our big and common problem. 1 Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 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). Link to comment Share on other sites More sharing options...
Supervisor fabiosun Posted September 1, 2020 Author Supervisor Share Posted September 1, 2020 That quirk is a sort of nullcpupowermanagement.kext used in the past for cpu not supported by osx today i will verify our kernel patches because i think some differences is there Link to comment Share on other sites More sharing options...
Moderators iGPU Posted September 1, 2020 Moderators Share Posted September 1, 2020 19 minutes ago, fabiosun said: @meina222i like your programmer way to explain and to try to solve problem also @iGPU way is similar and i think you have given a bit to improve this thread thank you now a simple way to explain and sorry to all if sometimes i seems to be rude..it is only my english... more 1 we have in our debug better is because all that area are in OSX avaibility when an ‘area’ is on 0 in debug and OSX try to write there or use it for its tasks..system hangs about @Driftwood problem i have always said i am testing high sierra, mojave, catalina and for this when you reach your gold situation no problem at all gold situation means nvram ok sip ok bios ok config ok if one of this fails problem happens and to solve you have to be more drastic And you have to reset sip, in recovery and in config..to achieve and optimal condition this is our big and common problem. fabiosun, I was reading on some thread (forget which one, prob InsanelyMac) that to get proper SIP, one needs to first have native NVRAM working (which we do), then delete the csr-active-config entry in OC. Only then will the SIP set in Recovery maintain over a boot. Otherwise, the values set in csr-active-config will over-write Recovery SIP. I've not tried this. Link to comment Share on other sites More sharing options...
Supervisor fabiosun Posted September 1, 2020 Author Supervisor Share Posted September 1, 2020 @iGPU yes it works i use 00000000 then enter in recovery and clear sip and nvram from there this could be need of additional quirk like avoidruntime defrag if you do not use it but all this is the weaker part in our effort to have a perfect or almost perfect system and all of you are more lucky than me because you do not use a Nvidia gpu Link to comment Share on other sites More sharing options...
Pavo Posted September 1, 2020 Share Posted September 1, 2020 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. Link to comment Share on other sites More sharing options...
Moderators iGPU Posted September 1, 2020 Moderators Share Posted September 1, 2020 57 minutes ago, Pavo said: 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. Pavo, agreed. At least with the MSI mobo, there is no difference in HPET with or without DummyPowerManagement. Either setting gives this result: On a peripheral note, if the highlighted contents of the Spoiler is added to NVRAM, SBRG is populated as shown below, otherwise nothing is attached to SBRG. This was used on the X570 build (modified NVRAM SSDT is attached). Spoiler SSDT-TRX40-NVRAM.aml.zip Link to comment Share on other sites More sharing options...
Pavo Posted September 1, 2020 Share Posted September 1, 2020 (edited) 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. Edited September 1, 2020 by Pavo Link to comment Share on other sites More sharing options...
Driftwood Posted September 1, 2020 Share Posted September 1, 2020 Ill switch mine off to see if any difference. Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 @Pavo - Here it is. Thank you! System DSDT.zip Link to comment Share on other sites More sharing options...
Pavo Posted September 1, 2020 Share Posted September 1, 2020 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. Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 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 Link to comment Share on other sites More sharing options...
Pavo Posted September 1, 2020 Share Posted September 1, 2020 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 } }) } Link to comment Share on other sites More sharing options...
meina222 Posted September 1, 2020 Share Posted September 1, 2020 (edited) 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. Edited September 1, 2020 by meina222 Link to comment Share on other sites More sharing options...
Recommended Posts
Posted by fabiosun,
MMIO rules shutdown and reboot previous problems
Recommended by fabiosun
2 reactions
Go to this post
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now