iGPU

During installation, Proxmox on the next to last screen, will automatically fill-in an IP address, such as 192.168.1.55 (based of course, on your network's setup). At that point, you can accept it as is, or change it (if you do change it, only change the last segment, such as the '55' to '60'). That IP will remain fixed for your host. On the first boot, Proxmox will remind you on the host screen of that IP address, and you'll be prompted to enter you user name ("root") and the password you entered during set-up. After that, you can connect to the host. You connect to the host via WiFi (or hardwired) from another computer (laptop, desktop, etc). You'll enter the above IP along with "/8006" (for example, 192.168.1.55/8006), in your browser. This browser window will become the Proxmox GUI interface for your VM.

I would advise against GB Designare for the moment. My build is totally messed up. The computer now can only stay on for ~1 min before locking up. It was gotten worse over the past 4 days, when it began crashing after 1 hour. The crashes became progressively faster, barely allowing me enough time to boot into macOS. I'm getting strange error messages (see spoiler). These appear on host and GUI, sometimes superimposed while editing inside a file. Errors: I either have a bad mobo or bad CPU. I think CPU is probably OK, but I've contacted AMD customer service to get their opinion. Meanwhile, I'm getting an MSI Creator mobo, possibly tomorrow. If this works, then CPU okay. While researching problem, I came across many issues with GB TRX40 mobos (search on Prime95-TRX40-errors). It seems GB not fast in fixing TRX40 BIOS. Some on forums think GB is too interested in getting Z490 mobos ready as more $$ selling those than TRX40s. In looking at an alternative, I see that MSI has latest fixes for AMD micro-code, as compared to any other manufacturer. Also, MSI/AMD seem to be working with RED camera for 8K processing so maybe MSI has greater interest than other manufacturers to stay current. Anyhow, I'll be able to report back soon which is bad: mobo or CPU.

This afternoon, I swapped out the BT/Wifi module in the TXR40 Designare. On first boot, Wifi was working but BT was not. When this is seen, it almost always is due to the BT section not receiving USB power. On the stock module (which was 8086:2723), the associated USB was 8087:0029. The above test suggested that 8087:0029 was no longer the correct USB power source to pass with the swapped PC card, and vfio.conf needs adjustment. Running this command: dmesg | grep -e 'bluetooth' -e 'usb' yields the following (excerpt): [ 2.933820] usb 7-5: New USB device found, idVendor=0489, idProduct=e07a, bcdDevice= 1.12 [ 2.933821] usb 7-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.933822] usb 7-5: Product: BCM20702A0 [ 2.933823] usb 7-5: Manufacturer: Broadcom Corp [ 2.933823] usb 7-5: SerialNumber: 48E244E224BA [ 2.964018] usb 5-5: new high-speed USB device number 3 using xhci_hcd [ 3.064028] usb 7-6: new high-speed USB device number 3 using xhci_hcd [ 3.087535] usb 7-6: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=85.36 [ 3.087536] usb 7-6: New USB device strings: Mfr=0, Product=1, SerialNumber=0 Based on this information, I adjusted vfio.conf, entering 14e4:43a0 for the PC card. The last 2 IDs are for USB (probably only one of the two is actually needed, but I simply passed both): options vfio-pci ids=14e4:43a0,0489:e07a,05e3:0608 After this update (and running: update-initramfs -u -k all, then re-booting), both BT and Wifi worked just fine in macOS. So despite swapping out the BT/Wifi cards, the USB power source did not remain the same and must be adjusted for BT to work. The values I found may not be correct for your module and mobo. One other caveat regarding BT/Wifi swaps. These swapped modules do not work well in Windows (I don't know about Linux). So if BT is sufficient in macOS (and Wifi is not needed), and BT/Wifi is important in WIndows, then don't swap the module.

Well, no, the point of what I wrote is that even if it works on bare metal, there is NO guarantee that it will work via VM. And if it doesn't work, it is most likely due to a pci-bridge issue. You literally got lucky by having one that does not use a pci-bridge.

Now, I'm seeing a pattern with regards to passing devices. In summary, it is a current limitation of Linux. I tried to pass a FireWire card I've used on several Hackintosh builds (a Vantec, here). It works natively on those builds (several Intel Z390 and one AMD X570). But on this TRX40 build using VM, it's a no-go. I can get drivers loaded on macOS, but SystemInformation-FireWire panel says that no devices are connected to the FireWire bus ("Warning: Unable to list FireWIre devices"). ...and now I see why. On my build the card looks like this: 49:00.0 PCI bridge [0604]: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] [104c:823e] (rev 01) 4a:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] [104c:823f] (rev 01) while on Driftwood's build, his FireWire looks like this: 4d:00.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller [11c1:5901] (rev 08) Subsystem: Device [5901:1101] Kernel driver in use: firewire_ohci Kernel modules: firewire_ohci This difference is not due to our mobos, but the PCIe cards themselves. My Vantec card contains a pci-bridge at 49:00.0. While I can easily pass 4a:00.0, if I try to pass 49:00.0, Proxmox (Linux) reports that the device does not exist. The reason: Linux cannot pass pci-bridges. Since only part of the card can be passed, FireWire does not work on my build. Similarly, fabiosun, we cannot pass 42.08.0 as it too is a pci-bridge. And... this is why I cannot pass a functioning Thunderbolt card: it's missing the pci-bridge sections on the macOS side. And the reason that they're missing is due to the same inability of Linux to pass ANY pci-bridge. If a device contains a pci-bridge, the device will be 'broken' in macOS. Until Linux can pass pci-bridges, associated with a given device, we will have limited functionality on the macOS side of things when running as a VM. In this FireWire example, for me to get a functioning FireWire card, I need to get one (you got lucky, Driftwood!!) that does not have a pci-bridge. I hoping this one doesn't have a pci-bridge.

If you look at IOMMU groups, which must be passed together, there are some missing if you discretely pass 47:00.1 and 47:00.3, etc. It's my understanding that all components within an IOMMU group must be passed together, or the items must be further separated into discrete IOMMU groups and only then passed separately. The IOMMU group for my mobo for this same USB is in IOMMU group 52: 42:08.0 PCI bridge for USB 46:00.0 Non-Essential Instrumentation 46:00.1 USB controller 46:00.3 USB controller so for VFIO: options vfio-pci ids=1022:57a4,1022:1485,1002:149c and for the VM file: hostpci6: 42:08.0 hostpci7: 46:00 <--- leave off ".0" to include all components of addr 46 *** Similarly, the SATA has an IOMMU grouping 54: 42:0a.0 - PCI bridge for SATA 48:00.0 - SATA: options vfio-pci ids=1022:57a4,1002:7901 (1022:57a4 is same for both the USB and SATA bridges, so only needs one entry) and for the VM file: hostpci8: 42:0a.0 hostpci9: 48:00.0 *** and finally, the SBUS is tied in with ISA in IOMMU group 11: 00:14.0 AMD SMBus Controller 00:14.3 ISA bridge options vfio-pci ids=1022:790b,1022:790e and for VM file: hostpci2: 00:14 <--- leave off ".0" to include both components of addr 00:14 *** You can check your groups by running (after PAVO): for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}:" for d in $g/devices/*; do echo -e "\t$(lspci -nns ${d##*/})" done; done; But... the problem when I try to run this is that I get an error, for example with the USB group trying to pass the whole IOMMU group gives the error: "kvm: -device vfio-pci,host=0000:42:08.0,id=hostpci6,bus=ich9-pcie-port-7,addr=0x0,rombar=0: vfio 0000:42:08.0: error getting device from group 52: No such device Verify all devices in group 52 are bound to vfio-<bus> or pci-stub and not already in use" Fabiosun, maybe this is because I'm using the 'trimmed' down /usr/share/qemu-server/pve-q35-4.0.cfg that you previously posted? However, I don't see any of the excluded items listed as 'port-7'. And, I cannot pass anything at 00:14, as these items give an error: kvm: vfio: Cannot reset device 0000:00:14.3, no available reset mechanism. kvm: vfio: Cannot reset device 0000:00:14.0, no available reset mechanism. kvm: vfio: Cannot reset device 0000:00:14.3, no available reset mechanism. kvm: vfio: Cannot reset device 0000:00:14.0, no available reset mechanism. I think I've read that we can only pass items that can be "Reset".

I'm having some odd findings that perhaps someone can shed light upon; it's possible it's unique to my mobo, but I doubt it. With the PCIe slots empty except for the GPU in slot 1, I pass 2 NVMe devices, 1 Ethernet port @ 44:00 and 1 USB controller @ 46:00 (the ones at ~4:00 and ~25:00 won't pass) and the built-in BT @ 45:00 (but this only has BT functionality). No SATA is being passed. Things work fine. If I try to add a Fenzi card (well-regarded in the Hackintosh community) in slot 3 or 4 (passing it at 49:00), I find that no USB is available once macOS boots. No port on the mobo is active; all are without any power. I still have control via Proxmox to stop the VM, but then it won't re-start and I must re-boot everything. Meanwhile, if I don't pass the native BT @ 45:00, but pass everything else as above, I get into macOS with USB seemingly active. But after 1 or 2 min, the mouse cursor disappears and all is frozen. Proxmox can still. This sequence is completely repeatable, and I can remove the Fenzi card, re-pass the native BT and all goes back to working as before. I am mystified as to why USB is being dropped. I'm pretty certain as I write this (but I'm at work so cannot verify) that the Fenzi card is on it's own IOMMU group (I can't see how or why it would be added to an on-board USB controller's IOMMU group). One test I will try is to add a PCIe USB card (one is on order). This will allow me to pass it in parallel with the Fenzi card to see if that will maintain USB. But then BT probably won't work unless I use the PCIe USB card to provide USB power to the Fenzi card. Has anyone successfully passed an add-on BT/Wifi card on this build?

My present drive scheme: The Proxmox boot drive is a 500GB SATA SSD drive at SATA port 1. At SATA port 2, I installed Windows 10 onto a SATA SSD 1TB drive. I'll boot Windows directly; it makes no sense to me to hassle with VM for Windows on this build; just hold down F12 key during BIOS boot. On the mobo, in the M.2 slot closest to the CPU, is the 1TB Sabrent Rocket 4.0 (E16), which is the "Macintosh HD" drive. In the next M.2 slot over from that drive, is the "Catalina" drive, which is a slightly slower Sabrent 1TB NVMe (E12). There are 2 other M.2 slots on this mobo, both facing each other adjacent to the 4th PCIe slot, farthest from the CPU. These are presently empty.

I've solved the prolonged boot problem... it took me several days because I forgot a maxim with Hackintoshes. If you get strange boots ,without having made major changes, consider 2 sources: BIOS and OS. That is, our Hackintoshes during our initial builds have frequent crashes/freezes/forced shutdowns. These episodes can lead to corrupted BIOS and macOS. The fix is to re-flash BIOS. This is fast and pretty easy. I'd done that, but it didn't help. The second, and more annoying fix, if you don't have a bootable backup (which I did not on this machine), is do a fresh install of macOS. My Mojave drive was corrupted and this is what led to prolonged boots (2 to 3 minutes, instead of 10 or 15 seconds. So I made a fresh install; this time using Catalina. I started in Mojave and erased (formatted) the new drive. I then copied the EFI partition contents from the Mojave drive to the new drive's EFI partition in preparation for the next step. (Remember to copy the EFI folder to the EFI partition; don't be too fast and copy the contents of the EFI folder to the other EFI partition: it won't boot). I had already downloaded the Catalina installer onto the Mojave drive and next proceeded to begin the installation on the new drive (named "Catalina"). At the end of the installation, when prompted if I wanted to transfer data, I indicated yes and did a migration between the Mojave and Catalina drives. This allowed me to have almost all settings and apps ready to go. Once I knew it was functioning well (and booting very fast), I created a backup. The backup was the old Mojave drive: I erase/formatted it (naming it "Macintoth HD"), using Carbon Copy Cloner (CCC) to duplicate the new Catalina drive. Now there are 2 drives with Catalina. The one labelled "Macintosh HD" will be the main drive and the "Catalina" drive will now become the backup. There was (is?) some documentation for OpenCore indicating that a drive traditionally named "Macintosh HD" will behave better. (I can't swear by this; but I've kept this naming scheme for the main booting macOS drive.) Periodically, while things are stable, I'll run CCC to keep bootable backup current. If I get another corrupted macOS drive, then it's a simple matter to clone the backup back to the "Macintosh HD" drive, saving much time.

I just ran 8K Bruce X test. First run was just over ~18 sec, next 2 runs were each under 2 sec ~1.7 sec. I followed the instructions as given here. Attached is the file that contains the 8K as well as two 5K versions of Bruce X. It is interesting that the times for 5K and 8K are the same. So the times are not 'limited' by the resolution but by maybe the software. Whatever, this build is pretty fast! Again, this is with one Radeon VII, no WEG, no SoftPowerTable injection, but with Radeon kext all under Mojave. (I plan on adding a 2nd Radeon VII in a few days; a very fast machine even if there is no TB.) *** I added a connector to the USB3 plug on the mobo as shown in photo. It was bought off Amazon here. This passes-thru with the back panel USBs (~ 47:00 on my mobo). This gives much better USB performance, using the same drive that had the very delayed opening when plugged into the USB3 jack on the rear panel. Both connectors are part of the same 47:00 group that is being passed-thru, so I don't understand why one is faster than the other. However, at times, after copying some folders or scrolling within a window on this external USB drive, the whole computer would freeze. But after 20 to 30 seconds, it would un-freeze and behave normally----as long as I didn't interact with the external USB drive. The internal drive is just fine and everything is very fast. Not so with the external USB drive: there is still something strange about USB external drives on my build. Bruce X.fcpbundle.zip

Yes, I posted this some time ago: here. I also included the BT kexts to allow it to work. I repeated comments about it here. Again, so far, only BT works, but there are people actively working on the Wifi components, so only a matter of time before it all should work.

I just ran 5K Bruce X test. First run was just over 9 sec, next 2 runs were each under 2 sec; maybe 1.8 sec (my reaction time is too slow to stop timer; I tried ChronoX was didn't seem to work correctly). This is with one Radeon VII, no WEG, no SoftPowerTable injection, but with Radeon kext all under Mojave.

I don't know your exact mobo. Intel is supported on macOS side for 1GB Ethernet, but not 2.5GB (1GB = I210. I211 and I219, but these need kexts to work). So if you have 2.5G ports, I don't think any kexts allow them to work. My mobo has two I210 and needs SmallTreeIntel82576.kext to work. I pass one of the two (the 2nd one) for macOS and leave the first one for host. If you look at PVE/Network via the GUI, you'll probably see that the first one in list is active at your IP (CIDR section) and gateway. The first will be named something like enp68s0, and the second, enp69s0. (if you have a 3rd controller, it will be named in sequence, enp70s0). Since the the first is active, you'll want to pass the 2nd one in list. This port will also be the 2nd controller listed when running "lspci -nnk". If you pass the active port, then you'll lose the VM and host connection. (BTW, I run without any "net0: vmxnet3" bridge port; hardware only.) Meanwhile, if you have Aquantia AQC107, it is natively supported on macOS side: no extra kexts needed. I'd pass the Aquantia controller and leave the others for host.

It seems like I may have seen this when I forgot to add: echo "options kvm ignore_msrs=1" > /etc/modprobe.d/kvm.conf Also, when you move drives, you need to re-run "lspci -nnk" as the addresses change when you move anything on the mobo. At the very least, the drive will change to a new address, or at worse, everything gets shifted. Also, these movements change where macOS loads the devices as seen in IORegistryExplorer; so some SSDT files or DeviceProperties may need adjustment too.

I'm not using patched kernel; I tried PAVO's but was getting a green screen. I am using Proxmox 6.2. I will re-check verbose mode. Thanks. TB USB did pass, but was not functional. Even when passing NHI portion, TB drivers started to be loaded on the macOS side, but again, not functional. *** After adding -v to OpenCore boot arg, the verbose portion went fast, then the Apple logo appeared and started the progress bar. The progression stopped at about 25%, with no more words appearing, then suddenly went to login screen after 60 sec or so. So this didn't help to figure out the prolonged boot problem. Then after running for 10 to 15 min, it locks up. I'll try turning off WEG as lock-ups after 15 min is commonly seen on Intel platforms when running WEG and Radeon VII GPUs. *** After testing above, I was suspicious of AppleALC. Leaving WEG and AppleALC disabled, the progress bar no longer paused, but still took a long time to boot. Maybe an issue of newer AppleALC kext breaking something as I had updated various kexts (I'd made so many changes, it is difficult to isolate one). Newest version used was v1.4.9. This was the problem: AppleALC. Using an older version from Oct, 2019 fixed the problem (v1.4.3): boot went rapidly. I don't know when in the updates the problem started. I may test tomorrow different ones, but I'm avoiding v1.4.9 and suspicious of v1.4.8 until tested. update: 5/19/20: Re-tested to the above issue with different versions of AppleALC and now the older versions are giving the same delay. I now don't know what is going on. It is curious that sometimes changing WEG, AppleALC or DeviceProperties which inject Radeon VII SoftPowerTable data affect this prolong boot. It must be related to the GPU. Further investigation needed on my part. update: 5/21/20: the problem was erratic because the main macOS was corrupted. See this post for clarification.

Yes, I'm using the Audient EVO4 (USB DAC) without any problem. I am giving up, for now, on TB. Based on what I've tried and the response from the Proxmox forum, it is not possible (at this time, as they said) to pass-through a TB device. On a related issue, has anyone passed-through a BT/Wifi card (like the Fenvi) that's commonly used on Hackintosh builds? When I try, it seems to pass, but is not active on the Mac side (I've included what I believe are its associated USB devices). I know it's a good card as I pulled it from a working build. I can pass and use the on-board BT with special kext files; but the Wifi portion of the AX200, does not yet work, so not ideal for full Mac functionality. I realize that a BT card swap is possible, but BT with the AX200 is more powerful. On other Hackintoshes, I use the native BT from the mobo and supplement with Wifi from the Fenzi card for a nice combination. One significant problem that's cropped up for me it a prolonged boot, but only when using a pass-through GPU. I've not been able to sort it out for over one week now. (I initially did not see this, but now occurs no matter the GPU.) The Apple progress bar hangs about 2/3 of the way (after the screen flashes off then back on) and sits there for about 90 sec, then it progresses to login. However, about half the time after login, I have no USB connection. I tried with and without the recent trimming of devices discussed here, but of no help. (I do like having the devices trimmed.) The late boot problem seems like a GPU related matter, but using WEG or not using WEG has no effect, nor does injecting or not injecting DeviceProperties.

Interesting! I didn't think dual GPUs worked with Hackintoshes, as they do on the Windows/Linux side. Are the scores noticeably improved with the 2nd GPU (I think I saw 120 on an earlier post vs 146 here)?

As I mentioned here I'm using an Audient USB interface without problems. There are many good USB interfaces now. A new Apogee Symphony USB desktop interface is supposedly coming to market soon (here) and will be bundled with various plugins. A TB interface may be possible if I can activate it. The TB device tree is nested along with the NVMe drive and 2 other nodes, and so far has eluded me in creating an SSDT (I've written SSDT files for other nested USB nodes on this build without difficulty). I continue working on it. There may be a juggling act to balance the NVMe positions and how they and the TB device are assigned addresses, so next step is to try different locations for each part and see if a more amenable address is assigned to permit a functioning SSDT.

I've got TB3 tree working in this build! More things to work out; details to follow. The teaser is the tree below with details appearing in the PCI/Thunderbolt section. This card was previously flashed with firmware. (I also inserted the GB4 window to show that it is indeed the 3970X CPU.) Interestingly, I only passed 15eb and 15ec. The other TB3 sections I did not even try to pass-thru. The card is in slot-4 and has the TB header connected, the USB-2 connection and the power jacks applied. I think I was blocking the appearance of the TB device while re-naming USB devices, and each part was appearing on the PCI0 tree. Now, the entire TB tree is appearing within SB0, which contains the NVMe (M2M slot) drive located at 1:00.0. This drive contains macOS Mojave. Next, I'll work on the SSDT; once this is working TB3 should become functional. Unfortunately, after I made the image below with passed-thru Radeon VII, I made many changes to config.plist file and now I cannot boot into macOS while passing the GPU. (Nuts.) Also, my water cooler pump is making a loud racket and I think I'll need to replace with an air-cooler. BTW, fabiosun, how to you monitor temps; the usual SMCAMDProcessor kext doesn't work on the TRX40?

A few days ago, in an attempt to allow better TB3 functioning (due to lane-sharing issues between PCIe and M.2 slots), I moved the macOS NVMe drive from slot closest to the CPU, along with the Proxmox MVMe drive from the next slot, placing them both into the two M2M slots farthest away from CPU. (The GB TRX40 Designare has 4 M.2 slots.) These latter 2 slots go through the TRX40 chip rather than the CPU, and supposedly should eliminate lane-sharing issues. Instead of helping TB problems, it created many other problems, and left TB3 working as poorly as ever. So, I took a well-working system and converted it into a broken one. I immediately lost control both on the host machine and my laptop SSH/Console to control Proxmox. Even moving the Proxmox drive back to its original location didn't restore control. One thing I did find, after a suggestion by fabiosun, was to look at my blacklist. I found that blacklisting amdgpu prevented seeing the command line on the host monitor. If I'd had access to the host, I could have salvaged the original build. I've since permanently removed amdgpu from the blacklist.conf file. I've gave up trying to fix the mess and re-installed Proxmox. Yet, nothing was working as well as it had. Besides many re-installs, I've even re-flashed BIOS. Some problems, I now track back to using parts of PAVOs GitHub that somehow gave me a green screen when booting both Proxmox and Apple screens; even different GPUs gave same green screens. I don't understand why. Only by using the very basic instructions by fabiosun was I able to get a bootable build. But all is not as it was. While I can boot via Console into macOS, if I pass-thru the Radeon VII (that was working perfectly last week), the boot only makes it to the Apple logo with no progress bar: frozen. When verbose mode is turned on, it stops at slightly different locations on each boot attempt. If I revert back to Console, macOS fully boots; back again to GPU pass-thru: macOS again stops at the Apple logo. So pass-thru works (the main monitor is on and showing the start of the boot), but Mojave won't fully boot. BTW, other things pass-thru okay; strange. While I've still not sorted this out, the next step in trouble shooting will be to remove all pass-thru devices except GPU and slowly re-introduce them. *** On a positive note: I found that if you boot using "boot: ide2" (where, ide2: local:iso/opencore.iso,cache=unsafe,size=512M), once you're in macOS, you can load the EFI from the QEMU drive. This contains the de-compressed opencore.iso. Since it's booting from the iso file, you can alter and save it, effectively making changes to the iso file. In other words, if you make changes to this EFI folder (update opencore to v058, add SSDTs, turn kexts on or off, etc.), the changes will be written back to the opencore.iso file under Proxmox: this is like an automatic ISO conversion. You can then copy this updated opencore.iso file back to another computer using the command from the other computer (I used Terminal from my laptop). I did this so I could re-load this updated opencore.iso between my many re-installs. scp root@IP_addr:/var/lib/vz/template/iso/opencore.iso /Users/userName/Downloads/opencore.iso (where IP_addr is the VM's log-in IP) If the ISO file is several GB is size (like a Win 10 iso), the built-in Proxmox Upload feature will fail, so you'll need to use the following for large files: scp /Users/userName/Downloads/Window_10.iso root@IP_addr:/var/lib/vz/template/iso/Window_10.iso Similarly, it is easy to upload the GPU.rom file from an external computer using the same command to the folder that is for GPU rom files (different from iso location): scp /Users/userName/Downloads/myGPU.rom root@IP_addr:/usr/share/kvm/myGPU.rom If, as has happened to me with the various re-installs of Proxmox, there are 'host key' restrictions preventing you from reading or writing using the above commands, enter the following into Terminal on Mac and this will re-set permissions, allowing you to re-try one of the above commands: rm .ssh/known_hosts *** EDIT: With pass-thru using Radeon VII, I can now get 2/3 of Apple progress bar (earlier today was zero progression). The change: disabling 4G. The whole problem is curious. Before I moved the NVMe drives, 4G was enabled and the Radeon VII was easily pass-thru and good booting was seen. Those slots share lanes with the CPU. Now that I've moved both drives to M2M slots, which instead share lanes with the TRX40 chip, the 4G must be disabled for graphics. This is an interesting issue. When I was working on the X570, I had many issues with lane-sharing and it took me many days to sort it out as I'd not seen it discussed (briefly covered on my GitHub for X570 here and throughout a thread at AMD-OSX co-worked with CaseySJ). So here it is again with the TRX40 mobo: when different NVMe slots and different PCIe slots are used, different BIOS settings and different PCIe addresses are required. I will probably move the NVMe drives back to the original positions as the current setup is more difficult to successfully boot.

I was monitoring Proxmox on a Mac laptop: when running Cinebench 20, there is an expected increase in CPU usage over that during idle stand-by. Idle: Cinebench 20:

Modest update on TB. While I still don't have it fleshed out, it does look promising if I can get the 'bridge' portions (addresses 49:00 and 4a:00 passed through), I truly think it will work. The problem is on the Linux/Proxmox side. In the screen shots below of IORegistryExplorer, I used a very modified SSDT to change the USB section and it worked, perfectly generating the USB section. This now shows up in the Sys Info/PCI section as well as in Hackintool. Unfortunately, hot-plugging a USB or TB drive does not yet mount, but this is not surprising since the whole TB tree is not present. IORegistryExplorer: System Information / PCI Section: Hackintool USB Section:

The new 1.0.0.5 Microcode can be applied to CPU directly via Windows. When AMD updates microcode, the mobo manufacturers will usually update their BIOS at a later date to include this microcode as well as make any changes they see fit (MSI has updated some mobo for X570 style). When the microcode is made available, it can be flashed independently of the BIOS. If later the BIOS is updated to same microcode, then nothing changes with the microcode. It is probably safer to simply wait for manufacturer's updated BIOS. (I've never flashed microcode before.)

Do you think that the updated AMD micro-code might help? AMD released last month here. (I have not updated as I don't yet have WIndows access.)

I'm still having issues with TB: I'll work on more tomorrow. Tonight, the extra DDR4 finally arrived, so total is now 128GB running XMP. I also switched out the Vega 56 for a Radeon VII... so tonight I I ran tests. The Radeon VII benefits from a modified CMMChris kext and DevProperty SoftPowerPlayTable injection (and I disable WEG as it does not play nicely with the Radeon VII---at least on the Z390 buld). GeekBench-4: CPU, OpenCL and Metal LuxMark v3.1: GPU and GPU+CPU Cinebench-15 Cinebench-20 Corona *** Attached is the CMMChris kext file used for the above tests. This kext file also inject AGPM and works with almost all AMD GPUs (see internal info.plist file). And in below Spoiler is OpenCore DeviceProperties code for speeding up the Radeon VII as well as keeping voltages as low as practical. The code also populates the Syst-Info/PCI section. Do note, however, that the PCIRoot(...) address will need changing for any other mobo. Use Hackintool' to determine for your mobo if different and ProperTree to copy and paste. RadeonBoost-v1-4.kext.zip