Mieze Posted January 5, 2014 Author Share Posted January 5, 2014 Here it is... https://drive.google.com/file/d/0B0aU-ZPms10nWkpmV3FLMnRHNms/edit?usp=sharing Thanks! According to the logs you are using an old RTL8111B. Which board do you use? Or is it an add-on card? It looks like the chip's transmitter constantly hangs so that the driver issues a reset. Although I received a success report from a user with an RTL8111B last year, I also remember that the same chip refused to work on an add-in card and I never managed to find out what the problem was. Mieze Link to comment Share on other sites More sharing options...
Chicura Posted January 5, 2014 Share Posted January 5, 2014 Thanks! According to the logs you are using an old RTL8111B. Which board do you use? Or is it an add-on card? It looks like the chip's transmitter constantly hangs so that the driver issues a reset. Although I received a success report from a user with an RTL8111B last year, I also remember that the same chip refused to work on an add-in card and I never managed to find out what the problem was. Mieze It's an Acer Aspire V5-573G-54208G50aii; the netowrk adapter is onboard on an Intel Lynx Point-LP Mainboard with Haswell Intel Core i5-4200U. Is the adapter always recognized correctly or might it be mistaken by wrong dsdt information? Will there be a chance to have this driver working for this adapter in the future? In earlier OSX versions I found a driver named RTGMac but it isn't working in Mavericks. Link to comment Share on other sites More sharing options...
Mieze Posted January 5, 2014 Author Share Posted January 5, 2014 It's an Acer Aspire V5-573G-54208G50aii; the netowrk adapter is onboard on an Intel Lynx Point-LP Mainboard with Haswell Intel Core i5-4200U. Is the adapter always recognized correctly or might it be mistaken by wrong dsdt information? Now I understand! No, it's not an old RTL8111B but a newer member of the family which is currently unsupported by the driver so that it falls back to the default chipset, the original 8111B. That's the reason why it refuses to work. Well, you'll have to wait until I find some time to update the driver with the latest linux sources from Realtek in order to add support for your chip too. Originally I was planing to do it over the christmas holidays but still haven't found enough time for the job. Currently I'm still working on one of my iOS projects but as soon as it will be finished I will take care of the driver update. Expect a first development release to be available by the end of the month. Mieze 5 Link to comment Share on other sites More sharing options...
Scoliosis Posted January 6, 2014 Share Posted January 6, 2014 I have a weird problem with this driver in Mavericks. My hackintosh uses a Realtek 8168E/8111E-VL chipset. Ethernet [RealtekRTL8111]: EEE support enabled. Ethernet [RealtekRTL8111]: TCP/IPv4 segmentation offload enabled. Ethernet [RealtekRTL8111]: TCP/IPv6 checksum offload enabled. Ethernet [RealtekRTL8111]: Using interrupt mitigate value 0xcf68. Ethernet [RealtekRTL8111]: RTL8168E-VL/8111E-VL: (Chipset 16) at 0xffffff837bd01000, 50:e5:49:52:c7:7d Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control This is the contents of my /etc/sysctl.conf net.inet.tcp.delayed_ack=2 net.inet.raw.maxdgram=16384 net.inet.raw.recvspace=16384 net.link.ether.inet.arp_unicast_lim=0 I haven't figured out how to disable hardware checksum offload. This sysctl - net.link.ether.inet.apple_hwcksum_rx says that it is read-only. First let's do iperf from this Mac to a FreeNAS box on a 1Gbps, Full-Duplex line. Server - [user@freenas] ~# iperf -s -w 1024k ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 1.00 MByte ------------------------------------------------------------ [ 4] local 192.168.1.20 port 5001 connected with 192.168.1.3 port 49687 [ ID] Interval Transfer Bandwidth [ 4] 0.0-15.2 sec 48.5 MBytes 26.7 Mbits/sec Client - user$ ./iperf -c 192.168.1.20 -w 1024k ------------------------------------------------------------ Client connecting to 192.168.1.20, TCP port 5001 TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) ------------------------------------------------------------ [ 4] local 192.168.1.3 port 49687 connected with 192.168.1.20 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0-13.1 sec 48.5 MBytes 31.2 Mbits/sec Nothing is accessing the network on the Mac client at the time. Nothing is connected to the NAS either at the time. Both machines are idle. Interconnect is a 1Gbps switch. Tried using a crossover cable and the result is the same. The interesting thing is during the transfer, there is substantial variation in ping times, from 1-5ms to 1000-2000ms and with some unreplied ones too. Ping times - user$ ping 192.168.1.20 PING 192.168.1.20 (192.168.1.20): 56 data bytes 64 bytes from 192.168.1.20: icmp_seq=0 ttl=64 time=4.132 ms Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=2002.999 ms 64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=1002.338 ms 64 bytes from 192.168.1.20: icmp_seq=3 ttl=64 time=1.338 ms 64 bytes from 192.168.1.20: icmp_seq=4 ttl=64 time=1462.177 ms 64 bytes from 192.168.1.20: icmp_seq=5 ttl=64 time=461.287 ms 64 bytes from 192.168.1.20: icmp_seq=6 ttl=64 time=3.972 ms 64 bytes from 192.168.1.20: icmp_seq=7 ttl=64 time=2002.231 ms 64 bytes from 192.168.1.20: icmp_seq=8 ttl=64 time=1002.152 ms 64 bytes from 192.168.1.20: icmp_seq=9 ttl=64 time=1.174 ms 64 bytes from 192.168.1.20: icmp_seq=10 ttl=64 time=2003.134 ms 64 bytes from 192.168.1.20: icmp_seq=11 ttl=64 time=1002.203 ms 64 bytes from 192.168.1.20: icmp_seq=12 ttl=64 time=1.179 ms 64 bytes from 192.168.1.20: icmp_seq=13 ttl=64 time=1002.582 ms 64 bytes from 192.168.1.20: icmp_seq=14 ttl=64 time=1.568 ms 64 bytes from 192.168.1.20: icmp_seq=15 ttl=64 time=0.239 ms 64 bytes from 192.168.1.20: icmp_seq=16 ttl=64 time=0.231 ms 64 bytes from 192.168.1.20: icmp_seq=17 ttl=64 time=0.264 ms 64 bytes from 192.168.1.20: icmp_seq=18 ttl=64 time=0.146 ms Once the transfer is complete, it drops back down to sub millisecond response time. Now, the ping time spike is only to that particular machine. If I were to ping something else on the network, they all come back with sub millisecond response. Next test is transferring a file over NFS protocol (Mac -> NAS). It starts off at a decent speed, then after about 10 seconds, it drops off. Estimates 4 minutes to transfer a 200MB file. Doing the reverse in traffic direction does not show a problem. Server (Mac) - user$ ./iperf -s -w 1024k ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 1.00 MByte ------------------------------------------------------------ [ 4] local 192.168.1.3 port 5001 connected with 192.168.1.20 port 34362 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 957 MBytes 802 Mbits/sec Client (NAS) - [user@freenas] ~# iperf -c 192.168.1.3 -w 1024k ------------------------------------------------------------ Client connecting to 192.168.1.3, TCP port 5001 TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) ------------------------------------------------------------ [ 3] local 192.168.1.20 port 47908 connected with 192.168.1.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 957 MBytes 803 Mbits/sec NFS copy works really well as well, so no problems there. Any suggestion on what might be the problem? This does not occur when running in OSX Lion. Link to comment Share on other sites More sharing options...
RehabMan Posted January 6, 2014 Share Posted January 6, 2014 ... Not sure if it will help, but maybe run the same test using my fork of this driver instead. I did some work on it to fix some perf issues with SMB (so not really related to your situation with NFS/iperf). But still worth a test... See here: https://github.com/RehabMan/OS-X-Realtek-Network Note: I see I really wasn't very good at updating the changelog past a certain point, so read the commit descriptions if you're interested... Link to comment Share on other sites More sharing options...
Mieze Posted January 6, 2014 Author Share Posted January 6, 2014 I have a weird problem with this driver in Mavericks. My hackintosh uses a Realtek 8168E/8111E-VL chipset. Ethernet [RealtekRTL8111]: EEE support enabled. Ethernet [RealtekRTL8111]: TCP/IPv4 segmentation offload enabled. Ethernet [RealtekRTL8111]: TCP/IPv6 checksum offload enabled. Ethernet [RealtekRTL8111]: Using interrupt mitigate value 0xcf68. Ethernet [RealtekRTL8111]: RTL8168E-VL/8111E-VL: (Chipset 16) at 0xffffff837bd01000, 50:e5:49:52:c7:7d Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control This is the contents of my /etc/sysctl.conf net.inet.tcp.delayed_ack=2 net.inet.raw.maxdgram=16384 net.inet.raw.recvspace=16384 net.link.ether.inet.arp_unicast_lim=0 I haven't figured out how to disable hardware checksum offload. This sysctl - net.link.ether.inet.apple_hwcksum_rx says that it is read-only. First let's do iperf from this Mac to a FreeNAS box on a 1Gbps, Full-Duplex line. Server - [user@freenas] ~# iperf -s -w 1024k ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 1.00 MByte ------------------------------------------------------------ [ 4] local 192.168.1.20 port 5001 connected with 192.168.1.3 port 49687 [ ID] Interval Transfer Bandwidth [ 4] 0.0-15.2 sec 48.5 MBytes 26.7 Mbits/sec Client - user$ ./iperf -c 192.168.1.20 -w 1024k ------------------------------------------------------------ Client connecting to 192.168.1.20, TCP port 5001 TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) ------------------------------------------------------------ [ 4] local 192.168.1.3 port 49687 connected with 192.168.1.20 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0-13.1 sec 48.5 MBytes 31.2 Mbits/sec Nothing is accessing the network on the Mac client at the time. Nothing is connected to the NAS either at the time. Both machines are idle. Interconnect is a 1Gbps switch. Tried using a crossover cable and the result is the same. The interesting thing is during the transfer, there is substantial variation in ping times, from 1-5ms to 1000-2000ms and with some unreplied ones too. Ping times - user$ ping 192.168.1.20 PING 192.168.1.20 (192.168.1.20): 56 data bytes 64 bytes from 192.168.1.20: icmp_seq=0 ttl=64 time=4.132 ms Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=2002.999 ms 64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=1002.338 ms 64 bytes from 192.168.1.20: icmp_seq=3 ttl=64 time=1.338 ms 64 bytes from 192.168.1.20: icmp_seq=4 ttl=64 time=1462.177 ms 64 bytes from 192.168.1.20: icmp_seq=5 ttl=64 time=461.287 ms 64 bytes from 192.168.1.20: icmp_seq=6 ttl=64 time=3.972 ms 64 bytes from 192.168.1.20: icmp_seq=7 ttl=64 time=2002.231 ms 64 bytes from 192.168.1.20: icmp_seq=8 ttl=64 time=1002.152 ms 64 bytes from 192.168.1.20: icmp_seq=9 ttl=64 time=1.174 ms 64 bytes from 192.168.1.20: icmp_seq=10 ttl=64 time=2003.134 ms 64 bytes from 192.168.1.20: icmp_seq=11 ttl=64 time=1002.203 ms 64 bytes from 192.168.1.20: icmp_seq=12 ttl=64 time=1.179 ms 64 bytes from 192.168.1.20: icmp_seq=13 ttl=64 time=1002.582 ms 64 bytes from 192.168.1.20: icmp_seq=14 ttl=64 time=1.568 ms 64 bytes from 192.168.1.20: icmp_seq=15 ttl=64 time=0.239 ms 64 bytes from 192.168.1.20: icmp_seq=16 ttl=64 time=0.231 ms 64 bytes from 192.168.1.20: icmp_seq=17 ttl=64 time=0.264 ms 64 bytes from 192.168.1.20: icmp_seq=18 ttl=64 time=0.146 ms Once the transfer is complete, it drops back down to sub millisecond response time. Now, the ping time spike is only to that particular machine. If I were to ping something else on the network, they all come back with sub millisecond response. Next test is transferring a file over NFS protocol (Mac -> NAS). It starts off at a decent speed, then after about 10 seconds, it drops off. Estimates 4 minutes to transfer a 200MB file. Doing the reverse in traffic direction does not show a problem. Server (Mac) - user$ ./iperf -s -w 1024k ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 1.00 MByte ------------------------------------------------------------ [ 4] local 192.168.1.3 port 5001 connected with 192.168.1.20 port 34362 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 957 MBytes 802 Mbits/sec Client (NAS) - [user@freenas] ~# iperf -c 192.168.1.3 -w 1024k ------------------------------------------------------------ Client connecting to 192.168.1.3, TCP port 5001 TCP window size: 1.00 MByte (WARNING: requested 1.00 MByte) ------------------------------------------------------------ [ 3] local 192.168.1.20 port 47908 connected with 192.168.1.3 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 957 MBytes 803 Mbits/sec NFS copy works really well as well, so no problems there. Any suggestion on what might be the problem? This does not occur when running in OSX Lion. Compare the output of sysctl -a while running Mavericks with the output under Lion. Please tell me more about your NAS hardware (CPU, mainboard, NIC) and OS. Serious performance problems usually originate in wrong network related settings. Therefore your first step should be to check the configuration. As I'm setting up a new development machine with an Asrock B85M Pro4, I had the chance to run some performance tests with an Intel NIC (i217V) under Win7 using SMB (the issue RehabMan described) and was able to improve throughput dramatically with optimized settings on the Win 7 machine. I will publish the results later because I'm preparing my dinner now. Mieze Link to comment Share on other sites More sharing options...
Scoliosis Posted January 6, 2014 Share Posted January 6, 2014 The NAS has the same hardware as my hackintosh. Gigabyte Z68P-DS3 F9 motherboard. Core i5 2500K 16GB RAM Freenas 9.1.1 I took your advice and started dumping values and config output from Lion into text file to compare against Mavericks. While copy and pasting I found the culprit. TSO was not enabled in Lion but is enabled on Mavericks. Once I disable it by using "ifconfig en0 -tso" things went back up to line speed but with a spike in CPU utilization. Will have to investigate more as I see it disabled on the NAS as well. I'll also test with my work MBP when I bring it back from the office tomorrow. For now, let's consider this issue resolved. Link to comment Share on other sites More sharing options...
Mieze Posted January 7, 2014 Author Share Posted January 7, 2014 As already announced, here are the results of my latest performance test with SMB while communicating with a Windows machine equipped with an Intel NIC. On the OS X side I used my home server: MSI B75MA-P45 (with RTL8111E-VL using version 1.1.3 of my driver) Core i3 3225 4 GB RAM OS X 10.8.5 Server My new development system, which acted as a client in the setup, has the following configuration: Asrock B85M Pro4 (with Intel i217V) Core i5 4570 4 GB RAM Windows 7 / 64 Bit (clean install with latest drivers from Asrock and all Windows updates installed) On the OS X side I use net.inet.tcp.delayed_ack: 2 which is best when communicating with Windows and the default value on the server version of OS X. Please note the the client version uses 3 as the default value. In order to test throughput I copied a 2GB file from/to the server using Windows Explorer. With the default settings throughput was quite low. I got data rates between 10-20 MB/sec with sudden drops to less than 10 MB/sec. After some experimenting I disabled the "QoS Packet Scheduler" for the LAN connection on the Win 7 machine. I also increased the number of RSS queues from 1 to 2 in the configuration options of the Intel driver. After applying these settings I experienced a nice speed bump: Read: 50-60 MB/sec stable Write: 25-35 MB/sec stable Mieze TSO was not enabled in Lion but is enabled on Mavericks. Once I disable it by using "ifconfig en0 -tso" things went back up to line speed but with a spike in CPU utilization. TSO lets the NIC segment large TCP packets before sending them out to the cable which reduces CPU load but of course makes timing of packet transmission less predictable. That's why I assume that your problems are due to a timing issue. On linux the r8169 driver has TSO disabled as it's default, because of bad performance in some situations but I don't know the exact context where this happens. On the Mac I haven't heard of any TSO related errors before which makes it an interesting question to find out what exactly happens. Mieze Link to comment Share on other sites More sharing options...
Scellow Posted January 12, 2014 Share Posted January 12, 2014 Thanks a lot Mieze! As my 8105E doesn't work well i bought this little one for less than 7,58€ : http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=120907841615&ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 It's the 8111D chipset , and it's fully compatible with your driver, thanks a lot! Link to comment Share on other sites More sharing options...
longxinmengfei Posted January 14, 2014 Share Posted January 14, 2014 thanks,let me have a try on Mavericks Link to comment Share on other sites More sharing options...
vaslobas Posted January 14, 2014 Share Posted January 14, 2014 Hello. Any progress with 8105E? There datasheet for it http://rghost.ru/51660482 Link to comment Share on other sites More sharing options...
Mieze Posted January 14, 2014 Author Share Posted January 14, 2014 Hello. Any progress with 8105E? There datasheet for it http://rghost.ru/51660482 This driver is based on Realtek's r8168 driver for their Gigabit Ethernet NICs and doesn't support FE devices. Therefore I won't add support for their FE device family in the future because it would make it more difficult to merge in updates of the underlining linux code. In case anyone is interested to write a dedicated driver for 810x series I will certainly support this effort as much as I can. Mieze Link to comment Share on other sites More sharing options...
nirmodel50 Posted January 16, 2014 Share Posted January 16, 2014 Hi I have a problem with the sleep. When the machine gets up the name is changed and I can't find my music library. Is it possible that the driver forget to release the name before sleep or something like that? Thanks for the driver. Link to comment Share on other sites More sharing options...
Mieze Posted January 16, 2014 Author Share Posted January 16, 2014 Hi I have a problem with the sleep. When the machine gets up the name is changed and I can't find my music library. Is it possible that the driver forget to release the name before sleep or something like that? Thanks for the driver. No, because all the DHCP related stuff is part of the network stack, not of the driver. Looks like you have a problem with your DHCP server? Please check its logs? You can also send me a copy of your kernel logs as I might find some piece of information what exactly happens on wakeup. Mieze Link to comment Share on other sites More sharing options...
skong125 Posted January 17, 2014 Share Posted January 17, 2014 Hi, I'm having difficulty getting the driver to work on my build, I'm using a Realtek RTL8111G controller on the ASUS H81i-plus Motherboard. I tried installing the kext onto a clean Snow Leopard OS, but the Ethernet is still not working, and I'm at a lost. Any help will be appreciated. System log.txt Link to comment Share on other sites More sharing options...
Mieze Posted January 17, 2014 Author Share Posted January 17, 2014 Hi, I'm having difficulty getting the driver to work on my build, I'm using a Realtek RTL8111G controller on the ASUS H81i-plus Motherboard. I tried installing the kext onto a clean Snow Leopard OS, but the Ethernet is still not working, and I'm at a lost. Any help will be appreciated. Jan 16 21:15:03 Zi-Yings-Mac-Pro com.apple.kextd[10]: Can't load /System/Library/Extensions/RealtekRTL8111.kext - no code for running kernel's architecture. You need at least 10.7 and a system running in 64bit mode for the kext to work because the driver doesn't support 32bit architecture. Mieze Link to comment Share on other sites More sharing options...
RehabMan Posted January 18, 2014 Share Posted January 18, 2014 Hi, I'm having difficulty getting the driver to work on my build, I'm using a Realtek RTL8111G controller on the ASUS H81i-plus Motherboard. I tried installing the kext onto a clean Snow Leopard OS, but the Ethernet is still not working, and I'm at a lost. Any help will be appreciated. My fork will work on 10.6.8. See: https://github.com/RehabMan/OS-X-Realtek-Network I've even had someone claim that 32-bit works on SL. I do not provide 32-bit builds and don't support them so you will have to build it yourself (requires xcode 4... xcode5 is pretty broken when it comes to 32-bit support). Use 'make BITS=32' or 'make BITS=3264'. But if you're running SL 64-bit, you can just use the binaries I make available for download. Link to comment Share on other sites More sharing options...
cee`o Posted January 20, 2014 Share Posted January 20, 2014 Hi, Mieze. I have a problem with the write speed of the NAS D-Link DNS-315, it is practically zero. Speed reading is normal. Mac OS 10.9.1, Realtek 8111C, driver version 1.1.3 P.S. Sorry for my english. I use Google Translate. Link to comment Share on other sites More sharing options...
Mieze Posted January 20, 2014 Author Share Posted January 20, 2014 Hi, Mieze. I have a problem with the write speed of the NAS D-Link DNS-315, it is practically zero. Speed reading is normal. Mac OS 10.9.1, Realtek 8111C, driver version 1.1.3 P.S. Sorry for my english. I use Google Translate. Well, I guess there isn't much to configure on the NAS with regard to the network so that you can only change the configuration on the OS X machine. Try to disable TSO in the drivers Info.plist. Mieze Link to comment Share on other sites More sharing options...
ramdass Posted January 21, 2014 Share Posted January 21, 2014 Hello Mieze: I tried your driver, following the instructions on the first page, and I have now lost Ethernet as an option in the Network settings: I deleted the Lynx2Mac driver, and the Apple8169 inside the NetworkFamily kext. Then I repaired permissions and updated the cache with Kext Utility. I removed the ethernet setting in the Network Preferance panemad restarted., I installed version 1.1.3 of your driver into S/L/E using Kext Utility. Restared again. Then I went to the Network Panel, but there was no Ethernet option available. Clicking on the '+' button to add a new service the only options available were 'PPPoE', 'VPN' and '6 to 4'. I double and triple checked the Ethernet wiring and the router. All OK, but the OS does not see the router. I tried again using version 1.1.2 and installing with Kext Wizard. Same negative result. Here are the relevant lines from the kernal log: Jan 20 12:51:17 Jacks-Mac-Pro kernel[0]: kxld[com.insanelymac.RealtekRTL8111]: The Mach-O file is malformed: Invalid segment type in MH_KEXT_BUNDLE kext: 42.Jan 20 12:51:17 Jacks-Mac-Pro kernel[0]: Can't load kext com.insanelymac.RealtekRTL8111 - link failed.Jan 20 12:51:17 Jacks-Mac-Pro kernel[0]: Failed to load executable for kext com.insanelymac.RealtekRTL8111.Jan 20 12:51:17 Jacks-Mac-Pro kernel[0]: Kext com.insanelymac.RealtekRTL8111 failed to load (0xdc008016).Jan 20 12:51:17 Jacks-Mac-Pro kernel[0]: Failed to load kext com.insanelymac.RealtekRTL8111 (error 0xdc008016).Jan 20 12:51:17 Jacks-Mac-Pro kernel[0]: DSMOS has arrived This with the 1.1.2 version, but I checked it with 1.1.3 and it said the same thing. Since then, in hopes of regaining an Ethernet setting, I have installed every RTL8111 driver I could find, one by one, refreshing the cache, restarting etc. between each. I've tried RehabMan's fork, Slice's driver, the 10.7 Mac driver from the Realtek site. None of those brought the Ethernet setting back, and booting with any of them left no traces in the kernal log, (unlike your driver). I am now at a loss as to how to proceed. Do you have any idea how I can get the Ethernet option back? If I can get it back, I will try the RehabMan, Slice and Realtek drivers without deleting the service, and see what happens. This is a new install of Lion 10.7.5 on a GA-EP35-DS3P mobo, which has a 8111B chip, according to the Gigabyte webpage. The Ethernet was NOT working on this install, in which I had initially installed the Lynx2Mac driver from the Lion version of #####. That is why I went searching on the web for solutions, found this thread, and seemingly deepened my predicament. I am using the Chameleon bootloader. I have turned of the npci=x3000 flag, and tried things both with 'Built In Ethernet' enabled and disabled. Any suggestions? (Please?) Link to comment Share on other sites More sharing options...
Mieze Posted January 21, 2014 Author Share Posted January 21, 2014 A quick Google search indicates that this happens when you build a kext for Lion using the 10.8 SDK and 10.8 as deployment target. Here is a prebuilt version made with SDK 10.7 for Lion. The archive contains the debug and release versions as well as the sources. Please try this! Mieze RealtekRTL8111-Built_with_SDK10_7.zip Link to comment Share on other sites More sharing options...
Philip Petev Posted January 21, 2014 Share Posted January 21, 2014 A quick Google search indicates that this happens when you build a kext for Lion using the 10.8 SDK and 10.8 as deployment target. Here is a prebuilt version made with SDK 10.7 for Lion. The archive contains the debug and release versions as well as the sources. Please try this! Mieze Isn't it enough only the deployment target to be changed (regardless the SDK)? In most of the cases should do. Link to comment Share on other sites More sharing options...
Mieze Posted January 21, 2014 Author Share Posted January 21, 2014 Isn't it enough only the deployment target to be changed (regardless the SDK)? In most of the cases should do. In theory you are right but in practice, for example when trying to build for Snow Leopard, it often fails. Mieze Link to comment Share on other sites More sharing options...
RehabMan Posted January 21, 2014 Share Posted January 21, 2014 In theory you are right but in practice, for example when trying to build for Snow Leopard, it often fails. Mieze Correct. My fork of this kext uses the 10.6 kext, targets 10.6. Same binary works with SL->Mavs. If Apple did their headers correctly (use the pre-processor appropriately), deployment target would affect the content of the headers. Unfortunately, they don't do that, so one must pay careful attention to the changes from one SDK to another and always test on the intended target. My guess is they don't want to do the testing (of the SDK) that would be required. IOEthernetController/IONetworkController are a couple of classes that have changed in incompatible ways from SL->Mavs, such that you must use the SDK that matches your deployment target. A binary with an older deployment target, of course, is usually compatible with newer versions, as there is mechanisms in the IOKit for backward compatibility (that is, OS X is backward compatible with kexts compiled against old headers). All of these problems really stem from using C++ base classes as a driver framework. This is one area that Microsoft actually got right with COM interfaces. With COM interfaces, vtable structure/interface contract is immutable once released and identified by GUID. If extensions need be made, a new interface is added with a new GUID. On its face, it is seems unnecessarily complex, but when it comes to successfully versioning the interfaces, it is much more sane than Apple's IOKit. Link to comment Share on other sites More sharing options...
drakoon Posted January 22, 2014 Share Posted January 22, 2014 hello os x 10.9.1 PCI (00|05:00.00) : 10EC 8168 class=020000 driver ver. 1.1.3 not working system.log: Jan 22 21:09:49 localhost com.apple.kextd[43]: kext com.insanelymac.RealtekRTL8111 101039000 is in exception list, allowing to load Jan 22 21:09:49 localhost kernel[0]: RealtekR1000: init Jan 22 21:09:49 localhost kernel[0]: RealtekR1000: start Jan 22 21:09:49 localhost kernel[0]: RealtekR1000: R1000InitBoard @ PCI 0x1,00 Jan 22 21:09:49 localhost kernel[0]: RTL8xxx@0xfffc: Realtek RTL8168C/8111C_3 (mcfg 19) Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: PCI power management unsupported. Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: EEE support enabled. Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv4 segmentation offload enabled. Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv6 checksum offload enabled. Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: Using interrupt mitigate value 0xcf68. Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: RTL8168C/8111C: (Chipset 5) at 0xffffff808eec6000, 0:e0:4c:80:1a:50 Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: Warning: MSI index was not found or MSI interrupt could not be enabled. Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: Error initializing event sources. Jan 22 21:09:49 localhost kernel[0]: Ethernet [RealtekRTL8111]: initEventSources() failed. Link to comment Share on other sites More sharing options...
Recommended Posts