Jump to content

Mieze

Mieze

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

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

Posted by Mieze on 27 March 2015 - 01:46 AM

 @MadMax3947: Frankly, I don't think that there is a driver bug but something outside of the driver seems to shut down the NIC which causes the driver to hang because read operations return 0xffffffff when the PCIe device is no longer accessible as in the log message below.Mar 24 23:08:21 Mac-Pro kernel[0]: Ethernet [AtherosE2200]: Tx stalled? Resetting chipset. ISR=0xffffffff, IMR=0xffffffff.The reason why I am so sure is that you are using the same NIC as I do for development and I never had an issue since release of version 1.0.0d7 (7 month). Please take a look at the BIOS settings and make sure that network boot and the UEFI network stack is disabled. You'll have to find out what is disabling the NIC in order to prevent the issue. Mieze

#2123444 New Driver for Realtek RTL8111

Posted by Mieze on 26 March 2015 - 11:27 PM

The cause of the problem lies on the other side because it doesn't accept packets fast enough to reach full speed. That's also the reason why TSO is causing trouble. You'll have to dig deep into the TCP configuration of this machine, but I leave this task up to you because I don't have a quick answer. Mieze

#2122824 New Driver for Realtek RTL8111

Posted by Mieze on 25 March 2015 - 09:05 AM

The driver is unable to determine the correct chipset. Which mainboard are you using or is the NIC located on an add-in card? Mieze

#2119653 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 14 March 2015 - 01:22 AM

I'm making progress with regard to the VMware issue. I created a version of the driver which uses Apple's private network driver interface introduced with 10.8. This new interface has an improved output queue handling and support for packet scheduling with QFQ. Performance and CPU usage seem to be comparable to the version with the traditional interface but it looks like VMware has stopped killing the network stack from time to time. At least I haven't had this issue since I switched over to the new interface. As it was introduced with Mountain Lion there is no way to make the new version work under anything below 10.8. I will publish it during the weekend after running some more tests. Its version number will be 2.0.0d1. Mieze

#2119568 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 13 March 2015 - 08:21 PM

Can't really test full throughput yet as only getting a max 100baseTX connection to router (which has gigabit ports). Had this problem previously using AppleIntelE1000e.kext too, which likely suggests a wiring issue—probably involving the ~75ft of 8-y/o cat5e that runs from one end of the house to the other @ router. Guess I'm going to be having fun this wknd swapping that out for cat6… then I'll try posting some speed test results. First, try to clean the RJ-45 connectors/cables from dust. Gigabit ethernet needs all 8 wires to be working. I experienced this issue several times since I switched to gigabit ethernet 6 years ago and in more than 90% the cleaning resolved the issue. Possible, but the WiFi also does the same thing. Which makes me think its something to do with the network stack initialization as a whole. Sounds like a DHCP issue. Maybe you should take a look at the kernel logs and /or the DHCP server's logs. Mieze

#2118311 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 09 March 2015 - 01:20 PM

I pushed the source code to GitHub last weekend. It can be found here: http://github.com/Mi...elMausiEthernet Mieze

#2118253 Permanently Banned From Tonymacx86

Posted by Mieze on 06 March 2015 - 02:40 AM

I wonder how long it will take for tonymacx86 to steal my latest project: http://www.insanelym...-lan/?p=2107186 I'd love to scratch him with my claws. :cat:  Mieze

#2118189 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 05 March 2015 - 09:14 PM

After testing iMessage on my development machine this evening with version 1.0.0d6 of the driver I can confirm that it is working. See for yourself:Mieze

#2117850 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 04 March 2015 - 11:58 PM

I ran some additional tests this evening without finding evidence for a driver issue. Everything was working as expected. Nevertheless I used this opportunity to complete the missing lines of code needed for WoL support which is now working (1.0.0d6) on my test machine too. You can find version 1.0.0d6 attached to post #1 of this thread. Good luck! Mieze  :cat:

#2117024 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 02 March 2015 - 07:00 PM

I've been running D5 for the last 3 days and its been fine other than the occasional01/03/2015 17:51:40.000 kernel[0]: Ethernet [IntelMausi]: Check tx ring for progress. txNumFreeDesc=1016(where desc is a number between 1016 and 1023). However I haven't run VMWare at all. These occasional messages are lost interrupts and nothing to worry about. Under load the next interrupt will clear the condition and in idle mode the watchdog will do the job. With d5 version, I can't connect to iMessage nor FaceTime.Revert to d3 and all is good anew. I can assure you that this is not a driver issue because I haven't changed anything which might affect iMessage or FaceTime. Strange things like this happen sometimes but they are usually a side effect caused by the installation process itself. After all it seems that we are making progress. I will rework TSO6 too in order to prevent problems which may arise with VMware just to be on the save side. Mieze

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

Posted by Mieze on 01 March 2015 - 01:06 AM

I updated the prebuilt binary in the Download section of this site and pushed the source to GitHub this evening. Have fun! Mieze  :cat:

#2116300 Atheros AR813X/AR815X/AR816X/AR817X/E220X driver for Yosemite (based on Ather...

Posted by Mieze on 01 March 2015 - 12:53 AM

Not working for me. With debug kext: Well, the expected behavior because the underlying Linux code doesn't support AR813x and AR815x. @Andy Vandijck: Please contact me before you start modifying my drivers. I would love to l help you to do it properly. I would suggest to create a new driver just for AR813x and AR815x. Take my code as a base and remove all the AR816x, AR817x and Killer specific stuff, in particular the linux code, and replace it with code from the linux driver for AR813x and AR815x. You'll get much cleaner code which will work the way it should. Mieze

#2115798 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 27 February 2015 - 06:40 PM

I just posted version 1.0.0d5 with reworked TSO4 support in order to circumvent the issue in 1.0.0d4. It also includes additional debug code to collect more information about the VMware related problem. According to my findings it isn't a TSO specific problem as kernel logs from tarasis showed transmitter deadlocks while doing non-TSO operations. As of now I'm at a loss but will continue the search for a solution. Mieze  :cat:

#2114961 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 25 February 2015 - 12:57 PM

Ok, I found something. Looks like VMware is killing TSO because the packets causing the tx deadlock are TSO4 operations. According to Intel's datasheet the Total Length field of the IP header should be set to zero, but in a packet that caused a deadlock it wasn't. See for yourself:IP-Header: Version: 0x4 Length: 0x5 TOS: 0x20 Total Length: 0x0b84 (2948) <--- Should be 0. ID: 0x32 0xc9 Flags: 0x4 Frag. Offset: 0x000 TTL: 0x40 Protocol: 0x06 CSum: 0x00 0x00 Source: 0xc0 0xa8 0x00 0x26 (192.168.0.38) Dest.: 0xc0 0xa8 0x00 0xd5 (192.168.0.218)I published version 1.0.0d4 moments ago which zeros the total length field of the IP-header for TSO4 operations. I hope this will resolve the issue with VMware. Good luck! Mieze

#2114834 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 24 February 2015 - 11:48 PM

First of all, thanks for the log data! Now let's summarize what we have because there are two different problems caused by VMware:The first problem is, that VMware sometimes messes up the network stack so that you have to use ifconfig up/down in order to revive it. This problem is independent of the driver. The second one is that VMware seems to alter packets in a way so that they cause a transmitter deadlock. As strangeNoises is using the same NIC as I do for development (I217V rev. 5) and the driver is working absolutely stable on my test system, I'm quite sure that VMware is the key to a solution. Although I haven't worked with VMware, I have some experience with Parallels Desktop and VirtualBox. I know that virtualization software installs its own kexts which are deeply interfering with the OS even when no VM is running, making the fact that the deadlocks continue to occur after shutting down the VMs irrelevant.tarasis sent me some log data which he collected with the debug vers...

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