iGPU

24 minutes ago, fabiosun said:

and also it seems disabled 🙂

 

Yes, that too.

Also change the DevProp LAN injection to the attached data. I've added the "device ID" info, which id 0x1533 (in reverse byte order) for I210.

And I have a different patch for you to try.

Arrakis-DevProp.plist.zip

Arrakis-kernel patches 11.4.plist.zip

On 5/17/2021 at 12:25 AM, Arrakis said:

@iGPU Merci beaucoup pour l'excellente recherche.😃

 

This is a great lead, for sure my problem is there. I remember in the multitude of backtrace kernel reports related to IONetworkingFamily.

From the start I suspected this issue related to the IONetworkingFamily car kext in BigSur 11.4. beta 3 the wrong kext is loaded (see capture, AppleEthernetE1000.dext....)

I will do the test at the end of the week as I am in production until Friday.

I have looked in the OpenCore documentation (Page 25) this handles issues related to ONetworkingFamily and IOAudioFamily.

Here are the values in my current config.plist.

Your setting shown above won't work as your MaxKernel is 13.99.99.

You must change this to 20.99.99 and the MinKernel to 20.0.3 or 20.0.4

@Arrakis 

I've found one more thing for you to try. 

I must have too much time on my hands; I was going through each entry in OC and came across this "Force" example provided by the OC developers. It 'forces' IONetworkingFamily! This is the main kext file in which is located the plugin AppleIntelI2210Ethernet.kext.

If you look under your Kernel/Force/0 entry you will probably see it. If not, then open the Sample.plist file inside the Docs folder and copy and paste it into your config.plist file. Do remember to enable and change the MaxKernel, MinKernel to the values I've shown below.

51 minutes ago, Arrakis said:

@Ploddles 

I didn’t use the terminal command but went directly to the folder.

The "NetworkInterfaces.plist" file does not exist ....! It is worth saying that it was never created. For which reason …..?

I rather doubt that OC is to blame. Your NIC I210 problem seems more like a Big Sur 11.4 beta issue, and will require future releases to fix.

The latest v070 commit adds a folder name Acidanthera to Resources/Image. If this is not present, you'll only see the text based OC bootloader instead of OpenCanopy's graphic display. I've attached the folder to this post (Acidanthera-orginal.zip).

WIthin this folder are 3 others: Chardonnay, GoldenGate and Syrah. Chardonnay will the "Old Icon" (10.4 stye) folder, GoldenGate is the Default. Syrah will store the dark/black images, while Chardonnay will store the lighter colored images.

The Docs are a little confusing about these definitions. There is no mention of the "Modern-" and "Old-" icons which are still present in the main "Image" folder.

The documentation says:

UPDATE:

Yes, the items outside of the Acidanthera folder are ignored. So the structure below works just fine.

The original attachment is the stock folder. The second attachment (Acidanthera-modified.zip) is one I use with some darker images inside the GoldenGate & Syrah folders. I placed the "Modern-" images inside the GoldenGate folder and the "Old-" images inside the Chardonnay folder. This modified folder works as expected when Misc/Boot/PickerVariant is set to Auto.

Acidanthera-modified.zip

Acidanthera-orginal.zip

2 hours ago, Arrakis said:

@iGPU 

Approach n ° 1 : Doesn't work for I210 (no internet connection) and I already had DisableWatchDog enable from the start.

Approach n ° 2: Does not work for the I210 (no internet connection) but I will keep the SSDT-TRX40-USBX)

Approach n ° 3: Does not work for the I210 (no internet connection)

Approach N ° 4: Prevents the system from starting, stays on the beginning of the loading stuck eternally on the apple.

 

I did the 1,2,3,4 tests with the SSDT-EC-USBX-DESKTOP.aml and / or the SSDT-TRX40-USBX.aml) as well as the I210 Device Properties enabled or disabled.

This makes a number of test….

I even did a clean instal 11.3.1 then update to 11.4.beta 3.

The installation is absolutely problem-free with my EFI. I just changed a DSDT. I kept the SSDT-TRX40-USBX.aml.

I don't get a PCI card placement errors message the first time I log in (I don't use Kext restrict events).

And still no ethernet connection. The Wifi module works as before.

From the moment I start to order the ports for example, it is unstable. (Kernel panic….)

 

I keep the patch and the pci properties of the I210 as it works as you can see. (Screenshot)

I will wait for the next beta and the new version of OpenCore to redo the tests

I saturate and I am a little annoyed ...😞

I'm sorry to hear this, but now I'm beginning to wonder about your actual internet connection. The fact that the drivers are reported being loaded on the PCI window makes me think the ports are active.

Am I understanding that if you run an older version of OC, your ports are active, but from (what?) v069 onwards there is no activity? If you create a new EFI with the same kexts/dev prop we just worked on and run under v068, it all works?

Some more questions.

Are there any LEDs on at the RJ45 jacks on the rear panel of your mobo?

Do you have other ethernet cables to try? Are you going through a switch? Is the switch working (powered up, etc; I've had them go bad)?

Can you directly run an ethernet cable from the rear of the mobo to your modem/router?

To help with trouble shooting, there is an Apple utility (Network Utility) that is useful. Unfortunately, Network Utility was dropped for Big Sur. But fortunately, it can be extracted from Catalina. The Catalina version runs just fine under Big Sur. I'll attach a copy to save you digging around for it. (On new installs, Big Sur removes it (I've variably installed in the Application or Utility folders, but hiding it in the Download folder seems best.)

If you run it, it will show you packet transmission information. Below is mine for the I210 port. The one for the Aquantia port is similar (I run 2 cables back to my router). You should be able to see something like this.

Network Utility.app.zip

I posted some results on the GPU testing thread here, using Octane X.

They are as good as the revised Davinci tests I've run and posted on the same thread.

I've done some other testing using Octane (downloadable from App Store, here). You may have to sign up (register with OTOY) for a free download.

On the Octane (OTOY) forum, there is some discussion of testing with 6900XTs here. You may need to register on their forum to gain access.

When I run Octane X, I get 7 sec for the 6900XT (although my GPU is constantly listed as an unknown, "AMD Radeon HD GF10 Family Unknown Prototype"). The fastest run was 6 sec; slowest was 8 sec; avg = 7 sec (4G is disabled; ResizableBar is enabled).

Details from above image:

Their tabulated results would imply that this is actually pretty good. The Radeon VII gives about 19 sec (although, if the 6900XT on my setup is getting 7 sec or 4 sec faster than on their plot below, perhaps the Radeon VII would also be about 4 sec faster, or 15 sec on my setup) if the differences are linear.

The RTX-3080 got 8 sec, 3 sec faster than the 6900XT, so maybe 4-5 sec on my setup, assuming linearity. The 3090 is reported on some posts to get 7 sec under Linux with many scenes comparably rendered between the 3090 and the 6900; but on some renders, the 3090 is much faster than the 6900, so the results are scene dependent.

4 minutes ago, Arrakis said:

@iGPU I misspoke my question, what tool do you use to insert into the config.plist ?

PlistEdit Pro is the editor I use; attached.

Or try this one here (OCAT_Mac.dmg)

PlistEdit Pro.app.zip

30 minutes ago, Arrakis said:

@iGPU how to create a patch kext.  ?  to inject the code to test 3.

I created the patch. If's in one of the Spoiler sections above (please look at all of the Spoiler sections!)

You simply copy from Spoiler and paste into your config.plist file:

Candle Benchmark in DR v17.2 with one AMD 6900XT, using Metal setting. Same results with or without WEG.

I also repeated, with same results, ±4G. When 4G was disabled, I tested with ResizableBar enabled; again same results. (BTW, it is not possible, at least with my mobo, to boot with both 4G and ResizableBar enabled.)

18 @ 66 nodes; 23 @ 6 nodes.

UDPATE:

The above results are incorrect. It now shows the following (4G disabled; Resizablebar enabled):

30 @ 66 nodes; 40 @ 6 nodes.

The difference is a patch I'd left engaged for the first set of results. I'd left it enabled (and just remembered this morning), as I didn't see an issue using it with the Radeon VIIs. If you enable this patch, your results are reduced by ~ 50% !!

The patch does not have any influence on the Octane X results discussed in the next post.

I updated my above post regarding 6900XT noise.

It is now better and should further improve with some more changes.

40 minutes ago, A23SS4NDRO said:

XD

 

seriously, do you mind to tell the price?

1600 USD.

(But I'm still waiting for refund from eBay for the 1300 I spent for 1st 6900XT that seems now to have been from a scammer.)

1 hour ago, A23SS4NDRO said:

How many kidneys did it cost?

Both, but they threw in a free dialysis unit.

On 5/13/2021 at 10:59 PM, fabiosun said:

@iGPU thank you

in 66 nodes condition dual radeon VII rig is about 8% faster than a single 6900 xt at this drivers development stage..

so i can say it is worth to update to big Navi 2

The one annoyance I'm seeing (hearing), is noise coming through my USB audio interface (and this is with the interface muted).

If nothing on the computer is used, the speakers are quiet. If I scroll a window, I get a noise proportional to the amount of scroll. If I run a GPU test, the noise gets louder, disappearing once the test is complete. I did not have this with the Radeon VIIs or the RX580. I dislike hums and buzzes in my audio systems. It reminds me of the occasional Vega 64 coil whine, but this is worse.

If this doesn't improved, I'll sell the 6900XT. I'd rather have a slow, quiet GPU than a fast, noisy one.

UPDATE:

Better. I was lazy on 1st install and only connected 2 power supply (PS) cables with a jumper from one of these for the 3rd PS jack.

Today, I installed a 3rd PCIe PS cable for the GPU, and noise is reduced (not zero, but close enough). The reason to add 3 discrete PS cables rather than use a jumper from one cable is to minimize PS sag. While the new AMD GPUs are more efficient, they require a lot of power under load and this can lead to sag. When the PS sags, it can modulate the PS coils on the GPU, leading to buzz and other noises.

In the next day or two, I'll be adding some ferrite collars around the USB cables: one simple clamp on (high freq block) and at the other end, a loop clamp on (lower freq block). Hopefully that will eliminate most all noise. Another option I may try out is a USB filter (they come in various plug shaped combinations).

2nd UPDATE (5/15/21):

Neither the ferrite beads nor the USB filter worked to remove the noise.

What did work was an isolation transformer (here; these are rather expensive due to the high quality Jensen transformers, fortunately I already had one from another project). All became quiet once the transformer was placed between the output jacks of the USB Audio Interface and the speakers. This fix suggests that there is a ground loop somewhere in the computer/GPU/PS section that the GPU is modulating.

6 hours ago, fabiosun said:

have you tried Candle Davinci benchmark with your dual radeon rig?

Could be interesting to compare with your new GPU

 

Yes, I posted the dual Radeon VII results back on 9/9/21, here with an early version of BS beta. (The debate at the time was if bare metal was as good as VM.)

18 hours ago, Arrakis said:

@iGPU

I have proceeded in order of suggestion.

 1. I have disabled iommu in the bios (deactivation does not modify the MMIO) which I will keep like that anyway: identical problem, kernel panic or freeze, no recognition of the Intel I210 module.

2. Addition of the codes in Device / Properties: identical problem, kernel panic or freeze, recognition of the Intel I210 module but inactive. (Capture 1)

3. Addition of the SmallTreeIntel82576 kext: identical problem, panic or freeze kernel, recognition of the Intel I210 module but inactive. (Capture 1)

4. Deactivation of the codes in Device / Properties: identical problem, kernel panic or freeze, no recognition of the Intel I210 module but inactive. (Capture 1)

5. Wake on Lan has been disabled since the start of my hack.

 

I still don't understand why the system is loading the wrong kext in the wrong folder. While this Intel I210 is present in the kext of the IONetworkingFamily system (Capture 2)

Why does the system choose this AppleEthernet1000 module?

 

@Arrakis

Ok, some more approaches...

1) First try one more kext (attached). This one (SmallTreeIntel82576_mod.kext), I'd modified in 2019 (it works with I211 and with I210), adding a 'root' ending to the Info.plist file that was missing from original and would give an occasional panic without.

Also, have you set the following in red box to "Yes" (it might help):

2) Are you injecting a DSDT or SSDT that might be interfering? Specifically, I'm wondering what is inside your "SSDT-EC-USBX-DESKTOP.aml". It is possible that the 'DESKTOP' portion is a DSDT extract that may be giving you grief. Instead of enabling this aml file, disable it and use the one attached below (SSDT-TRX40-USBX.aml).

BTW, if you want to get a summary of all loaded, non-Apple kext files, enter the following into Terminal:

Kextstat | grep -v com.apple

My results are in Spoiler below:

3) The next approach is to create a kext patch. Try the attached code shown in the Spoiler below, if the above SSDT swap does not work.

			<dict>
				<key>Arch</key>
				<string>Any</string>
				<key>Base</key>
				<string></string>
				<key>Comment</key>
				<string>I210 Big Sur</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>
				YnVpbHQtaW4=
				</data>
				<key>Identifier</key>
				<string>com.apple.driver.AppleIntelI210Ethernet</string>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data>
				</data>
				<key>MaxKernel</key>
				<string>20.99.99</string>
				<key>MinKernel</key>
				<string>20.0.3</string>
				<key>Replace</key>
				<data>
				YmJiYmJiYmI=
				</data>
				<key>ReplaceMask</key>
				<data>
				</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>

4) Finally, what about trying to inject AppleIntelI210Ethernet.kext? Attached is one I extracted from the latest Big Sur beta. If you use this, I'd try with and without the SmallTree82576 kext enabled, listing the SmallTree after AppleIntelI210Ethernet kext as in Spoiler.

			<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>BundlePath</key>
				<string>AppleIntelI210Ethernet.kext</string>
				<key>Comment</key>
				<string>Intel I210</string>
				<key>Enabled</key>
				<true/>
				<key>ExecutablePath</key>
				<string>Contents/MacOS/AppleIntelI210Ethernet</string>
				<key>MaxKernel</key>
				<string>20.99.99</string>
				<key>MinKernel</key>
				<string>20.0.3</string>
				<key>PlistPath</key>
				<string>Contents/Info.plist</string>
			</dict>
			<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>BundlePath</key>
				<string>SmallTreeIntel82576_mod.kext</string>
				<key>Comment</key>
				<string>Intel I211 LAN Patches</string>
				<key>Enabled</key>
				<true/>
				<key>ExecutablePath</key>
				<string>Contents/MacOS/SmallTreeIntel82576</string>
				<key>MaxKernel</key>
				<string>20.99.99</string>
				<key>MinKernel</key>
				<string>18.0.0</string>
				<key>PlistPath</key>
				<string>Contents/Info.plist</string>
			</dict>

In any of these situations, you can probably still use the Device/Properties stuff I uploaded earlier. In fact, in Comet Lake mobos, AppleIntelI210Ethernet can have a kernel panic that is only resolved with a DeviceProperties injection (see here).

Also, remember to try re-setting NVRAM.

***

If the I210 works, you should see sometime like I see for I211:

SDDT-TRX40-USBX.aml.zipSmallTreeIntel82576_mod.kext.zip

AppleIntelI210Ethernet.kext.zip

1 hour ago, fabiosun said:

I am using release version and without RestricEvents kext no problem

it is difficult to track this..maybe an OSX beta bug or bootloader stuff

i do not know for now 🙂

Happy of your 6900xt? 🙂

 

I've only done minimal testing (and I've left on "silent", not "OC", mode). The GPU is so far a bit underwhelming: LuxMark not much better than the Radeon VII results (and the PowerColor 6900XT takes up 3 slots!, so dual cards not possible). Since I never game (I've never seen a purpose in  playing computer or board games; my life is too busy), the 6900XT may not a benefit for my build. But I'll test some more. DaVinci will be interesting (as I actually use it), to see if one 6900XT is close to my old dual Radeon VII set up.

11 minutes ago, A23SS4NDRO said:

Just curious, where did you get that?

The 6900XT? eBay.

10 minutes ago, fabiosun said:

@iGPUlatest OC and kext version?

 

Yes, I use latest OC commits from here (presently booting with v070, 4cdd360. I update daily (sometimes more often ).

I also run ocvalidate (inside OC/Utilities/ocvalidate folder) on current config.plist file to ensure there are no errors; sometimes the docs are behind and ocvalidate will pick up structural changes. Each commit has an updated ocvalidate, so you must use the latest version of ocvalidate to avoid mistakes.

The RestrictEvents is also latest (use pop-up box at upper left to navigate amongst the various kexts): here.

I've left the computer on for ~14 hours with no crash or reboot with new 6900XT GPU, using 11.4 Beta (20F5065a). 

RestrictEvents was enabled; using MacPro7,1 SMBIOS. So, I'm not certain what led to previous reboots.

7 hours ago, Arrakis said:

@iGPU 

Here is the .txt file of the PCI implementation. There is no improvement under Big Sur 11.4. beta 3 with your SmallTreeIntel82576-I211.kext for the ethernet module.

I attach the config.plist of my current setup which works fine on Big Sur 11.3.1.

PCI DEVICES ARRAKIS.zip 13.72 kB · 1 download config arrakis.plist.zip 6.83 kB · 0 downloads

Try adding the code below into your Device/Properties section to see if that helps. (You should try this ± SmallTreeIntel82576 kext.)

From the pcidevices list, I see that you have IOMMU enabled. This is required for VM, but not bare metal. I keep it disabled. I don't know if this would have any influence on LAN behavior; I've never checked. Disabling it might affect MMIOWhitelist. Also in BIOS, do you have Wake on LAN disabled?

            <key>PciRoot(0x2)/Pci(0x1,0x1)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)</key>
			<dict>
				<key>AAPL,slot-name</key>
				<string>Built in</string>
				<key>built-in</key>
				<data>
				AA==
				</data>
				<key>device_type</key>
				<string>Ethernet Controller</string>
				<key>model</key>
				<string>Intel I210 Gigabit Network Connection</string>
				<key>name</key>
				<string>Intel I210 Ethernet</string>
			</dict>
			<key>PciRoot(0x2)/Pci(0x1,0x1)/Pci(0x0,0x0)/Pci(0x5,0x0)/Pci(0x0,0x0)</key>
			<dict>
				<key>AAPL,slot-name</key>
				<string>Built in</string>
				<key>built-in</key>
				<data>
				AA==
				</data>
				<key>device_type</key>
				<string>Ethernet Controller</string>
				<key>model</key>
				<string>Intel I210 Gigabit Network Connection</string>
				<key>name</key>
				<string>Intel I210 Ethernet</string>
			</dict>

6900XT working, using WEG with boot-arg. RestrictEvents left active; will leave on and see if stable.

@Arrakis

I looked at the LAN section of your IORE file (BTW, the TB  section is PERFECT!):

Was the IORE file without a LAN kext? It looks good as is (and maybe needs a DeviceProperties injection).

If a kext was used and the LAN was not working, then maybe try the one I've attached.

Also, can you upload the txt or plist file from Hackintool for the PCI section for your mobo? If you do, I can work up a DeviceProperties injection for you to maybe enable better LAN functionality.

SmallTreeIntel82576-I211.kext.zip

1 hour ago, Arrakis said:

@iGPU And there you have it, there is work to do this weekend. Merci beaucoup Gigabyte Designare TRX40 REV 1.1 Arrakis .zip

Got it (and the GPU)!

So I'll work on this tonight too:

45 minutes ago, fabiosun said:

I have removed only the kext..system is stable...no weird reboot for now

let we see 🙂

 

Lately, I've been shutting down the computer at night as I've not had any stability issues to study. However, I left computer on last night (running latest beta 4 and with RestrictEvents enabled) and this morning the computer was off. On restart, I got a macOS warning of a crash, so I seemed to have had a shutdown over night. 

The Memory section does not add to any stability problems; I checked that last week (and it's part of OC, not RestrictEvents). It sounds like RestrictEvents is the cuilprit.

I'm at work now but I'll study later tonight to see if I get a shutdown again, but it must have happened a few hours into the boot, so it might take some time to sort out. (Today the 6900XT is scheduled to arrive and it I exchange the GPU, that might add to any stability issues.)