Jump to content

Marvell (Aquantia) 10 Gb Ethernet support thread

d5aqoep

By d5aqoep,
in LAN and Wireless

 Share
520 posts in this topic

Recommended Posts

XStylus
XStylus
Posted
Posted
On 2/18/2022 at 3:14 PM, starchyfind said:

I recently swapped out my Syba 10GbE card for the TP-Link TX401 which has been working much better with my system [...]

 

 

 

Out of curiosity, what issues were you experiencing with the Syba card?

Link to comment
Share on other sites
Dids
Dids
Posted
Posted
14 hours ago, nazrm said:

Quadrouplechecked my config. The patch is correctly set in the config file, unfortunately! 

 

Second'ing what @Dids wrote: When it doesn't crash on boot I too get the issue with no IP. 

 

I am running firmware 3.1.118 on the card and 12.3 build number is 21E230

 

Just a quick update. While keeping this patch enabled, and still not getting an IP, I experienced my first hard crash now as well.

 

As I've setup automatic login, it hard crashed on the desktop, with the cursor beachballing at the top left corner and the entire system was unresponsive.

I can pull the logs if necessary, but not sure if they'd help, as it's still very much unclear as to what Apple actually changed with 12.3, beta and otherwise.

Link to comment
Share on other sites
plutect
plutect
Posted
Posted (edited)

I have the same problems as the previous speaker since macOS 12.3 with my ASUS 10G XG-C100C. I have integrated the new patch in the OC config.plist, the card is recognized but no IP is assigned and no traffic is sent via the card. Unfortunately also hard crashes when the LAN cable is plugged in.

 

Edited by plutect
  • Like 1
Link to comment
Share on other sites
kaneske
kaneske
Posted
Posted

To solve this Puzzle I think @Mieze is needed 👩‍⚕️

 

Would you please be so kind and have a look on this?

In my Case with an ASUS Card on Reference FW newest release 121...no luck.

 

Blinking, but no useable connection.

 

Attached the Kext: IONetworkingFamily and AppleEthernetAquantioaAqtion

 

THX in Advance...

 

AppleEthernetAquantiaAqtion.kext.zip IONetworkingFamily.kext.zip

  • Like 1
Link to comment
Share on other sites
starchyfind
starchyfind
Posted
Posted
On 3/16/2022 at 1:27 AM, XStylus said:

 

 

Out of curiosity, what issues were you experiencing with the Syba card?

With my system, even across multiple version of macOS also Windows, the computer would never get to sleep. It would attempt to sleep, but then wake up immediately.  I tried every BIOS setting I could find.  I just got tired of troubleshooting with no change in results.

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
Posted (edited)

Guys I have good news: Shikumo's patch worked for me after all. I think for it to work you need to do one of the following:

1. Uncheck DisableIOMapper quirk. This quirk has to do with DMAR table and VT-d, so you might need to do proper DMAR patching and drop OEM DMAR (which is what I did), or disable/enable VT-d. There're tutorials on how to patch DMAR, it's not that hard.

2. Make sure the card is not one of the system interfaces (en0 and en1). I think this does not matter, but on my system it is now en3 and before it was en0. You can change the interface name by editing /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist. You need to reboot with `sudo reboot` command immediately after editing it, regular restart will revert your changes. If your network preference got messed up after editing this file (interface name mismatches), just delete the messed up interface and add it back. EDIT: Verified this does not matter. Just make sure the interface en0 and en1 DO exist in your system or you'll have various problems (e.g. App Store apps unable to verify signature and refusing to open).

I'll do a few verification boot when I have the time and update here.

Edited by MisakaMikoto0
  • Like 2
  • Thanks 1
Link to comment
Share on other sites
roddie
roddie
Posted
Posted
1 minute ago, MisakaMikoto0 said:

1. Uncheck DisableIOMapper quirk. This quirk has to do with DMAR table and VT-d, so you might need to do proper DMAR patching and drop OEM DMAR (which is what I did), or disable VT-d. There're tutorials on how to patch DMAR, it's not that hard.

 

Thanks for the update!

 

Sorry if this is a basic question: What is the impact of disabling this quirk without patching the DMAR?  I want to test disabling the DisableIOMapper quirk to see if my NIC (ASUS XG-C100C) works before taking the extra step of learning how to patch DMAR.

 

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
Posted
1 minute ago, roddie said:

 

Thanks for the update!

 

Sorry if this is a basic question: What is the impact of disabling this quirk without patching the DMAR?  I want to test disabling the DisableIOMapper quirk to see if my NIC (ASUS XG-C100C) works before taking the extra step of learning how to patch DMAR.

 

I'm not an expert on this so I'm not sure, but it should not make your system unbootable just by unchecking it. Some perple have a working system regardless of it's enabled or not. BUT just in case, always back up your EFI on to a USB drive.

Link to comment
Share on other sites
roddie
roddie
Posted
Posted
Just now, MisakaMikoto0 said:

I'm not an expert on this so I'm not sure, but it should not make your system unbootable just by unchecking it. Some perple have a working system regardless of it's enabled or not. BUT just in case, always back up your EFI on to a USB drive.

 

Thanks!  I may give this a try once others have confirmed it as a workaround.

Link to comment
Share on other sites
roddie
roddie
Posted
Posted
2 hours ago, roddie said:

 

Thanks!  I may give this a try once others have confirmed it as a workaround.

No luck after changing DisableIOMapper to false - I can see the NIC as en2, but it's not getting an IP address.

 

On the bright side, no adverse effects after disabling the quirk, either 🙂

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
Posted (edited)

I just did a few check reboots. It's kinda inconsistent. The first time I reenabled DisableIOMapper, the system booted but the card will not get an IP just like yours. Then I turned it back off, and the first reboot after that ended in panic at login screen but subsequent boots were fine and the card functions. Weird huh?

 

From OpenCore Configurator, explanation of DisableIOMapper quirk:

Misconfigured IOMMU in the firmware may result in broken
devices such as ethernet or Wi-Fi adapters. For instance, an
ethernet adapter may cycle in link-up link-down state infinitely and a
Wi-Fi adapter may fail to discover networks. Gigabyte is one of the
most common OEMs with these issues.

Edited by MisakaMikoto0
Link to comment
Share on other sites
roddie
roddie
Posted
Posted
On 3/18/2022 at 1:58 PM, roddie said:

No luck after changing DisableIOMapper to false - I can see the NIC as en2, but it's not getting an IP address.

 

On the bright side, no adverse effects after disabling the quirk, either 🙂

Just got it working by enabling VT-D support in my BIOS.  I've had it disabled since my first build many years ago for some reason.

 

In summary, these three things brought my ASUS XG-C100C 10G card back to life in 12.3:

 

- Patch using the values in this post.

- Set the DisableIOMapper Quirk to "false."

- Enable VT-D support in my BIOS

 

Thanks for the help everyone!

 

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
Posted
25 minutes ago, PMheart said:

After reading the posts and having reverse-engineered binaries myself, I believe that it is better to combine several patches into one using Mask. Here is the new patch based on @Mieze's one, whose bytes tend to be stabler.

  

			<dict>
				<key>Arch</key>
				<string>x86_64</string>
				<key>Base</key>
				<string>__ZN30AppleEthernetAquantiaAqtion10718checkConfigSupportERiS0_</string>
				<key>Comment</key>
				<string>AppleEthernetAquantiaAqtion general patch</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>QccAAAAAAADp</data>
				<key>Identifier</key>
				<string>com.apple.driver.AppleEthernetAquantiaAqtion</string>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data>//8AAP8AAAD/</data>
				<key>MaxKernel</key>
				<string></string>
				<key>MinKernel</key>
				<string></string>
				<key>Replace</key>
				<data>QccAAAEAAADp</data>
				<key>ReplaceMask</key>
				<data>//8AAP8AAAD/</data>
				<key>Skip</key>
				<integer>0</integer>
			</dict>

 

Also attached as a sample plist.

 

Thanks @Mieze and @Shikumo!

Patch.plist.zip 994 B · 3 downloads

You sir are awesome! Worked for me on the first try. Hopefully this patch can last more versions...

Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted (edited)
8 minutes ago, MisakaMikoto0 said:

You sir are awesome! Worked for me on the first try. Hopefully this patch can last more versions...

 

ミコトさんいえいえ！

 

PMheart is an auntie though 😛

 

I will now make this patch a OC quirk!

Edited by PMheart
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
Posted
12 minutes ago, PMheart said:

 

ミコトさんいえいえ！

 

PMheart is an auntie though 😛

 

I will now make this patch a OC quirk!

LOL! My bad😛

That username though is like AGES old, when I registered this account I tend to use names from anime for absolutely everything. Gotta DM a mod lol

Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted (edited)
1 hour ago, i0ntempest said:

LOL! My bad😛

That username though is like AGES old, when I registered this account I tend to use names from anime for absolutely everything. Gotta DM a mod lol

Could you please try ForceAquantiaEthernet quirk instead on OC now? I have just committed https://github.com/acidanthera/OpenCorePkg/commit/41882d980b4994497bb5730c1725eab60dfd8142

 

Sorry, I made a typo so the previous one won't work! Please try https://github.com/acidanthera/OpenCorePkg/commit/a4b0c47f13e9d5d34534e14ec34cee09cdee666d instead!

 

EDIT: You may take the binaries from https://github.com/acidanthera/OpenCorePkg/actions/runs/2011713486 when GitHub Action finishes.

Edited by PMheart
  • Like 3
Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted
2 minutes ago, kaneske said:
  Reveal hidden contents

 

@PMheart awesome 👏 

 

Really nice to see this going to be a quirk in OC!

 

THX in Advance!

 

I can test later this Day (Berlin Time Zone) if VT-D or DisableIOMapper affects it.

Danke! So we still have a nice weekend evening. UTC +1 here too.

Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted (edited)

UPDATE - Looks like we do need to enable VT-d with DisableIOMapper disabled in config! Added notes in OC Configuration.pdf.

 

Now - what if one is unable to keep VT-d enabled (i.e. by either dropping DMAR table or enabling DisableIOMapper) who want Aquantia to work? ...

Edited by PMheart
Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
Posted
4 hours ago, PMheart said:

Could you please try ForceAquantiaEthernet quirk instead on OC now? I have just committed https://github.com/acidanthera/OpenCorePkg/commit/41882d980b4994497bb5730c1725eab60dfd8142

 

Sorry, I made a typo so the previous one won't work! Please try https://github.com/acidanthera/OpenCorePkg/commit/a4b0c47f13e9d5d34534e14ec34cee09cdee666d instead!

 

EDIT: You may take the binaries from https://github.com/acidanthera/OpenCorePkg/actions/runs/2011713486 when GitHub Action finishes.

Will try soon. Do I need to adapt my config.plist to 0.8 first to avoid errors?

Link to comment
Share on other sites
Shikumo
Shikumo
Posted
Posted

I'm happy to see, that some of the you got it finally working.

 

I just want to to clarify that it should not matter which kind of patch is used here, because both approaches are doing basically the same. So they both should work or not work under the same circumstances with the same outcome. Anything else is because of other circumstances.

 

I also want to mention the differences in approach of the two patches. Some might be interested.

 

My proposed patch is patching the check of one of the return values of the virtual call to *::checkConfigSupport() (i.e. AppleEthernetAquantiaAqtion107::checkConfigSupport(int&, int&) and AppleEthernetAquantiaAqtion113::checkConfigSupport(int&, int&)), ignoring the result and always progressing to the next step. This means it probably supports a wider variety of Marvell/Aquantia cards (i.e. not only 107 based cards but also 113 based cards, but I haven't tested this). Whereas the patch by Mieze/PMHeart only patches  AppleEthernetAquantiaAqtion107::checkConfigSupport(int&, int&) with the value that is checked (and ignored) in my patch allowing it to progress.

 

On the topic of longevity of any patch. You can't really say, how long it will last, it all depends on what Apple is doing. Everything else is guesswork, as can easily be seen in that my proposed patch worked from 12.0 beta until 12.2, whereas the other one was broken in-between. But this is purely coincidental, and could have easily been the other way around  or both could have been broken the same way as with 12.3.

 

I hope this helps.

  • Like 3
Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted
1 minute ago, Shikumo said:

I'm happy to see, that some of the you got it finally working.

 

I just want to to clarify that it should not matter which kind of patch is used here, because both approaches are doing basically the same. So they both should work or not work under the same circumstances with the same outcome. Anything else is because of other circumstances.

 

I also want to mention the differences in approach of the two patches. Some might be interested.

 

My proposed patch is patching the check of one of the return values of the virtual call to *::checkConfigSupport() (i.e. AppleEthernetAquantiaAqtion107::checkConfigSupport(int&, int&) and AppleEthernetAquantiaAqtion113::checkConfigSupport(int&, int&)), ignoring the result and always progressing to the next step. This means it probably supports a wider variety of Marvell/Aquantia cards (i.e. not only 107 based cards but also 113 based cards, but I haven't tested this). Whereas the patch by Mieze/PMHeart only patches  AppleEthernetAquantiaAqtion107::checkConfigSupport(int&, int&) with the value that is checked (and ignored) in my patch allowing it to progress.

 

On the topic of longevity of any patch. You can't really say, how long it will last, it all depends on what Apple is doing. Everything else is guesswork, as can easily be seen in that my proposed patch worked from 12.0 beta until 12.2, whereas the other one was broken in-between. But this is purely coincidental, and could have easily been the other way around  or both could have been broken the same way as with 12.3.

 

I hope this helps.

Yes! This makes sense. I believe that we can integrate your patch as well. That is to say, applying both patches! And in case one is broken, there are still chances that the other will work.

 

Code-wise speaking, it should not harm by applying both patches. I will make it now.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...