iGPU
-
Posts
573 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Events
Downloads
Everything posted by iGPU
-
I'm on the latest BIOS for the MSI TRX40 mobo; it has Agesa 1.0.0.4. This BIOS was released in May, 2020. And yes, I'm quite obsessive about keeping kext files up-to-date, so are are the latest. In fact, I just updated OC to v060 17 July release this morning (using Pavo's OpenCore Builder!). (And thank you Pavo for clearing up my confusion with OCBuilder and kext files: I had not re-activating the Command Line pop-up on Pref/Location field inside XCode. It got turned off after the BS ß2 update.)
-
No, only "-v". I'm using latest commit: v060 dated 14 July.
-
I got VM 'host' to boot in Big Sur (even with Radeon VII), but... First, I removed all boot arguments in OC except for -v. I did have Kernel patches #1 and #2 (Penryn) enabled (from previous post). Then during first reboot, before changing VM from 'Penryn' to 'host', I did a 'Reset NVRAM' within the OC boot menu (I think this step was key). Screen stayed black at this point, so I turned off computer, restarted and once logged into Proxmox, I changed the VM to 'host'. The VM arg is the long one previously listed (except using 'host'). I then started the VM and all booted just fine into Big Sur. However, when I changed Kernel Patch from the #1 and #2 combination to #1 and #3 (leaf7), Big Sur would not boot, but froze at screen shot shown below:
-
I went through the various patches; no combination allows me to boot into Big Sur ß2 using 'host'. When using 'Penryn', booting and behavior seems the same whether the patches are enabled or disabled. I also tested with the briefer VM arg list and the longer list; again, behavior seems about the same either way. Meanwhile, booting in Catalina is easily done with either 'host' or 'Penryn'. The difference in GPUs might influence the host/Penryn problem. I ran a few tests, re-affirming some findings from a couple of months ago, using Radeon VII. First, I don't see reliable GPU function as pass-through unless 'amdgpu' is blacklisted. Example: booting into Catalina without blacklisting 'amdgpu', shows only a black background (icons and functionality are okay, but newly opened windows are laggy to display items). After 3 minutes or so, the normal Catalina background image suddenly appears. This behavior is independent of using WEG. If 'amdgpu' is then blacklisted and Proxmox re-booted, then when booting into Catalina, the background image is normally displayed and windows work well. Therefore, 'amdgpu' should be blacklisted in Proxmox for good Radeon VII behavior. With Big Sur, if 'amdgpu' is not blacklisted, I cannot boot into Big Sur; 'amdgpu' blacklisting is essential for Big Sur (at least thru ß2) with Radeon VII. So there is a difference in GPU behavior and 'amdgpu' blacklisting between Catalina and Big Sur. (And I think the 'amdgpu' issue is different between my system and yours, fabiosun, in spite of our both using MSI mobos.)
-
I will re-test later tonight after work, using: "args: -smbios type=2 -cpu host,vendor=GenuineIntel,+invtsc" in VM. This is much abbreviated than the one I'm presently using (which I posted a few threads ago). There is also one other patch I've used, making a total of 3, and I'll try the various combinations when using 'host'. Also, I just realized that in the patches section, the "MaxKernel" was set to 19.99.99 which does not include Big Sur, so perhaps none of these were even loading when I did the test last night (mentioned above). Best to leave this section blank, as the exact numbering of Big Sur is not clear (v 11 or 10.16.0; if 10.16.0 is used by Apple, then MaxKernel would become 20.00.0, or better, 20.99.99). *** ADDENDUM: I had time to run 2 tests using brief arg list in VM and cpu set as 'host'. Referencing the kernel patch list above (with MaxKernel = blank): A) #1 and #2 enabled --> no boot B) #1 and #3 enabled --> no boot
-
Enabling those 2 patches, still does not allow me to boot in BS as 'host'. I can boot into BS with both enabled or disabled as 'Penryn'. Using the same settings, and having those 2 patches enabled and using 'host', I can boot into Catalina (but, again, not BS).
-
Thunderbolt 4 was announced by Intel a few days ago. It seems this will be in parallel with USB4. USB4 was to include Thunderbolt, but it's not clear from their table that it does.
-
Sorry, while I normally keep all boxes, I threw away the Enermax box since I'd modified it and there was no chance of returning it. The code 2020-05 probably means it was produced in May of this year, so more recent production than mine.
-
I'm ignorant of changes within version II. I would assume production changes do occur. Mine was a new, shrink-wrapped box that I'd bought at a local MicroCenter shop in the first part of April this year.
-
I too cannot find any info. However, I rather doubt any new Apple Silicon computers for the coming year will have more cores/threads than the just released MacPro7,1. I would think the first Apple Silicon machines will be less expensive models. So I'd be surprised if Big Sur supported more cores than any machines currently produced.
-
Today while testing kext loading, I seemed to have found an anomaly. Kext files that only contain Info.plist in their contents are not being loaded. I posted on the active OpenCore forum here, so I'll not repeat the details in this post.
-
This web site has interesting, and well-thought out, commentary on Mac related issues (and also interesting essays on art). In this post, the writer discusses Apple Silicon matters as well as better describes the problem with kexts in Big Sur. On at least 2 other forums, I've read how many people have been trying to install kexts into Big Sur using Recovery Mode. In turns out, the Recovery Mode method is only for 3rd-party kexts to be used by Apple Silicon Macs. For our Hackintoshes and real (Intel) Macs, kexts intended for Intel-based machines are simply to use essentially the same installation methods as with Catalina, which OpenCore is handling for us with its updates.
-
This post raises 2 issues: Cinebench 20 speed in Catalina vs Big Sur (trivial), and 'host' vs 'Penryn'. *** I'm presently running Big Sur under 'Penryn' VM setting (since I cannot yet get 'host' to boot), while previously, Catalina was run under 'host' VM setting. When testing Cinebench 20, the score in Big Sur is about 500 lower than I was seeing in Catalina. So to keep things equal, I used the same VM and EFI settings for Big Sur to boot into Catalina. When I run Cinebench 20 under these conditions, I again get a 500 greater score in Catalina (17700 to 17800) than in Big Sur (17200 to 17300). I ran these tests several times over several boots. So while Cinebench 20 is (presently) slightly slower under Big Sur, the 'Penryn' setting does not run any slower than 'host' with Catalina. *** The above similarity in speed in Catalina when running under either 'host' or 'Penryn', makes me wonder how significant is either setting in our VM. I've read such statements as those below, which doesn't clearly indicate one being necessarily superior to the other: "For homogeneous clusters and single host setups, use the 'host' option. For mixed clusters, use the lowest available CPU version, so if one host is Penryn and the other Nehalem, use Penrym on both." "The 'host' option is good, but not the most efficient because it might enable options that can be emulated but that your cpu does not support. The guest system can then be slowed down anytime it tries to use one of those features that needs emulation." Supposedly, to see the differences between the host and the guest, one can type: grep flags /proc/cpuinfo | uniq, which gives on my system: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca But my VM for the guest has these arguments: -cpu Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+avx2,+aes,+fma,+fma4,+bmi1,+bmi2,+xsave,+xsaveopt,check I don't understand how the above command lists unique items, since many are in common to both host and guest, such as: aes, avx, avx2, bmi1, bmi2, popcnt, xsave, xsaveopt (assuming that the VM properly used the argument flags for the guest).
-
I used the first method. In the BigSur VM, I set ide0 = BigSur.iso (containing BigSur ß1 Installer), ide2 = opencoreBigSur.iso (containing OC EFI), and "bootdisk: ide2". Once the above was booted, installation was onto an NVMe drive that was first formatted (erasing a previous M.2 drive that was used as a Catalina backup drive) before running the BigSur Installer. After BIg Sur was running, the new EFI was set up on the BigSur drive's EFI partition. Next, the BigSur VM was edited: ide0 and ide2 entries were commented to disable and "bootdisk: ide2" was replaced with "boot: d". Now, the BigSur EFI partition is directly booted.
-
If the sound is new, I assume it is not from the chipset fan (which can be noisy at times unless slowed a bit). I hear almost no sound from the pump even with my ear close by, unless I run it full speed. When I dismantled the Enermax pump to clean out the system, I did notice some burrs inside the aluminum pump housing. I sanded this part smooth (unfortunately, I took no photos). Since I did not run it before dismantling it, I don't know if those burrs would have produced any noise. I wrote Enermax about this issue, but they never responded.
-
Attached are the BIOS settings for my fans. I never keep any fans running at the same speed; this can set up a resonance that can make fans noise louder. Even when I have multiple fans on the front (and often even on radiators), I set each one 50 to 100 rpm apart from the others. This is why CPU1 fan ≠ SysFan1 ≠ SysFan2. Overall, the fans are very quiet in their case (a Thermaltake View 71). It's a big case. I placed the CPU radiator on the top. I drilled some extra holes and mounted 3-140mm fans in the front (stock was 2). I still have yet to convert the 2 Radeon VIIs to water cooling That will require at least one more fan header. I presently have 5 free headers. *** First image is the CPU fans (the 3 fans on the radiator). The next image is the pump settings. Next, is the TRX40 chipset fan (inside shroud): Finally, the case fans (there are presently 2 sets: 3-140mm intake fans at front and 1-140mm exhaust fan at rear):
-
Attached is a current config.plist file. There are references to SSDTs I use specific to my mobo (but SSDTs not included) as well as typical kexts being used or disabled (like VirtualSMC). Also, I removed details inside PlatformInfo section (it is not functional as written; so if using, replace this section). And finally, I did re-place the "booter" comments inside NVRAM for some more testing. As is, this config file boots fine into ß2 with latest release of OC (5 July, v060). config.plist.zip
-
fabiosun, you interested me in looking at CPU history (part of Activity Monitor utility) when running Cinebench 20. All cores are simultaneously activated, as shown in the green peaks:
-
I forgot to mention that I've now ordered 2 more FireWire cards that looked exactly like Driftwood's photo (an older style of power plug is present on card). But what arrived were new models with TI chips, which meant bridges. I had to return them. I now give up on buying more FireWire cards. Unless we can come across some new-old-stock ones, we're out of luck until bridges can be passed-through.
-
The BigSur VM config:
-
I've been testing WEG with Radeon VIIs. I now see no problems running under Big Sur. I used to see freezes within just a few minutes, but not now. Good news. I'm also testing WiFi issues. I now seem to have no problems with it under Big Sur (USB audio dropout). But, the previous problems may have been related to 2 kext files. Historically, I've used several kext files for BT and WiFi: AirportBrcmFixup.kext, BrcmBluetoothInjector.kext, BrcmFirmwareData.kext, BrcmPatchRAM3.kext, and BT4LEContinuityFixup.kext. As I began work using Big Sur, no kext files were being loaded, so I turned off most trying to sort things out. Once the kext files were loading, I began turning them on selectively. When I turned on BrcmFirmwareData.kext and BrcmPatchRAM3.kext, I saw more erratic behavior using BT. I've now only have enabled: AirportBrcmFixup.kext, BrcmBluetoothInjector.kext and BT4LEContinuityFixup.kext. These 3 kexts seem to give good BT and WiFi response with the BCM4352 swapped card. So now WiFi also seems stable. Again, good news. And this is with an early beta Big Sur.
-
fabiosun, I found that I could not boot if I used 'host' instead of 'Penryn'. The Apple logo appeared, but no progress bar. Strange.
-
I updated to latest OC: v060, 5 July. Now all boots just fine. It was the kext related Cpuid discussed above that was apparently hampering a boot with latest OC. And with this latest OC, no extra "-lilubetaall" or "booter-fileset-basesystem" or "booter-fileset-kernel" arguments are required in the NVRAM section for kext injection. Presently, I am not enabling VirtualSMC. WEG is again enabled; it now seems okay with Radeon VII cards. I'll be re-testing WiFi stability with my build and BigSur, since when running Mojave or Catalina, there were stability issues when WiFi was enabled.
-
I finally got kexts working in OC v060 28-June. (I'll update to latest OC in a few minutes.) BT and Ethernet now working just fine. To check kext functionality, run this in Terminal: kextstat | grep -v com.apple What was preventing kexts from loading was a hold over entry for Kernel/Emulate. Once I deleted the entries for Cpuid1Data and Cpuid1Mask, things were fine. I also updated to ß2 this morning without any issues. I rather like Big Sur better than Catalina (and I'd preferred Mojave over Catalina). Edit: I have seen one glitch with ß2. When trying to access "Accessibility" item (I was looking to increase size of the cursor) within System Preferences section, I get a spinning beachball and must force quit Preferences. I'd not seen that on ß1 (but no size adjustment was visible). <--- I had VirtualSMC.kext enabled. I disabled and enabled WEG. Now Accessibility is working again. In summary: I've left VirtualSMC disabled; WEG, enabled. Also, when trying to adjust the Date & Time/Menu Bar Clock, items are grayed out in these early betas.
-
I've been asked how to make the Enermax Liqtech TR4 II stable, as it has a bad reputation on the internet. Many of these pumps have failed due to internal corrosion thought to be due to poor or non-existent anti-corrosion solution. Before using, I 'repaired' the cooler: first, by flushing out the radiator and pump housing, next by re-filling with a good quality, anti-corrosion solution, and finally, by re-surfacing the plate. I used these two videos as a start for the tear-down (the pump method is cleaner; I did the work in my kitchen sink): https://www.youtube.com/watch?v=luUwpbdYnaQ https://www.youtube.com/watch?v=Hx-fhoB5Gyo I used this pump to flush the radiator several times with water before re-filling: https://www.amazon.com/gp/product/B07GR1HSR7/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 I used this solution (it's a concentrate; follow directions on bottle to dilute with water) to re-fill the radiator/pump: https://www.amazon.com/gp/product/B00CDXQ22M/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 I then re-surfaced the plate, as I already posted in this thread here, to make the surface flat to better transfer heat from the CPU. After the above steps, the pump works great with good thermals and it is very quiet. More importantly, after these 'repairs', the functionality and longevity should be much improved. BTW, the fans that come with the pump are actually very good and I did not replace with Noctua fans as originally planned. When setting pump speed in BIOS, you want to set the speed at a minimum of 2500 rpm (less than 2000, the pump won't work and the LEDs won't turn on: the LEDs are a good indicator that the pump is working). I think it's now running closer to 3000 rpm. If running at full speed (>4000 rpm), it is too fast and I think will shorten life-span of the pump. I mainly use fan speeds to vary cooling and keep sound at minimum when thermals are low.
