Jump to content

(Solved) Problems with GA-Z490 Vision G and Intel I225-V onboard NIC


10 posts in this topic

Recommended Posts

To get the onboard Intel I225-V ethernet port on this board working "sort of" one has to fake the controller into something which it is not by injection device-id F2150000 together with FakePCIID.kext and FakePCIID_Intel_I225-V.kext, whereafter the ethernet port is actually working quite well however without properly functioning sleep.

 

To get sleep working "again sort of" one has to disable "Power Nap" as well as "wake for network access" in System Preferences --> Energy Saver, both are features I actually need.

 

To me this is actually tantamount to crippling some features in order to make another feature work, being not a very elegant hacking approach, at least as far as I am concerned.

 

I noticed however that the NIC continues to respond to ICMP (ping) request whilst the machine is actually sleeping, which is not correct.

 

Enabling "Power Nap" drastically changes the sleep rhythm. The machine now only sleeps for just over 5 minutes then wakes to engage in some background tasks and dutifully goes to sleeps again, this continues in intervals of 5 to 6 minutes ad infinitum, and amounts to more than 250 sleep cycles over a 24 hour period.

 

I am presently using an OOB compatible USB 10/100/1000 ethernet adapter, together with a fake en0 port to enable access to the Apple iCloud services. The onboard i225-V has not been disabled in BIOS as it is used by other operating systems, resident on this build.

 

The attached screenshot shows that sleep is now actually working quite well with the USB ethernet adapter in combination with the fake en0 port and the FakePCIID.kext and FakePCIID_Intel_I225-V.kext being disabled in the OC 0.6.8 config.plist file.

 

In the longer run,  and if at all possible, I want to revert back to the onboard i225-V controller, or is there perhaps somebody that can offer a solution already at this stage to make that possible.

 

Any suggestions will be most welcome, maybe @Mieze , time permitting, can also provide some advice leading perhaps in resolving this issue.

Screen Shot 2021-04-17 at 7.23.07 AM.png

Edited by Henties
Posted (edited)

@DertyThank you for your feedback, the method Samuel uses is exactly the same method, with the same files, that I am having sleep problems with. Indeed this is the method used universally by all users of this particular mobo that I have come across so far. I compared the FakePCIID.kext and FakePCIID_Intel_I225-V.kext files he published in his Git-hub repo, with the ones I am using as well as those still freely available on @RehabMan's Git-hub repo, and discovered a one to one correspondence between all sets that are available  to try out. 

The custom fakeid "F2150000" is what I am also using and is tricking Big Sur into believing that the operating system is "dealing" with a predecessor of the onboard Intel I225-V ethernet port on this particular mobo for which built in drivers indeed exist and are provided by Apple with the Big Sur distribution. The problem is however that the built in driver is not entirely able to handle this new onboard Intel I225-V ethernet port in all respects, hence the problems I am experiencing, and for that matter I believe everybody else using this particular method of faking.

A workaround is to just disable "Power Nap" and "Wake for network access" however this is not an acceptable solution in my particular "managed" networked environment, in which the NIC of a "sleeping" workstation must not respond to ICPM "ping" requests whilst supposedly sleeping.

 

Regards Henties  

Edited by Henties
11 hours ago, Henties said:

I noticed however that the NIC continues to respond to ICMP (ping) request whilst the machine is actually sleeping, which is not correct.

This is not a bug, it's a feature implemented by offloading tasks like Bonjour and ICMP to the NIC while sleeping. Apple machines exhibit this behavior too.

 

11 hours ago, Henties said:

Enabling "Power Nap" drastically changes the sleep rhythm. The machine now only sleeps for just over 5 minutes then wakes to engage in some background tasks and dutifully goes to sleeps again, this continues in intervals of 5 to 6 minutes ad infinitum, and amounts to more than 250 sleep cycles over a 24 hour period.

Depending what is running on your machine, this is also quite normal and the way PowerNap is designed to work. By the way, a USB network adapter is primarily an USB device. It does not behave in the same way as a PCIe-attached NIC.

 

As it is an onboard device, I would check the network-related settings in the UEFI setup.

 

Mieze :cat:

  • Thanks 1
Posted (edited)
13 hours ago, Mieze said:

This is not a bug, it's a feature implemented by offloading tasks like Bonjour and ICMP to the NIC while sleeping. Apple machines exhibit this behavior too.

@MiezeThanks a lot for taking the time to respond considering that you are possibly still tied down with your "Klausur" preparation/activities.

 

Your response to my ICMP (ping) observation is  confusing me somewhat because I have never encountered this phenomenon before with any of my hacks. Just tested ping to some sleeping machines on my network with the result being reflected as per the attached screenshot. 

Ping returns a "no route to host" when attempting to reach a sleeping machine, which seems normal to me.

 

The machine named "blikbrain" , being the Z490 Vision G build, now using a 10/100/1000 USB adapter instead of the onboard Intel I225-V ethernet port, behaves the same as the other 2 machines that are networking through their onboard NICS. 

Also check how nicely "blikbrain" sleeps with this 10/100/1000 USB ethernet adapter, achieving the same sleep stability that "office" is capable of except that "office" uses its onboard LAN in conjunction with your IntelMausiEthernet.kext V 2.5.3d1. Therefore there seems to be no penalty in using a USB 10/100/1000 ethernet port on "blikbrain", at leat not from an operational point of view.

As soon as I now configure "blikbrain" , using the fake device-id F2150000 together with FakePCIID.kext and FakePCIID_Intel_I225-V.kext "trickerydoo" so that it will use the onboard LAN instead, the wheels start falling off.

Instead of "dark waking" only 75 times over a period of 106 hours it will now darkwake close to 1000 times over the same period, or rather approximately 10 times every our, however it never reaches these long and flawless operational stints because not long after the machine has been configured to use the onboard NIC, it hangs itself up six or seven hours later. This machine lockup can however be alleviated somewhat by disabling "Power Nap" as well as "wake on network access in System Preferences --> Energy Saver, whereas I can leave those features enabled when "blikbrain" is using the 10/100/1000 USB network dongle.

 

Greeting Henties

 

Blikbrain 106 hrs 75 darkwakes.png

Office 107 hrs  68 darkwaakes.png

Ping result.png

Edited by Henties

It's not a bug, it's a feature. Protocol offload in sleep was designed to keep the machine visible in the network while it is sleeping. It enables the NIC to respond to ARP, ICMP, etc., or with Apple machines also to Bonjour requests. It also allows the machine to wake up when there are other requests, e.g. SMB.

 

Protocol offload requires the driver to provide the NIC with special firmware, which implements these features. Windows drivers come with the firmware, Apple supplied drivers too. Linux drivers don't support protocol offload because they lack the firmware. The same applies to my drivers because they are based on Linux source code. As USB-attached LAN-adapters use a generic driver, they lack this feature too.

 

AppleIntelI210Ethernet.kext comes with native support for the I225LM. Faking it's PCI dev ID allows it to work with the I225V on your board. This driver supplies the firmware required for protocol offload, which is the reason why your machine wakes up frequently and there is little which can be done to change this behavior, except disabling "Power Nap" as well as "wake on network access in System Preferences. 

 

With regard to the system hangs caused by wake ups, there is a number of possible reasons:

  • A bug in AppleIntelI210Ethernet.kext ->bad luck!
  • Differences between the I225LM and the I225V -> also bad luck!
  • A network related setting in the UEFI setup -> Check your settings!
  • A generic sleep/wake problem -> Usually hard to debug but not a hopeless case.

Frankly, at the moment, you have two choices: accept the behavior or avoid using the I225V.

 

Mieze :cat:

 

Edited by Mieze

@Mieze Thank you for your comprehensive reply and detailed explanation, much appreciated indeed.

The sleep behaviour that I am achieving with the 10/100/1000 USB ethernet adapter mimics that which I am accustomed to with your, linux based IntelMausiEthernet.kext V. 2.5.3d1 on my Skylake as well as my Haswell based hacks. 

Using the USB ethernet adapter allows me to integrate my Comet Lake build into my existing managed network, on which all devices, servers and workstations included, can be accessed from anywhere, even remotely, on an on demand basis, without any additional measures, that would otherwise have be necessary.

Topic closed

Greetings Henties

Enjoy or destroy, taken in my "garden"

656911604_LionCub.thumb.jpg.f3e411a636f7348a04a54aa63294f37e.jpg

  • Like 1
  • Thanks 1
  • Henties changed the title to (Solved) Problems with GA-Z490 Vision G and Intel I225-V onboard NIC

@Henties - Hello Sir haven't seen you in a while, the last time was on the other side :wink_anim: good to see you're still on the Hack scene. :thumbsup_anim:

Posted (edited)

Hi @eSaF I am pleased to meet "old" friends again here. I noticed that you haven't been active on the other side for some time now, nice to know that you are still around merrily hacking about. I spent some time on a mainly German "speaking" site where it is also possible to communicate in English, however there are a few too many "hacking gods" that control the scene over there. A complaint, of mine about something else though, ended up in me being banned from that site for 3 weeks, it's also quite ridiculous how often these guys are "bickering" among themselves about what I consider trivialities, therefore they will not see me again, when my ban "is lifted in a few days time. In any case Insanely is the place I consider the "hacking coal face" with more capable and helpful developers around than on the German site. I am pleased that we will be seeing each other here more often from now on. 

Greeting Henties

Edited by Henties
×
×
  • Create New...