Ethernet works via usb c adapter but not via dedicated port about gigabyte-z590i-vision-d-11900k

[arhoj]

BCM94360NG should work out of the box. Is it a FENVI card?

i225-v is more fickle. What does system info list under Ethernet? Ventura should work using AppleIntelI210Ethernet.kext with boot-arg e1000=0, VT-d enabled and DMAR table delete.

Sonoma seems to have broken this method, I haven't tested myself yet as I'm still on 13.5.1, but macpato82 says AppleIGC.kext should work in this case

[ramseysparrow]

Hey there @arhoj , kind thanks for assist.

I have the network adapter swopped over for the fenvi BCM94360NG, while ethernet card is mobo's default, so must be i225-v indeed – both being like Chris' build exactly.

I'm using Chris' original EFI and so AppleIntelI210Ethernet.kext is there, though I don't know about the [boot-arg e1000=0, VT-d enabled and DMAR table delete] part. I have only hackintoshed the machine for the first time very recently and so straight to Ventura 13.5.1: I wander if that could be the issue (ie outdated drivers)?
Chris built and tested up until Monterey / Ventura beta 5.

Here's what the Ethernet lists:

I210:

Bus: PCI
Vendor ID: 0x8086
Device ID: 0x15f3
Subsystem Vendor ID: 0x1458
Subsystem ID: 0xe000
Revision ID: 0x0003
PCIe Link Speed: 5.0 GT/s
PCIe Link Width: x1
Driver: com.apple.driver.AppleIntelI210Ethernet
BSD Device Name: en0
MAC Address: 18:c0:4d:ea:12:08
AVB Support: No
Maximum Link Speed: 2.5 Gb/s

USB 10/100/1000 LAN:
(this must be the thunderbolt adapter through which I successfully use ethernet)

Bus: USB
Vendor Name: Realtek
Product Name: USB 10/100/1000 LAN
Vendor ID: 0x0bda
Product ID: 0x8153
USB Link Speed: Up to 5 Gb/s
Driver: com.apple.DriverKit.AppleUserECM
BSD Device Name: en2
MAC Address: 00:e0:4d:6d:37:2f
AVB Support: No

[arhoj]

No problem @ramseysparrow, happy to help.

How familiar are you with OpenCore? I'm sure you're aware of it already but I'd suggest having a good read of the Dortania guide to ensure you understand how the process works – understanding how OC functions is key to fixing any issues that may arise in future.

I've edited Schmock's latest 0.9.3 EFI to use the new IGC kext for i225 here: IGC_EFI.zip

Use ProperTree to add your SMBIOS info, compare the changes of the two side-by-side and add any settings you've changed previously (if any).

I've removed the Atheros 10GbE adaptors under Kernel>Patches as you don't need these in your setup.

You can see the DMAR edits under:

ACPI>Add>10 #Edited SSDT-DMAR.aml
ACPI>Delete>0 #Removes default values for the system DMAR

This allows you to enable VT-d in your BIOS (virtualization), which is needed to run the InteIGC.kext under MacOS.

Finally, prep a USB drive with the new EFI to test, and keep your boot drive EFI the same as a fallback.
Unplug the Realtek and have your ethernet connected to the i225 before booting.

Good luck!

[ramseysparrow]

You're a legend, one final time - thank you.

This is my first Hackintosh, native Macs till now. I did due diligence with Dortania and other sources though – enough to manage the entire installation without a single hitch on first attempt, almost suspiciously so.

That said, some bits remain a tad esoteric to me, between my lack of experience and some of Dortania's instructions being a little vague and requiring a fair degree of extrapolation.

So, I have not yet installed or used propertree once, having had modified the initial EFI registries using basic text editor and never tried testing a new EFI boot from a pendrive yet. On that note, I also can't quite figure out why my open core's boot menu shows [windows] - [EFI] - [macOS], though I noticed that after countless errors on attempting to install minor Ventura software updates, re-booting via the said mysterious EFI (which otherwise doesn't seem to do anything at all and just boots macOS) appeared to have gotten them successfully installed.

I genuinely appreciate you offering a modded EFI, but given my lack of experience and proverbial wisdom about not fixing thing's that aren't broken, I wander if rather than replacing the entire EFI from scratch with your modded version it would instead make more sense for me to grab what I need from your file and modify my existing EFI with individual registries pertaining only to network adapters issue? I'm basically just mindful about not throwing the baby out with the bathwater here :)

This being a genuine question on my part: What do you think?

[arhoj]

Ha, the baby analogy is spot on, there's no doubting Hackintosh are temperamental and I've often found myself tiptoeing around it when things are predominantly working. The only key is gaining a better understanding of how OpenCore functions, having the confidence and knowledge of what your changing helps immensely – I can tell you from personal experience it comes with time and plenty of headaches!

The beauty of having another instance of opencore on a USB means it won't affect your current boot drive EFI, I'd recommend you do this when making any changes at all. Then when you're sure it's 100% stable, back up your previous boot drive EFI to the USB and copy over the one from the testing USB to your boot drive. Always keep one you know works handy – you never know with Hackintosh these days.

ProperTree is a must, it just makes reading the plist tree infinitely easier. I tend to open x2 instances of it and compare a new/foreign plist with my own line-by-line, any differences I just read the OpenCore manual/changelog to fully understand what it is I'm changing.

By all means keep the EFI the same if you're happy with it currently, feel free to use mine as a reference when creating a new one for the i225 fix (booting from a USB drive, and not your system EFI until you're sure it works, ofc).

I stupidly forgot to mention my board is the ATX variant of the Vision D, so you'll have to keep your own USB map anyway (these are the USBToolBox/UTBMap kexts in the EFI I supplied). I know Schmock uses the SSDT method which I always found caused random hangs on my machine, often at comical times like client calls...

In regards to the system update behaviour, I've experienced issues when installing OTA updates, they'd seemingly fail with an instant kernel panic and I've found creating a bootable USB with the version of MacOS I want to install more successful. Recently I've had no such issue and went from 13.5.2>13.6 OTA, I set the update going from System Pref's an OC automatically chose the correct drive from the picker for me, no interaction needed.

The EFI boot entry can be hidden as this isn't strictly needed, the only option I have visible is the MacOS drive as I boot Windows from a separate internal drive at post, so you may want the Windows drive there if you boot it from OC. To hide clutter from the picker you can look at changing ScanPolicy and HideAuxiliary settings in your plist – see Reddit post for more info. I'd recommend setting ScanPolicy to '0' and disabling HideAuxiliary when your tinkering though.

[ramseysparrow]

Good advice and no way around it really: the only way to learn anything is by doing it and making mistakes.
I will install propertree and learn about test-booting from a pendrive as my next steps, but while still I have an attention of someone a little more experienced, let me ask you this:

1. I have already had 'hide auxiliary = true' and there's no clutter, with all the other things hidden till space is pressed. Still, [EFI] persists alongside [Win] and [Mac] boot options. I don't mind it aesthetically, rather I'm mindful if this isn't an indication that I did not finish something off properly during installation. So, is [efi] expected to be there? What is it anyway, since you're saying it's not strictly needed? I could not find definite answers to this anywhere.

2. I have Mac and Win on separate drives and use OC boot menu to move between. It works flawlessly and reliably. That said, I noticed that some connections get 'hijacked' by whichever last OS that used them. For instance, if I have headphones bluetooth-paired on macOS end, they will remain so until the time I pair them to Windows. At that point, going back to Mac the pairing no longer works and must be forgotten and re-paired, which will then in turn corrupt the pairing windows-end and so on, in circles. It is as if the pairing was considering some unique bluetooth hardware identifier rather than local OS that uses it. That, I have just figured, is also the reason why the [ethernet via thunderbolt] I described earlier works Mac-end without needing to unplug and replug until the time when I decide to boot to windows and back to Mac - then I must unplug it and plug it again for Mac to recognize it. As above, I wander if that is a common byproduct of double-OS hackintoshing, or some individual quirk my end?

[arhoj]

You can think of an EFI like a middleman between your OS and UEFI BIOS. All the EFI partition does is load firmware and extensions required to get to the OS during boot, if the ScanPolicy is set to display EFI, then it'll show up as a selectable option. It being visible isn't an issue, you can just ignore it. Or use this generator to create an integer that would apply to your specific setup to get rid.

I'll be honest, I've always found bluetooth temperamental in Windows, with both Broadcom and Intel chips. I always have issues with it, but never have I had to re-pair when booting back into MacOS. This might be because I boot windows directly from the UEFI boot picker rather than through OC. Do you have this Fenvi driver (Link is a direct download) installed on the Windows side?

[SchmockLord]

Try https://github.com/SchmockLord/Gigabyte-Z590i-Vision-D-11900k/releases/tag/v35 to see if Ethernet and Broadcom Wifi works under Sonoma

[max3-2]

Try https://github.com/SchmockLord/Gigabyte-Z590i-Vision-D-11900k/releases/tag/v35 to see if Ethernet and Broadcom Wifi works under Sonoma

Cool, thanks for the new version, just a question:

1. Any reason to remove the 6900xt ACPI?
2. Quite some kexts added, are those to enable root patching with OCLP and BCM94360?