Jump to content

Mieze

Mieze

Member Since 27 Mar 2012
Offline Last Active Yesterday, 10:53 PM
*****

#2163887 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 27 August 2015 - 11:08 PM

Hummm ok, let's say you're right, what kind of kernel parameters would you play with then ?I'd rather fix my problem than be right :) (thanks for your time btw !! I hope I don't sound too cranky)Frankly I'm not sure as there are things you can't control. The packet roundtrip time and it's variation are the factors which are used in order to detect congestion and it might easily produce false positives as both values are much higher for a remote connection which results in a dramatic slowdown. Basically it's a similar situation as with WIFI according to the IEEE802.11ac standard where the high roundtrip time is also a limiting factor and you might use the strategies used to optimize performance in these scenarios as a starting point. The packet scheduler QFQ, which is a part of Apple's new driver interface, is something that is harder to influence but it is necessary in order to maintain stability under overload because it throttles the output rate when packets start to bec...

#2163055 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 24 August 2015 - 12:58 PM

I analyzed the issue RehabMan and others reported and was able to reproduce it on my test machine with an I218. According to my findings and the log data chrashmaster4999 sent me, the problem can be narrowed down to an interference of the way AFP organizes network buffers since 10.10.4 and a peculiarity of the chip's DMA engine. After 25 hours of hard work it looks like I found a workaround which is working on my machine. I have successfully transferred 120GB of data over AFP without experiencing a single deadlock so that I'm quite confident that it will work on other machines too. Attached you'll find a prebuilt binary of the test version I've been using. Please test it thoroughly and report back if it works as expected. Good luck! Mieze Attached Files  IntelMausiEthernet-2.0.2d3.zip 1.49MB 27 downloads

#2160395 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 14 August 2015 - 06:25 PM

Support for I219 will be added when Apple comes out with Skylake based products. Mieze

#2159857 Solution for Qualcomm Atheros AR816x, AR817x and Killer E220x

Posted by Mieze on 12 August 2015 - 07:09 PM

I have published version 2.0.1 (source and binary) which improves flow control support in 100MBit mode a few moments ago.

#2159311 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 10 August 2015 - 10:00 PM

 What do you mean by: Call "Archive" from the menu "Product" and save the built driver. The first clause should be clear. In order to save the driver select it in the Organizer, which is opened automatically, and click "Export". Now select "Save Built Products", click "Next" and select a directory where the products should be saved, for example the desktop, and confirm with "Export". Finally open the saved folder in Finder and you'll find a subdirectory hierarchy called "System/Library/Extensions" in it. There you will find your driver. Mieze

#2159071 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 09 August 2015 - 05:11 PM

@RehabMan:  Intel's datasheets of the 82579 and the I217 contain the following advice with regard to the transmit descriptor handling policy. Bildschirmfoto 2015-08-09 um 18.49.58.png 23.3KB 2 downloadsThe strange thing is that neither the Windows nor the Linux driver follow this advice but on my I217, which was affected of random tx deadlocks in early development versions of the driver too, setting TXDCTL=0 eliminated the problem. That's why I added this workaround in version 2.0.0d2 but as I don't have an 82579 to test on, I haven't been able to verify it on this NIC./** * intelConfigureTx - Configure Transmit Unit after Reset * @adapter: board private structure * * Configure the Tx unit of the MAC after a reset. **/void IntelMausi::intelConfigureTx(struct e1000_adapter *adapter){ struct e1000_hw *hw = &adapter->hw; UInt32 tctl, tarc; UInt32 txdctl; /* Setup the HW Tx Head and Tail descriptor pointers */ intelInitTxRing(); /* Set the...

#2157720 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 04 August 2015 - 10:19 AM

Oh Sorry @Mieze ! I am back at work now so I should have time to try when I get home. The last version you gave me didn't work... So whats next step? you want my logs for the last try? AppleIIGuy reported it to work on X79. I need your kernel logs of the last try. EDIT: Almost 2 days later still nothing. Please tell me, why is it so hard to send me a log file?  :angry: Mieze

#2155540 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 25 July 2015 - 11:01 PM

Try this! It looks like npci=0x2000 is doing something really stupid as it changes the default cache setting for memory mapped I/O areas from uncacheable, which makes sense, to cacheable, which effectively breaks MMIO, unless the driver explicitly changes this setting to uncacheable. This is what I changed in the attached version. Sources and prebuilt binaries are included. Good luck! Mieze Attached Files  IntelMausiEthernet-V2.0.1d1.zip 1.44MB 13 downloads

#2155361 RealtekR1000 v3

Posted by Mieze on 25 July 2015 - 02:29 AM

Tried this driver today because Mieze's driver is not usable due to lost interrupts.  :no: Lost interrupts are nothing more than cosmetic issues. Mieze

#2155116 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 23 July 2015 - 10:49 PM

Maybe also it would be better if I could disable my npci=0x2000 as you said it would be best to avoid that bootflag but my machine is not starting without that one... I will test that now so that I am 100% sure about that... Frankly, I don't know how to resolve this and I even don't know if it can be resolved at all without the help of Apple. As far as I know, no real Mac needs this flag in order to boot and it is unnecessary on machines with an officially supported chipset like those for socket 115x CPUs. According to my information npci=0x2000 makes the memory area behind an PCIe-to-PCIe bridge prefetchable which effectively kills memory mapped I/O behind that bridge. I'm not a PCIe expert and the fact that a copy of the specs costs 3000$ doesn't make it easier to get access to the information. Otherwise you can come visit me, it's common that people from germany come to vaccation to sweden :) You are welcome! Unfortunately I'm not like most Germans because like all cats...

#2153333 New Driver for Realtek RTL8111

Posted by Mieze on 15 July 2015 - 12:45 AM

I was informed by bellcow that the prebuilt binaries of version 2.0.0 don't work on Mountain Lion. I pushed a modified version which fixes the issue to GitHub. In case you are still running ML, please build from source. Users with Mavericks and newer aren't affected of the problem so that there is no need for an update. Mieze

#2153331 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 15 July 2015 - 12:40 AM

I have pushed the modified version 2.0.0 with the fix for ML to GitHub. Please note that there will be no updated binaries. In case you are still running ML, please build from source. Mieze

#2151798 Solution for Qualcomm Atheros AR816x, AR817x and Killer E220x

Posted by Mieze on 08 July 2015 - 09:10 PM

Hi, Ever since I upgraded to Yosemite 10.10.4, I've been getting strange errors with my E2200 card: 7/2/15 1:53:15.000 PM kernel[0]: Ethernet [AtherosE2200]: Fatal interrupt. Reseting chip. ISR=0x200 This seems to happen most often when I am copying files to my SMB shared folder. This has only started happening in 10.10.4, previously, the driver was very solid. Is anyone else running into this issue as well? I have two machines with version 2.0.0 of this driver running under 10.10.4 (including my server with 24/7 uptime), and none of them has had any problems since I upgraded to 10.10.4 almost 6 days ago. That's why I'm quite sure that your problem is neither a driver bug nor has anything to do with 10.10.4 in particular, but it reminds me of this issue: http://www.insanelym...220x/?p=2128204 According to experiences I made during test runs while the driver was still under development, fatal interrupts occur when something has disabled the NIC...

#2149777 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 01 July 2015 - 10:31 AM

So we met again lol ok so the issue is your kext in 10.11 beta 2 has a huge issue where the net slows from 100 download 90 upload to 36/kb's download and 1 kb/s upload speed after 32 hours so can you maybe update your kext for 10.11 please thanks and all hail the cat gods!!!!  update: when i turn off itunes 12.2 the net speed goes back to normal seems to be a issues with your kext and the new itunes 12.2 with apple music  There is no need for an update because this is not a driver issue. A driver handles packets on behalf of the network stack, nothing more and nothing less. It doesn't care where they are coming from or where they are going to and it never gets in touch with an application directly. If there is a problem with a specific service or application, search somewhere else because a driver error can be ruled out. Mieze

#2149254 New Driver for Realtek RTL8111

Posted by Mieze on 29 June 2015 - 12:08 PM

Well,is there jumbo frame support available? You'll find the answer in post #1 of this thread. Mieze

© 2015 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy