Jump to content

iGPU

Moderators
 View Profile  See their activity

  • Posts

    573

  • Joined

  • Last visited

  • Days Won

    17

 Content Type 

Everything posted by iGPU

  1. 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.
  2. iGPU
    From the link, which beats our Single-Core: but not our Multi-Core:
  3. iGPU
    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.
  4. iGPU
    @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. iGPU
    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.]
  6. iGPU
    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.
  7. iGPU
    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.
  8. iGPU
    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.
  9. iGPU
    @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.]
  10. iGPU
    BYS4/5 are your internal I211 ports. Try using this I211 kext and see if that fixes the problem. SmallTreeIntel82576_mod.kext.zip
  11. iGPU
    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?
  12. iGPU
    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:
  13. iGPU
    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.
  14. iGPU
    @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.)
  15. iGPU
    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.)
  16. iGPU
    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.
  17. iGPU
    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):
  18. iGPU
    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).
  19. iGPU
    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.
  20. iGPU
    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.
  21. iGPU
    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.
  22. iGPU
    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).
  23. iGPU
    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".
  24. iGPU
    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:
  25. iGPU
    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.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.