cs45 Posted September 4, 2016 Share Posted September 4, 2016 Hi Mieze, No luck with 2.2.0d3 either... attached is the kernel log. Thanks, cs45 ----- Gigabyte GA-H170N / Core i3 6100 / 8 GB RAM / Seagate 8TB + 4TB NAS HDD / OS X Server 10.11.6 kernelLog.txt Link to comment Share on other sites More sharing options...
Mieze Posted September 5, 2016 Author Share Posted September 5, 2016 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 More sharing options...
MrToasty97 Posted September 6, 2016 Share Posted September 6, 2016 My Motherboard is the Gigabyte Z170X UD5 TH (Bios Version is F5). Which settings could be wrong or how can I determine if I just have bad luck? Edit: I now had 100Mbit for downloading. Link to comment Share on other sites More sharing options...
MrToasty97 Posted September 10, 2016 Share Posted September 10, 2016 doesn't anybody has an advice? Link to comment Share on other sites More sharing options...
Pirate_Tony Posted September 11, 2016 Share Posted September 11, 2016 Version 2.2.0d3 works fine. MacOS X 10.12 GM. Gigabyte GA-Q87N, Intel 217LM. Link to comment Share on other sites More sharing options...
Xander86 Posted September 11, 2016 Share Posted September 11, 2016 (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 September 11, 2016 by Xander86 Link to comment Share on other sites More sharing options...
marvinum Posted September 11, 2016 Share Posted September 11, 2016 Thanks to Mieze & Mausi my ethernet is now working on my Lenovo T440S. Link to comment Share on other sites More sharing options...
Mieze Posted September 14, 2016 Author Share Posted September 14, 2016 Ok, next try! Here is version 2.2.0d4. Good luck testing! Mieze IntelMausiEthernet-V2.2.0d4.zip 3 Link to comment Share on other sites More sharing options...
Pirate_Tony Posted September 14, 2016 Share Posted September 14, 2016 works on i217LM (from ESP) Link to comment Share on other sites More sharing options...
wastez Posted September 16, 2016 Share Posted September 16, 2016 Here it works too on i217v, no problems so far. WOL is working too. Link to comment Share on other sites More sharing options...
cs45 Posted September 18, 2016 Share Posted September 18, 2016 Success!! No more “Tx stalled” issues after 5TB+ of transfers... Yay! THANK YOU Mieze!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 More sharing options...
fjf Posted September 18, 2016 Share Posted September 18, 2016 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 More sharing options...
Xander86 Posted September 18, 2016 Share Posted September 18, 2016 Yes, nice job, Mieze. 2.2.0d4 seems stable, also without the automount method. thanks! Link to comment Share on other sites More sharing options...
vcn Posted September 18, 2016 Share Posted September 18, 2016 Hello, I had to stay in another country for months to complete a work project and couldn't bring my hack with me. I'm glad the latest versions fixed the large transfers issue Link to comment Share on other sites More sharing options...
scj312 Posted September 19, 2016 Share Posted September 19, 2016 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 More sharing options...
Mieze Posted September 19, 2016 Author Share Posted September 19, 2016 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 More sharing options...
Mieze Posted September 19, 2016 Author Share Posted September 19, 2016 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: 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. 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. 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 6 Link to comment Share on other sites More sharing options...
Xander86 Posted September 19, 2016 Share Posted September 19, 2016 Cool, thanks for the explanation. Link to comment Share on other sites More sharing options...
crashmaster4999 Posted September 20, 2016 Share Posted September 20, 2016 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 More sharing options...
cs45 Posted September 20, 2016 Share Posted September 20, 2016 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 More sharing options...
snam11 Posted September 20, 2016 Share Posted September 20, 2016 Mieze: should we still use the ssdt patch or new release of drivers can be installed with no ssdt injection? Link to comment Share on other sites More sharing options...
scj312 Posted September 20, 2016 Share Posted September 20, 2016 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 More sharing options...
Mieze Posted September 20, 2016 Author Share Posted September 20, 2016 Mieze: should we still use the ssdt patch or new release of drivers can be installed with no ssdt injection? No, the SSDT-patch is obsolete now! Mieze Link to comment Share on other sites More sharing options...
tarasis Posted September 21, 2016 Share Posted September 21, 2016 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. Link to comment Share on other sites More sharing options...
Mieze Posted September 22, 2016 Author Share Posted September 22, 2016 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 2 Link to comment Share on other sites More sharing options...
Recommended Posts