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 looked at your mobo specs. You have one I211 port. We've discussed this at length on this thread: it does not work on Monterey. So for the time being: ignore this port. However, your other port is an Aquantia and should work. I already gave you the patches for both Big Sur and Monterey. Please re-read what we've previously written for using Aquantia: the patches are different for Big Sur and Monterey and were recently posted on this thread.
  2. iGPU
    I'm unaware of any Pro Hackintoshes. Here is a good overview of the feature set between Threadripper, Threadripper Pro and EPYC. The price point for the Pro 3975X is not too much more than the 3970X most of us are using, at $2790 (there is a typo in the 32-Core table where they say the 3970X costs $3990; the MSRP is $1999). However, the price point for the Pro 3995WX over the 3990X is significantly more: $5490 vs $3990. This price difference doesn't reflect the need for a new mobo since the socket is different for the new Pro models (so there's no swapping of the CPUs for a quick test). And then there's the ECC memory (in the referenced review, read the Comments section, users have found that the number of used DIMM slots affect performance and explain why). In terms of performance, both use Zen 2 and little advantage was found except in memory performance. My guess is that except for the 3995WX (which uses 4 chiplets), the other Pro versions will have little improvement over our current CPUs in a Hackintosh. The next generation of Threadripper using Zen 3 will probably be a different story; they're supposedly due to arrive later this year.
  3. iGPU
    My reading of the above referenced thread is the same as fabiosun's understanding: they were not patching the kext from OC, but instead are 'patching' (editing) the info.plist and then injecting this kext (info.plist) from OC. There is something different about how Monterey, compared to all previous macOS releases, handles ethernet ports. Once this difference is sorted out, I'm sure all again be functional. (BTW, editing this kext to add 0x15398086 did not work for the I211 port...)
  4. iGPU
    The SSDT-6900XT is only useful if not using WEG. For months, I have used BS and now Monterey using only WEG and no SSDT file (for RX580, Vega56, Radeon VII and now 6900XT). Such SSDT files are not necessary for a boot if using WEG. And even if not using WEG, while the SSDT is helpful in re-naming the GPU devices as seen in IORE, the computer will still boot without it. I done this many time on both Intel and AMD platforms. If one wants to inject certain properties (like control the fan and GPU speed), these can be injected via an SSDT or injected by using DevProp section. The SSDT method is best, especially if one also wants to re-name devices. Portion of SSDT code to rename GPU devices. That is, how it's done: bridge after DODF becomes EGP0 and next bridge becomes GFX0: Result after above SSDT re-name as seen in IORE: Result after re-name by WEG. The first bridge is not re-named, but this is only cosmetic and seems to have no impact on GPU functionality. (Note: for those paying attention, this IORE taken from a different mobo than the above example, so the D0BF device is here D0C1, which would mean that the SSDT shown above would not work for this mobo unless changed, and it is for a different GPU and that portion should be changed as well.)
  5. iGPU
    It simply injects data for GPU and re-names devices. It is only useful if not using WEG. If using WEG, it is un-necessary, which is why I disabled it for @valmeida
  6. iGPU
    Terminal? No, IORE: Maybe you have a corrupted BIOS. I would re-flash latest version and then go over settings with fabiosun. But before flashing the BIOS, try re-setting NVRAM from the OC boot menu (press space bar when menu is up and scroll to left). You have your menu set for 10 sec (I don't use timed log in; but I left your settings), so you need to press a key before it auto boots after 10 sec. (With all respect to fabiosun, I don't think a lack of an SSDT-EC file is the cause of boot failure. In fact, a re-naming of an EC device can lead to system instability.)
  7. iGPU
    Carefully read what I write. I'm usually concise and reasonably accurate. There are 2 sections I cannot check: MmioWhitelist and your ethernet kext. If ethernet is working then the kext is probably fine. If you can boot into Big Sur, the MmioWhiltelist is probably fine too. ***** First off, the IORE you uploaded is an app, not your IORE file. Run IORE and do a "save as" and upload that file. Second, you extensively changed the config.plist file I spent more than an hour fixing last time. I again spent over an hour today re-re-fixing your config file. Do NOT change anything in this config file until fabiosun or I have gotten feedback from you. If you continue to fiddle with the config file (with apparently no understanding), you waste all of our time. For example, you'd completely replaced the Kernel/Patch section, so I had to carefully re-check each entry as the order was different and I had no idea what you'd done. I've re-done the SSDT section and supplied new files. Nothing there, as is, will prevent booting. Do not change it. We can refine later (with WEG active, no GPU SSDT is required). I've also removed your fancy log-in icons. It is back to basics. Leave this stuff alone while we are trouble shooting. After everything is booting properly, you're on your own with icons and change to your heart's content. But not before. Some of the problems: After fixing most of problems, I ran the ocvalidate and still had 40 errors that you'd introduced: And the tool section was not what I uploaded to you (this section alone gave 40 errors). Don't change this section; you'll never use it. The most unbelievable change you'd made was in the DevProp section as partially shown in Spoiler below (my monitor is not large enough to show it all in one shot). I'm surprised anything booted. It's now done to 1 (one). EFI-valmeida-2.zip
  8. iGPU
    I did not know you had Aquantia (I checked and you did not have them in the config file you uploaded, so I left out). You need to add the following to Patches: As for black screen, enable WEG and add agdpmod=pikera to boot argument in "csr-active-config".
  9. iGPU
    Are you booting from Sabrent drive or Samsung? Best to use Sabrent. Also disable NVMeFix kext for a test. I also did not check your Mmiowhite list, keeping it the same as we have different mobos. Double check it.
  10. iGPU
    The error msgs are probably due to out of date kext files. As for the EFI, there are many errors in your config file when trying to run ocvalidate, which could also contribute to the error msgs. I've fixed all errors and updated to OC v073. I've updated whole EFI, including kexts. I removed several items and inactivated some; changed patches, used different SSDT files, and re-vamped the NVRAM section. Also what exact BT/Wifi are you using? It's not clear what you're using; you had an odd mix of BT files which made no sense to me. I inactivated for now; you should not need BT/Wifi to boot (unless you only have BT mouse, but for trouble shooting, I only recommend wired mouse & KB). I've found that Monterey works with AIC without any kexts (but this depends on AIC, etc). Attempt to boot as is without changing anything in EFI. If this boots (and it should work with either Big Sur or Monterey), post an IORE file and I can possibly customize the USB devices with an SSDT. EFI-valmeida-update.zip
  11. iGPU
    I too updated to ß5 without any problems.
  12. iGPU
    As to why the DummyPowerManagement quirk might be important: The developer asked me to look at the Kernel panic log when the computer froze. I did so and found the following (Spoiler; small extract from end of panic log). To highlight the important part: "Kernel Extensions in backtrace:\n com.apple.driver.AppleIntelCPUPowerManagement (222.0)[C976299C-7A0C-3F2C-8A3A-524D89DEF7C6]@0xffffff8018219000->0xffffff8018235fff\n\nProcess name corresponding to current thread (0xffffff882a5816e0)". He suggested that the problem with the freeze was probably due to macOS's Intel PM (power management), which would require the DummyPowerManagement quirk to be enabled to fix the kernel panic. I tried this and found that by enabling this quirk, the crash (kernel panic) stopped.
  13. iGPU
    I do not view recommended settings as mandatory, but beneficial. That is, I view recommended settings as a way of allowing most users to have the most trouble-free functionality as possible: the basic common denominator (so to speak) for all. It's like learning to drive a car: there are many steps and rules that are not always obvious at the start, but end up benefiting most people, allowing for an overall enjoyable experience. Those who later wish to race cars or do stunt tricks will abandon those basic rules, stretching the limits by acquiring more more esoteric knowledge. Similarly, if we can get a generalized config file that is useful to as many users as possible, giving them an easy, enjoyable experience, then we've accomplished something good for most TRX40 users. So far, the only unique settings, aside from AIC and specialized SSDT files, are the MmioWhitelist (which is unique for each mobo/manufacturer, and even those have much in common with each other) and Memory configurations (which also can be simplified into 2 or 3 basic settings). Later, those who wish to streamline their config files, can trim the config file, and erase portions, to their heart's content. Using the DummyPowerManagement as an example, while I don't need this Quirk to boot, it now seems to allow me to use the AMDPG app whenever I wish, without having the computer freeze up. Meanwhile, GB mobo owners do need this Quirk. So why not include it as part of a basic, recommended config file for TRX40 users?
  14. iGPU
    In discussion with the developer, the freezing (hang) problem is solved by simply enabling the DummyPowerManagement quirk (inside Kernel/Emulate as shown in Spoiler). I'm now of the opinion that, from now on, we should keep this quirk enabled for all TRX40 mobos. (I don't see any downsides to this view.) There are still issues with the AMD Power Gadget (AMDPG) app having the submenus disappear if "statusbarenabled" Is enabled (plist file location shown below). And I see this menu problem whether SIP is enabled or disabled. This bug needs to be fixed. But at least now there seems to be no further computer lock-ups when using the AMDPG app!
  15. iGPU
    After several more crashes (everything locks up, freezing mouse–––the computer if left alone will re-boot; if impatient, a forced shutdown is required), I think I've isolated the problem... Each new kext seems okay. I can have a stable computer if one or both are running. I can even run the AMD Power Gadget app and the computer is stable. The problem is if the app has the feature to "Launch in menu bar at login" enabled (StartAtLogin in the plist file discussed below) through it's menu, shown below. Once this is enabled and the computer re-booted, the menu is no longer accessible to disable and now the computer locks up in less than 60 seconds after each re-boot due to the auto-login feature of the AMD Power Gadget app. I had to boot into Big Sur (or use another EFI where the AMD Spinach kexts were not enabled) to remove the AMD Spinach plist file. This file is located in the User/Library/Preferences folder as shown below. You can either delete it or better is to edit and set "startAtLogin" to "NO" (and while you're at it, also set "startAtLoginAsked' to "YES" to avoid a pop-up window shown in Spoiler below). In looking more deeply in the CrashReport log, one can find the following (an excerpt from that log file). I'll provide this info to the developer and maybe they can provide a fix. The bottom line, in its present state, the AMD Power Gadget system is usable (at least for me), if the Auto-Login feature of the AMD Gadget app is not activated. ADDENDUM: I found out through playing with the wtf.spinach.AMD-Power-Gadget.plist file that the menu is inactivated if "StartAtLoginAsked" is enabled and "statusbarenabled" is set to "YES". I'm leaving "statusbarenabled" set to "NO" in order to have access to the AMD Power Gadget app's menu bar. After writing the above, the system began locking up even if only the AMDRyzenCPUPowerManagement.kext was enabled (and no AMD Power Gadget app was running). This is after a morning of the computer running fine with both kexts enabled but no app running. It was only after enabling auto log-in did all the troubles start once more. Odd. I've presently disabled both kext files and have contacted the developer.
  16. iGPU
    Your reminder to update the MaxKernel is a good one, as this step is often over-looked when updating to a new macOS. However, under Monterey, the problem isn't with Aquantia ethernet ports, but with I210 and I211 ports. These ports seem to be no longer properly responding to the kexts which were working under Big Sur. I've literally spent a dozen hours or more working on the I211 problem (discussed here and here), and so far have had no success.
  17. iGPU
    This is interesting. I again tried and had crashes. I thought something might be amiss with Mß4, so I re-installed it through Recovery. Once more, AMD Power tools would crash the computer. I tried disabling various kexts and had no success. I think it is the app that is causing the crashes. I did not see any crashes with the older version from last fall with all things in the config file and BIOS being the same. I've had ExposeSensitiveData set to 14 for some time (previously having had it set at 3 or 8). I'll give the 8 setting a go.
  18. iGPU
    @fabiosun , I've begun having sudden crashes since using the new AMD Power Gadget (only tested in Monterey ß4). The computer locks up after about 3 or 4 minutes or will even spontaneously re-boot from the login screen. It happens whether or not SMCAMDProcessor is enabled, so it would seem to be a problem with either AMDRyzenCPUPowerManagement or the Power Gadget app. I did not see this with the older version. I now have the new kexts disabled and the computer has been stably running for hours, just like before. Have you noticed any problems?
  19. iGPU
    @tuxy, I don't know if you were asking for help with patches for the X570 or not. If you were, then maybe the attached config file for OC v072 will be helpful. It was used to boot a GB Aorus Master X570 into Big Sur 11.5.1 with the latest patches with a 3950X CPU. It was not verified with Monterey or earlier macOSes. I've removed most custom SSDT references, but please check and adjust the ACPI, DevProp and Kernel/kext sections for your own set up. SNs were removed. Finally, if you are using a different core count from the 3950X, adjust the first 2 patches accordingly. If you only want the patches, then throw everything else away. 😉 config-X570-v072-basic.plist.zip
  20. iGPU
    Besides the leaf7 patch, and ignoring patches specifically for < Big Sur, these 2 have not been required for the TRX40:
  21. iGPU
    One other thing to consider from Intel experience, if weird things happen, your BIOS may be corrupted. The solution is to re-flash BIOS, then re-do you settings. Next, I would literally remove as many things from your computer as possible. Only USB-2 KB/mouse, no other USB connections. Also, look at Energy Saver setting inside System Preferences. I would check Prevent your Mac... and uncheck the others. Finally, boot into your most recently stable OS (Big Sur 11.4?), let it run for several minutes to see if re-boots or freezes. If okay, then proceed with booting into Monterey on another disk.
  22. iGPU
    This may be of interest to few, but I've updated this post on the TRX40 EFI structure, specifically to show how to completely remove a device through an SSDT file. [The EFI itself is somewhat out-of-date due to the recent Patch incorporation, but the other sections are still applicable.] While the earlier post did accurately show how to remove the USB power from the internal AX200 WiFi/BT device, the WiFi portion was still attached at BYS4. Through the use of an SSDT file, the whole device can be completely removed. These results are shown in the Update, using HackCheck, at the bottom of the post.
  23. iGPU
    Unrelated to patches and EFIs, reboots on Hakintoshes (both AMD and Intel) can be due to USB problems. To trouble-shoot, try removing all un-necessary USB devices, including a TB AIC if you're using one. (I've posted on this thread how the TB AIC alone caused reboots.)
  24. iGPU
    I upgraded one drive with Big Sur 11.4 to M-ß3 and the Monterey OS was corrupted (e.g., no ethernet functionality; and who knows what else wasn't working. I had to do a fresh install and then all was working as expected. This is the recommended way even on the Intel side. After the fresh install, you can do a data migration.
  25. iGPU
    3 comments. Remove the TB AIC during all testing. Since not using Shaneee's EFI with internalized Patch 0, did you adjust Patch 0 for your CPU core count, as fabiosun described here? Some Patch 0 variations use core-1, the above link, no "-1"; try both.
×
×
  • 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.