iGPU
-
Posts
573 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Events
Downloads
Everything posted by iGPU
-
I kept getting odd freezes, so I went ahead and replaced the CPU. The new CPU seems to be working well. I also updated the BIOS (thanks fabiosun for pointing it out). One set of SATA has been passed. It seems that SATA ports 4-5-6 are assigned to address 49:00.0, while the lower numbered group, SATA 1-2-3, are assigned to 4a:00.0 (which comes after 49:00.0): so the addresses are reversed to the SATA numbering. fabiosun, I recall you asking us to provide DSDT files from bare metal and VM for comparison. Attached are mine for the MSI-TRX40-Creator. These are now easily made, starting with final release of OpenCore v059, using the Debug version. DSDT-MSI-Creator.zip
-
I had problems with the Aquantia not accepting DHCP. My network is based on 192.168.x.x and it would come up with odd-ball 192.247.x.x. When I assigned it manually, it wouldn't stick or else it wouldn't connect. The I211 works without any issues.
-
The Realtek 2.5Gigabit Ethernet port is different than most TRX40 mobos. Did you say earlier that you got this kext from PAVO? This is the first that I've heard of 2.5GB devices working on Hackintoshes. Many TRX40s seem to use the Intel I211 (1 GB) or the Aquantia AQC107 10 GB devices. The Aquantia is natively supported in Mac; the Intell I211 needs the SmallTree82576 kext. The Realtek kext doesn't work with either of these Ethernet devices.
-
03:00.0 PCI bridge [0604]: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] [104c:823e] (rev 01) 04:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] [104c:823f] (rev 01) Subsystem: Device [3412:7856] Kernel driver in use: firewire_ohci Kernel modules: firewire_ohci I see no other style FireWire cards to order... Every single one has the Cheetah bridge.
-
Driftwood, I got the same model StarTech FireWire card as you use. However, it too generates a bridge and is unusable in macOS. I give up (I now have so many FireWire cards...). I truly do not understand how you have no bridge appearing, unless the bridge issue is unique to mobos, and we do have different mobos. But this doesn't quite make sense as I thought most of the mobo behavior is dictated by the chip, in our case, the TRX40. Nevertheless, as long as a bridge shows up on a PCIe device, we cannot pass that device via VM (and to repeat what I've posted earlier, this seems to be the reason that Thunderbolt cards cannot be passed). If I understand correctly (but I may not be), some of the things being written about the latest Linux kernels, indicate that Linux may soon support the passing of bridges. But Proxmox seems to be a year or so behind using the latest kernels. (This makes me want see if I can get a VM working in AcroLinux.)
-
I'm using a swapped BT/Wfi card. I do pass 48:00.1 and 48:00.3. I too had all sorts of trouble with the Aquantia, so I ended up leaving it for the host and passing the Intel I211 and using the usual SmallTree kext. But I thought my problem may have been because I initially ran WIndows 10 and I updated various drivers. From old posts about Aquantia (I think dating from 2017 or thereabouts, when Sierra (High?) began supporting Aquantia), there were indications that once WIndows wrote a driver to the Aquantia chip, it wouldn't work under macOS. But that if you used macOS up until Mojave 10.14.3, macOS could write to the Aquantia chip (but then Aquantia wouldn't work under WIndows). So I don't know if the Aquantia problem I had is related to having written a WIndows driver to it or some other glitch. Anyhow, I don't have a 10G Ethernet system, so I'm content with the I211 port working.
-
fabiosun, I was wondering if passing the entire CPU might be a problem in general for audio. When you have audio problems with High Sierra, did you ever try only passing 62 threads instead of passing all 64 to VM (that is, leaving 2 for the host)? Why I ask, is that on UnRAID, it is expected to leave at least 2 threads for the host. In fact, UnRAID recommends specifically leaving CPU 0 and whichever thread is paired with 0 (such as 0 and 31) for the host. In reading about Proxmox, most of what I've read seems to suggest also leaving some threads for the host, so maybe we shouldn't be passing the entire CPU.
-
I bought 256GB of this DDR4, and it seems to work well.
-
I've tried 3 different FireWire cards (one Startech): 2 with 400/800 and 1 with dual 800. None work as they all have bridges. Driftwood, I located the one you posted here. Thanks.
-
Can you tell us which model of Startech you're using? I believe you described using a model with dual 800 ports. However, Startech does not have any dual 800 devices on their website nor are any sold at Amazon US. Amazon does have Startech with 1-400 and dual 800 (which I've already tried), but any devices with a 400/800 combo has an internal bridge and probably won't work as a pass-through. I ordered one non-Startech device with dual 800 but it's not yet arrived, so I cannot vouch for its quality or functionality.
-
I've finally re-established stability, and it's using the same CPU (which I believe had it's microcode re-written by ArcoLinux <-- thank-you!). Both Radeon VIIs were passed, and today computer has run for 12 hours without any problems. I did inactivate sleep by adjusting Energy Saver (which doesn't work anyway on most Hackintoshes). See Spoiler below. This image was sent to my laptop via AirDrop which works on this build with swapped BT/WiFi card. However, I needed to pass 48:00.3 which powers BT. Without specifically passing 48:00.3, BT did not work. Below is the rear panel for MSI Creator. MSI TRX40 Creator mobo (previously posted here😞 Basically, passing 48:00.3 covers most of the internal ports and rear panel. 48:00.3 must be passed if using a swapped BT/WiFi card, or else there is no USB to power the BT component. 48:00.1 covers the 4-stack and has interwoven, according to IORegistryExplorer, the ASM107 device. So while ASMedia specifically controls the USB-C port, it also is somehow involved with 48:00.1 in the 4-stack ports. The references to XHC and XHCI are from my custom SSDT file. The 10,3 and 10,4 are device locations as reported by IORegistryExplorer. Proxmox is located at 43:00.0 on an NVMe drive, which, of course, is not passed. The MSI Creator mobo has 3 NVMe slots. What are passed in the VM are the following (no SATAs to date, but they're coming, described here😞 VM:
-
I did a fresh install of Catalina (no data migration) on the Sabrent Rocket drive. It is now working well. So the macOS problem was due to having recently did a fresh install, but then a migration of data. The migration can bring instability of macOS, so not a good idea if there is a question of instability. But now I'm at work (my schedule this week returns to usual hours since lock-down), so no more testing until later tonightl. In summary there are at least two separate problems: 1) macOS - solved with fresh installation without migration. 2) CPU issues a) seemingly resolved since doing a separate drive install of ArcoLinux, which possibly flashed AMD microcode to CPU. b) maybe mobo problems related to microcode (if true, then GB Designare mobo was prob okay, but now returned). c) no more errors reported in Proxmox since ArcoLinux install. All testing with new Proxmox install/new Catalina install is done as mentioned in my previous posts using console and not passing GPU. Other items passed are two NVMe drives, BT/Wifi, Aquantia, ASMedia at 44:00 and Matisse USB at 48:00. Tonight I'll pass both GPUs. Instructions on most TRX40 mobos are slots 1 & 3 (as these are the x16 pcie slots) and then monitor for stability.
-
I'm still perplexed by the computer behavior. After running ArcoLinux (I tried to get a VM going, but not so easy), I went back and did another install of Proxmox 6.2. It is now running and stable. What changed? As I mentioned above, during install of ArcoLinux, it had option to install AMD microcode. I assumed that this was a software add-on, but now I wondering if ArcoLinux injected the CPU with microcode, and that updated microcode is allowing the CPU to work again with Prxomox. I ran Proxmox overnight, no errors were on host screen, and macOS still running (having timed-out and presented me with re-login screen). Meanwhile, MSI has not yet updated BIOS for TRX40 Creator mobo as they did for PRO 10G. So while the CPU is working better with Proxmox, macOS is not stable, but I think another issue. If any apps are run (Safari, Hackintool, etc), the OS freezes after a few minutes; and this is running under console, no GPU pass-thru. I will do a fresh install of Catalina and see how that behaves.
-
I spent most of yesterday trying to get various Linux distros to install (Redhat, Mint, et al). They all crashed during install (to a new SATA SSD). I finally got ArcoLinux to install. I then ran it all night. Completely stable, just like Windows 10 on the problematic CPU (replacement has not yet arrived). ArcoLinux is based on Arch Linux (which is what I referenced in above post as being the latest, but it is very difficult to install). ArcoLinux has almost the latest Linux kernel, like Arch Linux. During installation ArcoLinux asks if you want to install microcode for Intel or AMD. I chose to install for AMD (? version). I don't know if just because the latest Linux kernel, that supports latest equipment, or if the AMD microcode helps, but in any event, this Linux machine is stable. What I still don't understand is why my particular CPU was originally working on Proxmox but then gradually became unstable to the point that I couldn't run Proxmox (and I've tried their latest v6.2). Now, I'm looking into adding KVM and QEMU to ArcoLinux.
-
Following comments are FYI and have no immediate direct bearing on this build. I'm researching various Linux distributions and came across this news: Linus Torvalds has switched to using an MSI TRX40 Creator + 3970X, where the build is described here. Linus describes here using Linux 5.7-rc7. This all would suggest that the TRX40 platform will have increasingly better Linux support. I left Windows 10 running over night and zero issues, even after running many different stress tests. That led me to look for issues affecting Linux but not Windows: Core 6 issues can do this. But after making those changes described here in BIOS (changing 'Typical current idle', from 'Auto' or 'Low current idle'), the same error messages and kernel panel with shutdown happened under Proxmox. So no fix for my CPU.
-
First, I should get my system working better. I tested more tonight and under Windows 10 everything seems fine. I stress tested and temps never got over 75°C (I did not yet run Prime95). It runs without crashing. But under UnRAID or Proxmox, system crashes with same, repeatable errors in 5 min or so. Something about Linux and this CPU. I'll run other Linux tests tomorrow. Fabiosun, when you used to use MCE=off, did you place that in GRUB_CMDLINE_LINUX_DEFAULT, or somewhere else? Thanks.
-
I have no idea how to modify a kernel. Are there instructions? Or is it part of PAVO's site to download?
-
Questions: 1. can you pass a command line flr patch, like "pcie_no_flr=1022:148c", or must it be a new kernel? If a command line, is this placed into GRUB_CMDLINE_LINUX_DEFAULT? 2. PAVO's site is for the X570; are modifications needed from his download for the TRX40?
-
Yes, this is completely based on the data set up by VFIO-PCI-Config plugin, where ASM1074 High Speed hub is somehow tied in with Matisse. It would be interesting to see how this plugin affects other mobos. But setting up UnRAID is more awkward than Proxmox, so probably not worth the effort for most users if Proxmox is working.
-
Done. I added to same post at bottom.
-
More on USB Mapping. UnRAID has a good tool (plugin) called VFIO-PCI CFG. When run, it isolates IOMMU groups and allows you to click on a given group to create a pass-through, then after saving the selections, it creates the pass-through file for you, which is then available after a re-boot. VFIO Plugin When I plug different devices into the MSI Creator mobo, I find there is a 'blending' of USB controllers. This may explain the erratic behavior based on what is passed. The spoilers below allowed me to create the rear panel annotation at bottom. I think we're starting to see a pattern of what is passed. The audio USB connectors are Matisse USB from 48:00.x. But notice how, on my mobo, that 48:00.1 is shared with the USB-3 below the Aquantia port as well as those in the middle stack of USB ports. Meanwhile, 48:00.3 is used for the internal USB-3 connectors (often for front panel use), along with supplying USB power for the BT (I swapped out the BT/Wifi module). Surprisingly, the USB-C is ASMedia at 44:00.0, while the USB ports at the left (which I use for keyboard and mouse) come from 25:00.3. To make things more confusing, if you look at the spoiler below, at Matisse at 48:00, you'll see there is a blending of ASMedia High Speed. (Highlighted green in spoiler for 48:00.1.) This mix appears associated with drives to 48:00.3 and the ASMedia port 44:00.0. Bottom line for this mobo, is that to have full USB functionality, 25:00.3, 48:00.1, 48:00.3 and 44:00.0 must be passed. (I think 4:00.3 are the ports beneath I211, but I need to re-check this.) MSI TRX40 Creator: Basically, passing 48:00.3 covers most of the internal ports and rear panel. 48:00.3 must be passed if using a swapped BT/WiFi card, or else there is no USB to power the BT component. 48:00.1 covers the 4-stack and has interwoven, according to IORegistryExplorer, the ASM107 device. So while ASMedia specifically controls the USB-C port, it also is somehow involved with 48:00.1 in the 4-stack ports. The references to XHC and XHCI are from my custom SSDT file. The 10,3 and 10,4 are device locations as reported by IORegistryExplorer. lspci -nnk
-
Thanks, I think there's no heat problem. I've initially monitored temps in Windows and saw typical temps at idle of 35 to 38°C. Those temps jumped to less than 90° (based on audible feedback discussed below) when testing in macOS. I'm using (as in Signature), an Enermax Liqtch 360 which has a plate designed for Threadripper. They have a bad rep, so on purchase, I completely dismantled, flushed the radiator, smoothed the innards of the motor housing (due to burrs) and re-filled with anti-corrosion fluid. Then I lapped the base of the copper plate as it was far from flat. It took me almost 90 min of wet-sanding to get it flat (see spoilers). Because of the lapping and large heat sink size, I think there is very good heat transfer. I've adjusted fans speeds in BIOS, which are rather flat until 65°C and then gradually ramp up. This gives me an audible indicator of temps. There is another ramp up at ~80°C and then everything (fans and pump) goes to 100% (loud) above 90°C. After 30 min (surface still irregular): After 90 min (critical central area is evenly flat):
-
I've been running UnRAID (not a successful macOS VM, but I can run a Win10 VM). If I study the log files, all looks good until the end of the log (see spoiler; only shows ~ last 5% of the log). UnRAID is being run from a different drive (a smaller 256GB NVMe; UnRAID boots from a USB stick, so the combo is used). This eliminates a concern I had regarding the Samsung SSD SATA drive used to store Proxmox. The drive is most likely just fine. Basically, the UnRAID log shows the same error at the same CPU positions: 17 and 49. This suggests that Linux is picking up on a consistent error at a consistent location within the CPU. UnRAID, unlike Windows 10 which I ran as bare metal, crashed. So same behavior with Linux-based UnRAID and Proxmox. WIndows 10 does not report, to my knowledge, any CPU anomalies. I've checked GPU-Z in Windows and it seems to report all is okay. So two Linux systems report CPU problems; one crashes. It seems there is a problem with the CPU.
-
I tried an old Windows 10 NVMe drive that I move between computers, and it booted and ran just fine. I left it on for a couple of hours over dinner. No crash. So why is suddenly Proxmox creating problems? Today I used 6.1 and tonight I tried 6.2 --- all crash while I'm trying to get the VM files edited and ready to go. And I'm doing fresh installs. Hmmm... all the installs are on the same Samsung SATA SSD (its a new 500GB drive). I'll try installing on a different drive. I'll also test UnRAID. I have a test set up for it. I'll also install another flavor of Linux like Mint or Elementary to see how it behaves. I have a few days before replacement comes. If this CPU is okay, I will keep and return the other one, unopened.
-
In follow up, I transferred the 3970X to a new MSI Creator. Things looked really good (although, this is my first MSI product and BIOS rather different than ASUS and GB and ASRock). But after 30 min, the same error codes began. Exact same error codes and then it crashed. So I have a bad CPU. Interestingly, it started out okay, but then gradually got worse and worse. Fortunately, I had 3 days left to do an exchange, so I'll get a replacement 3970X next week.
