iGPU

I downloaded Luminar AI from App Store but it would crash on startup. (There is a 7 day free trial.)

A search found the answer to get it working (here); it is an AMD issue. Basically enter each of the following 5 commands into Terminal as shown in Spoiler below. After these are run, Luminar AI works fine under AMD.

sudo perl -i -pe 's|\x90\x90\x90\x90\x56\xE8\x6A\x00|\x90\x90\x90\x90\x56\xE8\x3A\x00|sg' '/Applications/Luminar AI.app/Contents/Frameworks/MPCore.framework/Versions/A/Frameworks/libtbb.dylib'

sudo perl -i -pe 's|\x90\x90\x90\x90\x56\xE8\x4A\x00|\x90\x90\x90\x90\x56\xE8\x1A\x00|sg' '/Applications/Luminar AI.app/Contents/Frameworks/MPCore.framework/Versions/A/Frameworks/libtbb.dylib'

sudo perl -i -pe 's|\x90\x90\x90\x90\x56\xE8\x6A\x00|\x90\x90\x90\x90\x56\xE8\x3A\x00|sg' '/Applications/Luminar AI.app/Contents/Frameworks/MPCore.framework/Versions/A/Frameworks/libtbbmalloc.dylib'

sudo perl -i -pe 's|\x90\x90\x90\x90\x56\xE8\x4A\x00|\x90\x90\x90\x90\x56\xE8\x1A\x00|sg' '/Applications/Luminar AI.app/Contents/Frameworks/MPCore.framework/Versions/A/Frameworks/libtbbmalloc.dylib'

sudo codesign --remove-signature /Applications/Luminar\ AI.app/

On 10/19/2021 at 12:49 AM, antuneddu said:

It would seem so 😀

 

https://mrmacintosh.com/macos-monterey-12-0-1-rc-21a558-is-live-whats-new/ 

From the link, which beats our Single-Core:

but not our Multi-Core:

12 hours ago, fabiosun said:

@23d1we talk about it extensively also in this thread

a common solution is to use latest OC with securebootmodel set to Default

for many of us works in this way

Besides setting to Default, I also had to disable RadeonSensor and enable RestrictEvents (I did both at same time, so maybe only one or the other was necessary); otherwise I got a KP during install at the 2nd re-boot (display froze immediately after RadeonSensor was loaded and the 1st bank of RAM was loaded). 

After doing above, the install resumed without any problems.

@Driftwood

Creating DSDT files (and worse, maintaining them: a new one is required for BIOS updates), is difficult at best. I went over this over a year ago on this thread and modified a few. I stopped using them soon after.

I would not recommend them (and I seem to recall that OC developers were not too keen on using DSDT files either).

5 hours ago, Driftwood said:

You see no differences moving around your NVMEs  clashing with say Thunderbolt Card (or the firewire you tried once some time ago?). Also, what SATA ports are your drives coming off? SATA Controller 1 , data controller 2 or both mixed? ie you see absolutely no clashing of IRQ resources anywhere?

No clashes.

SATA/PCIe clashes are only on Intel.

AMD has issues on X570 with PCIe and .M2 slots. I've not seen this on the TRX40 as there are not so many PCIe slots.

***

 I tried booting tonight with both OC ResizeBar variables set to -1 but had KP as shown in Spoiler. I had to change both values back to 8 or 10 to boot.

[BTW: please use Spoilers for routine (i.e., non-attractive) screen shots to keep post lengths short. Otherwise we have to scroll through pages of images to read a post. Thanks.]

4 hours ago, Driftwood said:

@iGPU In terms of M2 and SATAs, plus other PCIe cards inc GPUs, BT/Wifi what is your current I/o PCIe population? Also, are you booting off USB Stick every time, is your boot for Big Sur and / or Monterey on M2 or SATA SSD? Plus, can you video your BIOS settings. Im intrigued as to how you have all those Power Options in Energy Saver too (I may have switched off a few trying out variables for Sleep) so I may need to reset.

 

Its a lot to ask but I need to strike off a few things in my mind. Thanks. 

PCIe: GPU in slot 1 (which covers slot 2), BT/Wifi card in Slot 3 and TB card in slot 4.

All three .M2 slots on my MSI Creator mobo are populated with MVMe drives: one for Windows and 2 for macOS (M/BS). I boot off either of these two internal macOS EFI partitions on NVMe drives. There are also 3 SATA drives which are used for storage (these too have EFI partitions which have bootable OC EFI folders). I keep one of the SATA drives's EFI with MmioWhitelist for Above 4G enabled and another with for when Above 4G is disabled, using an older, stable versions of OC. These are for 'backdoor' booting should either of the EFIs on the main NVMe drives get corrupted or I change a BIOS setting.

Should something really get wonky, I have USB devices containing other NVMe drives that have their EFI partitions loaded with macOS EFIs with other boot options. I can edit these from a Mac laptop to further ensure a proper boot.

Also, all of my macOS drives contain a folder with many versions of OC EFI folders for Intel (Z390 various mobos, X299) and AMD (X570 and TRX40): backups of backups.

***

@fabiosun 

I changed both of my settings to "8" and re-ran the GB5 tests. Both OpenCL and Metal results were reduced by about 5%... I'll re-test another time disabling both Quirks. The results all seem a bit odd to me.

10 hours ago, fabiosun said:

Enabling resize bar on bios and in config with a value of 10 could cause a sleep/wake problem during wake stage (black screen or reboot)

A solution was proposed on Hackintosh-forum.de from hackmac004

setting quirk value to 8 solves wake problem

 

I have both ResizeBar values in OC set to 10, and had no problems with sleep/wake in Monterey and I left computer running over night.

Since I had to do a reformat and fresh install of Monterey (thanks MS!), initially sleep/wake was not working. (BTW, I did finally get Win 11 to install but it took many hours of fiddling with regedit, and other things like DISM, inside Win 10 to get the update to 11 to properly install.)

But after the re-install, I had to re-set Energy settings as shown in Spoiler below in order to get the sleep/wake cycle working once more. I did not change these settings for OC's ResizeBar when I left running over night.

As for testing, I only did some limited tests last night. I saw about a 20% improvement for GB5 with OpenCL but a 20% decrease with Metal. Strange.

GB5 Tests:

For GB4, both OpenCL (385723) and Metal (374494) were better. LuxMark values were unchanged when using ResizeBar. I've not yet test DaVinci.

This post is a heads up for what's coming in OC v075 (I test the daily mods).

The post is not a tutorial, I've not yet tested the functionality under our TRX40 system. (I'll work on later tonight.) What the latest commit adds is support for Resizable BAR technology. Apparently, macOS does support this feature up to 1 GB (which is the value of "10" for the entries as shown below). The value of "-1" is the default value, turning this feature off.

There are 2 Quirks for this feature. What is not yet clear to me is if both are used simultaneously, or, only one or the other.

I should also add that when Resizable Bar is enabled in BIOS, my mobo also turns on Above 4G. If you continue with these both enabled, you will also have to re-do your MmioWhite list; otherwise you will not be able to boot into macOS on our TRX40 mobos.

As for documentation, in the Spoiler below are excerpts from the latest Docs:

As I've posted on this thread several times, head over here for the latest commits.

But a parting editorial. I've previously given instructions on how to use "ocvalidate" in the Utilities folder to correct your config.plist file to eliminate errors. (ocvalidate shows you the items needing removal and those needing to be added; and comes with a README file if you don't wish to search for my earlier posts.) Everyone who is running a Hackintosh should know how to check their own config files with this tool and not depend on others to fix their files due to being too lazy to use this tool.

5 hours ago, fabiosun said:

@iGPUand @all 6900xt owners..

take a look to this thread (hackintosh-forum.de)

I have lowered my max GPU temps of about 10 degrees only loosing a bit of performances in my task (thanks to Aluveitie and his SoftPowerPlay for device properties)

 

PowerPlayTable thread

 

 

@fabiosun 

I did similar DevProp for Vega56, Vega64 and Radeon VIIs.

I don't see the actual PPTable data; where are did you get it (or can you post the code in a spoiler on this thread)? Thanks.

[I don't have Windows working; I tried installing Win 11 today and despite carefully only installing on drive 0, Win 11 decided during the install formatted drive 0 and drive 1 (my Monterey drive), and then to make matters worse, failed to install. I'm so annoyed with MS... So the rest of my free time today, I'm re-installing Monterey on drive 1 and copying things from drive 2, which thankfully Win 11 did not also re-format.]

7 hours ago, fabiosun said:

thank you IGPU

I am using only this:

2-SSDT-SBRG-USBX-v4.aml.zip 462 B · 1 download

and SSDT plug

BYS4/5 are your internal I211 ports. Try using this I211 kext and see if that fixes the problem. 

SmallTreeIntel82576_mod.kext.zip

25 minutes ago, fabiosun said:

Every now and then, since Monterey beta 6, this happens on my system with a percentage of 1 boot not working with 10 working

it would appear to be tied to the network card after the attached color screen, which appears in my monitor connected in hdmi

both monitors go to black screen with signal

I can't say it with extreme certainty but before beta 6 it didn't happen and the same didn't happen with Big Sur

Maybe it will be a SIP problem?

 

mmmmm

BYS4 should be intel Ethernet I think..and it is not connected (also no kext installed for it)

BYS4 is the location of my internal AX200 card, which can appear as an ethernet access. (I use a section of a USB port SSDT file to cancel this card.) 

But I thought your mobo has no Wifi card.

Are you using an SSDT, DevProp, or kext file (with its Info.plist file containing a definition) with BYS4?

3 hours ago, gosi said:

So the Titan Ridge Card v.2.0 finally arrived. I popped it in an in the PCI section of hardware I can already find it. Thunderbolt is empty.

 

I suppose it will not work without flashing the chips?

 

Also one question about iMessage: it worked for a few days now but now I cannot login anymore. Is this a known problem?

Correct, you need to flash _a_ chip.

iMessage requires proper log in to iCloud with your Apple ID. Sometimes signing in and out of App Store or Music app helps. Also, you need to have (one) internet connection assigned "en0".

How to re-set to "en0" has been discussed before, but in case you've forgotten:

On 9/30/2021 at 2:32 AM, gosi said:

 

Thanks! Update went smooth and system is stable!

 

The Rev2 TitanRidge card should arrive next week, I hope you can help me get it running 🙂

If you don't know how to create an SSDT for the TB card, after it arrives, install it and run without a TB SSDT. Next, post the IORE file under this condition. Based on the IORE file, I can possibly help you to create an SSDT file.

@Driftwood

Sorry I didn't get back to you earlier, but I've been busy all week. Happily, you all solved the Memory issue on your own!

(And I do use the same settings; no change from original post.)

I updated the earlier post (here) that provides a cursory comparison of USB device naming by SSDT and a kext file.

(I use Spoilers to keep the graphics and posts shorter; easier to scroll through.)

1 hour ago, Driftwood said:

BIOS Im using is 1.70 CSM disabled and Above 4G on. Plus, that .bin I sent you all in earlier thread.

 

Incidentally, Asrock Creator TRX40 users: here's the PCIEe layout. Note, Ive been told there is no sharing of PCIe M2 with SATA they are all independent.

 

Correct: PCIs are shared with SATA on Intel.

AMD, on the other hand, shares with .M2 slots with CPU lanes and PCI slots. This is true on X570 and TRX40 (it was maddening to sort this out soon after the X570s came out as AMD gave us no hints about this problem). This sharing is why adding more .M2 NMVe SSDs foul up PCI slots and vice-versa on AMD. I've previously discussed these issues on this thread, but the thread has become so large that they are as if from a bygone era. 

6 hours ago, fabiosun said:

@Rox67ert maybe could be useful to rule and declare USB's type and kind (never did this but maybe it could be helpful if osx reads bad kind and type)

 

Yes, the type and kind of ports are defined by either an SSDT or a kext file, and this can be very useful.

While I've used both, in my view, SSDT files are easier to edit and maintain (kext files require going into their contents and editing a relatively hidden parts within an info.plist file inside the kext's contents); furthermore, the SSDT file allows renaming at the same time.

The first Spoiler below shows an SSDT excerpt and annotates how a re-name and USB types can be assigned.

The 2nd Spoiler describes the steps used to locate and edit the Info.plist file for USB devices. This is only a cursory overview. Even if you have a program to create the list for you, you'll still need to know how to remove unwanted devices or re-add those previously removed.

SSDT:

Kext Format (much more confusing, no?; and you still cannot re-name a device as with the SSDT approach):

4 hours ago, Rox67er said:

@Rocket88 could you share your full EFI? I have been testing with your dsl file and also the port mapping tool but my ASRock behavior stays the same. Immediate wake after sleep. 😳🤯

Port mapping is important when any given USB device has more than 15 ports. This seems to be an Intel, not an AMD, problem. I've made such comments scattered throughout this thread, and now Driftwood, in his above post, is echoing the same position. On the AMD platform, each USB device typically contains only 10 USB ports, not more than 15 (which would require port limiting/mapping).

Where USB port limiting can help, is when certain ports are interfering with another function. The example I referenced in the recent response to Driftwood, was about limiting the USB power to the internal AX200 Wifi device. The interference arose between a natively functioning PCI AIC for BT/Wifi and the internal AX200. Cancelling the AX200 requires one USB device be "un-defined" via an SSDT file to make it disappear.

I think that the PCI AIC BT/Wifi card is superior to the internal AX200 because it allows AirDrop to fully function. I have no sleep/wake issues. BTW, this PCI AIC BT/Wifi card requires no kext files under Monterey such as BlueToolFixup. The AX200 device requires special kext files, which to date, don't permit AirDrop to work.

***

On a related note about kext files, I can vouch for @fabiosun's 2 kext booting. It works!

However, our set-up differ: he chooses to not use the internal I211 ports but instead use an Aquantia AIC; meanwhile, I use the internal I211 port, so I need the SmallTree kext (and my mobo has an internal Aquantia port). Nor does his system use BT/Wifi as mine, so I need some extra SSDT files which he does not need. 

Again, as of Monterey ß2, the Fenvi-1200M PCI card requires no kext files, which reduces my previously required kext number by 4 files (as when this same AIC is used in Big Sur).

I211 is now working with the old SmallTree kext file on Monterey ß7.  (The same file works with Catalina-BigSur-Monterey.)

The entire time is was a macOS problem, not a SmallTree kext problem. And most likely, the I210 ports will be working again too.

While I got the update to show up using j160; I cannot get past the "Macintosh HD" first reboot stage. Even using iMac17,1 does not help. (Driftwood, above you referenced "iMacPro17,1" and the other forums are using "iMac17,1".)

Since I'm now at work, later tonight I'll try changing other settings in SMBIOS associated with iMac17,1.

2 hours ago, Driftwood said:

SUCCESS!

SHUTDOWN / SLEEP with BIOS Control (All take note)  
*** NO ssdts Required ****
PLUS, MY USB MAP for ASrock TRX40 Creator Users

Plus, my EFI with the map inside

 

(Tested under Big Sur 11.5.2 and OC 0.71 built with Pavo's GenX)

 

So here's my EFI for Asrock TRX40 Creator motherboard users. This EFI shutsdown correctly (see BIOS settings) and has Sleep Power management. Other motherboard users should check their BIOS for matching settings.

 

Driftwood EFI:Driftwood EFI Big Sur.zip

 

My EFI has my own USBMap_D.kext requiring USBToolBox.kext. I DON'T like to use SSDTs as I dont require anything.

Getting Shutdown to work was fun. After I thought long and hard about it, it HAD to be something to do with BIOS and/or maybe turning off Bluetooth. But then it was the Power management sections which took closer scrutiny...

So see my screens below to check you have those settings enabled/disabled and matched to mine. Having turned the Bluetooth/on and off I dont think it was that. But Turn Onboard LED to S5 to =Disabled, and, USB Power Delivery in Soft Off State (S5) to =Enabled could be the reason why Shutdown works.

 

You absolutely DON'T NEED FixShutdown-USB-SSDT.dsl OR _PTS to ZPTS Patch or any Clover style fix.

 

FOR ASROCK CREATOR USERS ONLY:

I've attached a BIOS .BIN file if any Asrock TRX40 Creator (with latest BIOS already installed) can load in as a profile (just copy it to a external USB disk and on BIOS Setup on the Memory Screen choose the Add the Profile from Disk and install my BIOS settings!

 

My BIOS Profile: driftwood_BIOS.BIN.zip

 

Here's the BIOS screens needed to get Shutdown working:-

 

 

 

A video will be placed here soon proving shutdown and sleep.

 

This is good news for you. Congrats!

I looked over your files. I would add that many of us have used either USBPorts.kext or SSDT files to enable or disable USB ports; but you never want to use both together. If done correctly, they are equivalent. (I think the PTS to ZPTS patches were for Intel mobos.)

I believe that fabiosun and I have had sleep, shutdown and restart working for some time now. As you've observed, correctly functioning USB ports and BIOS settings are important, as is a correct MmioWhitelist structure.

Sometimes the BT problems are also related to a USB port since BT (not Wifi) is powered by USB. I discussed some of those BT-USB issues here and here (the latter, at bottom of post, where I describe how to remove a device from IORE using an SSDT; I'm don't think this is easily done using a kext file). Not related to your post, but since using Monterey > ß1, I've disabled all BT/Wifi kext files (including BlueToolFixup.kext); I'm using the Fenvi-1200M PCI card with the internal AX-200 inactivated as discussed in the above links.

FYI for new updates coming with OC v073. The latest commits change the structure of OC's driver section as shown below.

The OC documentation discusses the changes as seen in the comments inside the ChangeLog file. The changes also include a new driver (OpenLinuxBoot; only needed if booting from OC into Linux):

The changes to the config file are shown next.

These changes sub-divide the string driver list into an array with 3 parts each. One part is to allow arguments for each driver, the 2nd part is to enable or disable the driver (instead of using a "#" symbol to disable), and the 3rd part is for the driver name (with path if not in the expected Drivers folder).

On 8/31/2021 at 4:22 AM, fabiosun said:

To update to Beta 6 (if you do not see it in update)

If you have MacPro7.1 Smbios, and default or Disabled in Misc/security/SecureBootModel

put in Misc/security/SecureBootModel j160 value

reboot

You will find an update message on software update

download it..DO NOT REBOOT

before reboot change secureBootModel in Disabled

then reboot

And it should then update as usual

 

 

Completely agree with your findings: when SecureBootModel set to "Disabled" (the usual setting in my config file), the Mß6 update was not offered. Once this setting was changed to "j160" for my SMBIOS (MacPro7,1), and the computer was re-booted, the Mß6 Update became visible. (SecureBootModel was then re-set to "Disabled" before running the Update so that re-boots during the update would be run under "Disabled" and not "j160".)

The curious thing is that previous Updates in Big Sur and Monterey were not visible unless SecureBootModel was set to "Disabled" (and csr-active-config set to "00000000"; this setting was unchanged for the Mß6 update). In fact, early on when the SecureBootModel quirk was introduced, I had trouble even booting into macOS if SecureBootModel was anything but "Disabled".

On 8/28/2021 at 8:42 AM, fabiosun said:

@valmeidaweird

it differs in subvendor and sub device id

but it is weird it works in Big Sur and it doesn't in Monterey

By the way you have DDR4 @3200 in signature but Hack check detect them @3000

 

The sub-vendor and sub-device IDs are based on the mobo's manufacturer. Therefore, our MSI values will be different from those of ASUS. But no matter, as these ID values will not affect the Kernel patches since they are directly applied to Apple's Aquantia kext file without reference to any ID values.

And even with the patches applied, I've added cosmetic changes (that is, not essential) via SSDT or DevProp changes, and the Kernel patches still work in Big Sur and Monterey. (I've already cautioned @valmeida to use no DevProp during the test phase.) If an SSDT is used, the attachment point at device BYS3 could be changed but that should not be important at this point.

When I look at @valmeida's IORE, which I believe is from a Big Sur boot, we see the following at BYS3. This looks good. And after a boot into Monterey, it should look exactly the same. Please verify.

It is not clear to me why @valmeida's Aquantia patch is working on the ASUS mobo in Big Sur, but not working in Monterey. The fact that the port is seen in HackCheck would suggest that the patch is being injected.

However, to verify this change, turn off the Aquantia Kernel patch for Monterey in the OC config file. After re-booting, the Aquantia port should not longer be visible in HackCheck.

To summarize, @valmeida do two things I've written above. Both will be answered in 2 boots (one with the Monterey Aquantia port enabled and one boot with this same patch disabled):

1. look at the BYS3 section in IORE after a Monterey boot with and without the Monterey Aquantia patch being enabled.

2. look at HackCheck's Network section, again after a Monterey boot with and without the Monterey Aquantia patch being enabled.

*****

SPOILER: What I see on my MSI Creator mobo for Aquantia and I211 ports in IORE and HackCheck. While SmallTree is being properly injected, the port is still not active even under Mß6:

7 hours ago, fabiosun said:

@valmeidaSmallTreeIntel8259x.kext  is not valid for Monterey

Patches for aquantia you have in config.plist are fine both for Big Sur and Monterey

If you have a failure on aquantia connection, a reason could be a previous boot on windows OS

if you put OFF pc and start in OSX it should work

Obviously, your ethernet cable must be connected to Aquantia backplate connector

 

Agree with what fabiosun says. Additionally, I'd add that there were reports by KPG (now retired) on his threads that updating the Aquantia driver from Windows will cancel Aquantia from working in macOS. Therefore, seeing no good outcome in testing this belief, I've never updated any Aquantia drivers and the port works just fine in macOS, Linux and Windows.