Contribute
Register

Radeon VII freezing, Apple driver problem?

Status
Not open for further replies.
I don't know if it will help, but you don't need the following and I don't think Radeon VII is Kamarang...
View attachment 512520
Yes, I don't need it. It's there form when I was using WEG and not all DP ports were working, so I was trying to inject another framebuffer and Kamarand is on of 2 that have 3 DP and 1 HDMI outputs.

BTW, the injections doesn't work so it has no impact on system...
 
You have a 14 core 28 Thread CPU, don't you need VoodooTscSyn.kext or CpuTscSync.kext to enable all your processor cores/threads?

Do X99 systems no longer need to rename the CPU processor thread, i.e. CP01 -> PR00 etc. Or has OpenCore done away with the need to those APCI patches? The screenshots below show the numerous ACPI rename patches that were required under Clover:

Screenshot 2021-03-17 at 22.55.44.png
Screenshot 2021-03-17 at 22.56.01.png
Screenshot 2021-03-17 at 22.56.30.png
They continue on,
Screenshot 2021-03-17 at 22.59.40.png
But I suppose the number of patches required would be dependant on the CPU and number of cores.

I think I read the the Alpha Piker Kernel Patches have been incorporated in to the OC setup, but I can't remember which quirk you need to enable to have these patches included:

Screenshot 2021-03-17 at 23.12.37.png Kernel Patches - Find -> Replace

Screenshot 2021-03-17 at 23.12.27.png Kernel Patches - comment

FWIW, the Kamarang framebuffer is for the Vega 56/64 series of cards. I'm not sure the 'name' key would instruct OC to force the system to use the Kamarang framebuffer.

Do your system's USB ports work OK, without the need for XHCI-Unsupported.kext? By that I mean are the USB controllers discovered correctly?

You have the Audio codec injected twice, once via DeviceProperties layout-id=1, and again via the boot arguments alcid=5, which is correct?

I am not sure you need the wegtree=1 boot argument, from what I just read:
  • Added wegtree=1 boot argument (rebuild-device-tree property) to force device renaming on Apple FW
Using the -wegtree boot argument to force device renaming might be a better boot argument for your system.


The OC folder contains a lot of drivers and tools, which your system probably doesn't need or use.

The config.plist contains a lot of placeholder entries, i.e. patches that are set to false and used by the config creators to show what could be added to the various sections, these again do nothing for your system.

Nothing stands out as being wrong, not in respect of your Radeon VII, well not as far as I could see.
 
You have a 14 core 28 Thread CPU, don't you need VoodooTscSyn.kext or CpuTscSync.kext to enable all your processor cores/threads?
Sorry, few weeks ago I changed the cpu, it's i7-5820k now.
Do X99 systems no longer need to rename the CPU processor thread, i.e. CP01 -> PR00 etc
I don't know, I'm using a ssdt made with Piker script for power management so I assume it's all fine.
Or has OpenCore done away with the need to those APCI patches?
I did some patches in config.plist, others are in ssdt files and kext like usb ports.
FWIW, the Kamarang framebuffer is for the Vega 56/64 series of cards. I'm not sure the 'name' key would instruct OC to force the system to use the Kamarang framebuffer.
I think any of those framebuffers from a certain kext may be used by any card that uses that kext and radeon vii uses the same kext and it's a vega 20 card.
Do your system's USB ports work OK, without the need for XHCI-Unsupported.kext? By that I mean are the USB controllers discovered correctly?
Yes, I used USBMap method so the result was a kext that inject all my used usb ports and a ssd to reset usb hubs.
You have the Audio codec injected twice, once via DeviceProperties layout-id=1, and again via the boot arguments alcid=5, which is correct?
Boot argument method is correct and it was picked up, I'm gonna delete it and edit device properties. Thanks for that!
I am not sure you need the wegtree=1 boot argument, from what I just read:
  • Added wegtree=1 boot argument (rebuild-device-tree property) to force device renaming on Apple FW
Using the -wegtree boot argument to force device renaming might be a better boot argument for your system.
Since I'm not using WEG I'm gonna delete that argument, thanks!
The OC folder contains a lot of drivers and tools, which your system probably doesn't need or use.
I dont know about tools, but tool and drivers are there because I used Dartania guide where they guided me what I need for my motherboard. I assume I can delete tools and few drivers... But there is nothing GPU related.
The config.plist contains a lot of placeholder entries, i.e. patches that are set to false and used by the config creators to show what could be added to the various sections, these again do nothing for your system.
I know, but since they are disabled... And I also have to say that I installed OC only a week ago, so ahven't managed yet to understand all entries.

Thank you for your inputs!
 
IOReg:
Post a copy of your IOReg, so we can see what is happening in your system. Follow this guide for making a copy of your IOReg, use the app linked in the guide - https://www.tonymacx86.com/threads/guide-how-to-make-a-copy-of-ioreg.58368/

CPU:
CPU is now a 6 Core/12 Thread processor, so it may not need the rename patches that were used with the other CPU's with more core/threads. SSDT-PLUG.aml should work just fine with this CPU, even the generic 'catch-all' Dortania SSDT.

USB Config:
Not sure the USB Configuration works like that. I think you should have used the XHCI-Unsupported.kext while creating the USBMap.kext and carried on using it after the kext was installed. Same with the USB rename patches. I may be wrong, but that is what I would expect you to need to do to maintain the USB setup, as mapped.

Radeon VII:
I'm not sure you are correct with the usage of the Kamarang framebuffer. That framebuffer is for a Vega 10 card, the Radeon VII is a Vega 20, so I am sure it would require/use a different framebuffer.

Remind me again why you don't use WhateverGreen.kext with your Radeon VII. This is what the GPU Buyers-Guide says about the Vega 20 Series Radeon VII.

Screenshot 2021-03-19 at 16.48.45.png

Tools:
The /OC/Tools folder contains a number of tools that can be used from the OpenCore boot screen, GUI or Picker list, such as ClearNvram, as shown below:

Screenshot 2021-03-19 at 16.35.12.png

Starting contents for OC 0.6.7 /OC/Tools folder. Most if not all of these tools are not used or required after the initial boot from the macOS drive and can be deleted or disabled in the config.plist.

This is what my main iMac1 system's /OC/Tools folder contains.
Screenshot 2021-03-19 at 16.37.41.png

The three tools in the /OC/Tools folder, plus the AllowNvramReset quirk are all disabled in my config.plist, as shown below (ProperTree Plist Editor screenshot):
Screenshot 2021-03-19 at 16.39.44.png
Kernel > Security > AllowNvramReset - False
Kernel > Tools - Three entries have 'Enabled' set as False, so they don't show on the Picker List or OC GUI.

This Tools section is not going to help with the Radeon VII issue unfortunately, but would tidy up your OC boot screen and config.plist.
 
Thank you for such a detailed reply!
Done, please take a look!
SSDT-plug is just injecting Plugin type and it's already in my ssdt for the cpu that I made with Piker script. Whith Clover I was using the PMdrv kext so I dont think my OS lagging is related to CPU.
USB Config
I did all steps as by Dortania guide, and confirm all ports are recognized now.
Radeon VII:
I'm not sure you are correct with the usage of the Kamarang framebuffer. That framebuffer is for a Vega 10 card, the Radeon VII is a Vega 20, so I am sure it would require/use a different framebuffer.
It doesn't matter since all those cards use the same kext, you are free to use any framebuffer you want/is suitable for your setup.
Remind me again why you don't use WhateverGreen.kext with your Radeon VII. This is what the GPU Buyers-Guide says about the Vega 20 Series Radeon VII.
Believe me, I followed the guide step by step and I tried WEG also and can report 2 things:
-with WEG I have same lags and freezes;
-with WEG my Dell MST monitor is not recognized correctly as a 60p one. It's 30p only or as 2 separate 60p monitors but the image is black on both halves...
So I just removed it since Vega cards are natively supported.
In guide they said: it's recommended to still have WhateverGreen.kext installed as this helps with proper framebuffer connections and fixes other odd issues like proper ACPI mapping and such.
I have no problem with framebuffer connections without WEG since all my 3 DP ports are working fine and the card is recognizing correctly the Dell monitor as 4k 60p. As i said above, with WEG I have problem to use the Dell monitor AND only 2 DP ports work, so in my conclusion the WEG is not yet ok with Radeon VII card.
In regards of proper ACPI mapping yes, with WEG under ioreg I can see GFX0, without it's just display0 but it works fine.
I can delete all files if you think one of them can create problems but again, under Clover those tools don't exist and I had same freezes...
AllowNvramReset quirk are all disabled in my config.plist
I followed that part of the guide for my haswell-e mobo:

As you can see it's enabled...

In the end I think it mat be the defective mobo...
Thank you again for trying to help me! :thumbup:
 

Attachments

  • Riko’s Mac Pro.ioreg.zip
    1.1 MB · Views: 37
Your Radeon VII is reported as a Vega 10 series card in your IOReg, obviously this is not correct as the Radeon VII is a Vega 20 series card. This (possibly cosmetic issue) is probably due to your use of the Vega 10 framebuffer.

Your IOReg shows you only had one display connected to port 2, when you made the copy of the IOReg.
Screenshot 2021-03-19 at 19.39.39.png AMD connectors highlighted in Red were not in use.

It also shows that it is using the 'ATY,AMD,RadeonFramebuffer', not the Kamarang framebuffer.

Screenshot 2021-03-19 at 19.42.38.png Framebuffer name highlighted.

I take from the information provided in an earlier post that a single screen is not your normal setup.

As you are not using WhateverGreen.kext you may want to look at adding the following ACPI patch to your /OC/config.plist:

Change PEGP to GFX0

This being the main display related rename patch you are missing, as WEG usually takes care of the IGPU and DGPU renaming.

There are other rename patches you are missing, as listed in the screenshots attached to post #22, none of these are present in your config. Some of these may be cosmetic, but some I think are central to how the X99 system works with macOS.
 
I think Edhawk nailed it. The ACPI tree shows neither PEGP nor GFX0.

I never looked in to any HEDT hackintoshes... I didn't know it was so different from the consumer level stuff.
 
Your Radeon VII is reported as a Vega 10 series card in your IOReg, obviously this is not correct as the Radeon VII is a Vega 20 series card
Do you have a Radeon VII? How it's reported under ioreg?
This (possibly cosmetic issue) is probably due to your use of the Vega 10 framebuffer.
I'm sure it's just cosmetic issue. With WEG it was exactly the same: same Vega 10 and same framebuffer!
Your IOReg shows you only had one display connected to port 2, when you made the copy of the IOReg.
Yes, the second one was off. Do you need a ioreg with both?
It also shows that it is using the 'ATY,AMD,RadeonFramebuffer', not the Kamarang framebuffer.
Yes, as I said I'm unable to inject different framebuffer, maybe I'm doing it wrong or maybe OC doesn't work like that...
Even with WEG I have ATY,AMD,RadeonFramebuffer
Change PEGP to GFX0
I'll try it and report.
There are other rename patches you are missing, as listed in the screenshots attached to post #22, none of these are present in your config. Some of these may be cosmetic, but some I think are central to how the X99 system works with macOS.
I'll check it again.

Thank you!
 
I never looked in to any HEDT hackintoshes... I didn't know it was so different from the consumer level stuff.
I just followed the guide...
 
I think the OC guide for your motherboard/CPU is fairly limited in what it covers. I have gone through it a few times and believe that t follows the same setup as for a standard desktop system, to just get the system booting macOS with OC. They have aimed to make the setup as uncomplicated as possible, which they have done.

However, the guide contains none of the 'additional' settings that are used to make these High End Desktop (HEDT) systems run as well as they can under macOS. By that I mean it fails to take in to account a lot of the differences that your system contains when compared to a desktop system.

There are some extremely detailed guides for X99 and X299 systems on this site, which you have probably seen and followed, when you set up you X99 system using Clover. All of these guides go to much greater levels of detail to get these HEDT systems working as best they can, not just booting macOS.

So to my mind, saying you 'followed the OC guide' doesn't mean a lot, other than your system should boot macOS with OC.

No you don't need to provide a second IOReg, the first even without the other display(s), shows sufficient information to see that your setup is not as good as you would get if you were following one of the older Clover guides.

What you probably need to do is use and amend your current OC setup alongside the detailed fixes, tweaks and if possible compatible Clover settings for your system. That would probably help fix your Radeon VII issues.

If the rest of the system is setup to run below par (not optimised), why would your discrete GPU (your only GPU) be expected to work at its maximum and without issues?
 
Status
Not open for further replies.
Back
Top