Jump to content

IntelMausiEthernet.kext for Intel onboard LAN

Mieze

By Mieze,
in LAN and Wireless

 Share
1,015 posts in this topic

Recommended Posts

Mieze
Mieze
Posted
  • Author
Posted

Does anyone know what the problem could be: My hackintosh always connections with "10baseT/UTP <full-duplex>" and if I change it to manually in the network preferences, i can't get a IP-Address. My Macbook can use with the same cable 1Gbit. Thanks in advance for your help.

There are several possible reasons which may cause such behavior:

  • Wrong BIOS settings -> Check settings!
  • A Firmware issue (Gigabit operation disabled by firmware) -> Bad luck!
  • Compatibility issue with the switch -> Exchange switch!
  • Hardware defect -> Bad luck!
  • Dust on the RJ-45 connector -> Clean it carefully avoiding electrostatic discharge!
  • A messed up system configuration -> Reinstall!

Mieze

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

Hi Mieze,

 

I changed my mounting method, and all large file copies, from share to share, I did so far today, have been successful.(will test some more)

 

Formerly I just had aliases of my network shares in my user folder, now I use automount/autofs. (like this: http://blog.grapii.com/2015/06/keep-network-drives-mounted-on-mac-os-x-using-autofs/ )

 

i didn't expect this to make a difference, I'll test some more, and post the results here, maybe i was just lucky today.

 

2.2.0d3 version is installed at the moment, I will check if 2.1.0 gives the same results.

 

 

I've tested with 2.1.0 and it also seems to work well with this way of mounting.

 

If anyone can explain this...you're welcome.

 

grtz,

Sander.

Edited by Xander86
Link to comment
Share on other sites
fjf
fjf
Posted
Posted

Using an Asus z170 deluxe (the mobo has an Intel® I219V) with a 6700 CPU, this last driver seems stable.  I've uploaded near 500GB so far (to amazon drive using Arq) and ethernet is still working. Yay!!!.

 

Thanks, Mieze!!.

Link to comment
Share on other sites
scj312
scj312
Posted
Posted

I just switched from 2.1.0 to 2.2.0d4 and noticed that when I sleep the system, my I219V2 seems to not wake up with both ipv4 and ipv6 addresses- it now always seems to lose one or the other. If I bounce the adapter everything comes back to normal.

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

I just switched from 2.1.0 to 2.2.0d4 and noticed that when I sleep the system, my I219V2 seems to not wake up with both ipv4 and ipv6 addresses- it now always seems to lose one or the other. If I bounce the adapter everything comes back to normal.

This isn't a driver problem because the driver handles packets. The IP address is acquired by the network stack.

 

Mieze

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

I was asked to explain what I changed in the last version in order to make the driver work stable during large transfers. Well, after reviewing the code and checking the docs again and running several tests together with crashmaster4000, I identified 3 problems which I have fixed in the last version:

  1. There was a DMA latency issue which was easy to fix after I found the matching system call requireMaxBussStall() to tell the OS about the NIC’s latency requirement.
  2. A hardware bug with regard to descriptor management. Descriptors are small memory blocks, in this case 16 bytes in size, used to communicate commands and data to the the NIC. They are arranged in a ring from where the NIC fetches them and stores them in an internal buffer. After they have been processed, they are marked as consumed and written back. With descriptor prefetch enabled the NIC sometimes reads more descriptors from the ring than there is space in the internal buffer so that unfinished descriptors will be overwritten hence resulting in a transmitter hang. The solution was easy too, I disabled descriptor prefetch.
  3. The third problem was another hardware bug affecting TSO operation. This bug exists since the the days of the old 82571, the ancestor of Intel’s recent onboard LAN solutions which was released in 2005. As the data sheets of the chips the driver supports don’t mention this bug, I wasn’t aware of the fact that these chips are affected too. The documentation (see attachment) reads:

Problem:

The Device Transmit flow stops and the device hangs when operating in TSO with MULR enabled.

 

Implication:

When operating in TCP Segmentation Offload mode and with Multiple Request enabled, one of the two workarounds listed below must be in place or the Transmit Flow will stop unexpectedly.

 

Workaround:

The driver must ensure that the first descriptor points to the (L2+L3+L4) Header and at least two bytes of the data (payload). This has been implemented in the Intel drivers. This workaround must be applied before activating TSO when MULR=1.

Alternatively, register 0x3940 “TARC1” bit 22 can be set at initialization time to workaround this issue.

 

Status:

No Fix: There are no plans to fix this erratum. 

 

Obviously they have been serious about having no plans to fix that issue, even in newer designs as this bug seems to be present in any derived chip for more than a decade now.  Well, I tried both suggested workarounds, both worked for me but failed on crashmaster4000's machine. That's why I finally decided to disable TSO. After all I’m in good company because Apple decided to solve the problem in their Intel 82574L driver (The 82574L is another member of this NIC family) the same way as I did. Although they implemented support for TSO, it has always been left disabled.

 

Mieze

82571eb-82572ei-gbe-controller-spec-update.pdf

  • Like 6
Link to comment
Share on other sites
crashmaster4999
crashmaster4999
Posted
Posted

Mieze -

 

I just wanted to say one more time - thank you so very much for all of the work you've put into this project, and thanks for letting me help with all of the testing. In a way I'm sad to see the project finished... I get the same feeling after finishing reading a captivating book, or re-watching a favorite tv show. I really did enjoy testing 2, 3 or more versions in a night - and I still think you worked way too hard. Now go pet a cat  :)

 

Thanks and I'm ready to help test whatever your next project may be.

 

crash

Link to comment
Share on other sites
cs45
cs45
Posted
Posted

Hear, hear!  A bittersweet victory...

 

Mieze -- Thanks for the in-depth explanation.  I think we all learned something new today.

 

cs45

 

------------------------------------------------------------------------------------------------------------------

Gigabyte GA-H170N / Core i3 6100 / 8 GB RAM / Seagate 8TB + 4TB NAS HDD / OS X Server 10.11.6

Link to comment
Share on other sites
scj312
scj312
Posted
Posted

This isn't a driver problem because the driver handles packets. The IP address is acquired by the network stack.

 

Mieze

Indeed it was an issue with my DHCP server :)

 

Thanks for all of the work on the driver! It's been working very well for me.

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

I'm a little out of the loop, just installed version 2.2.0d4 on Sierra. How/where do I find the driver output? There seems to be absolutely no output in any of the Console views.

I knew this question would be posted here one day because Apple reworked logging in Sierra completely. In Terminal type

log show --predicate "processID == 0" --debug

in order to retrieve kernel logs. See "man log" for further information.

 

Mieze

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