Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
Mieze

New Driver for Realtek RTL8111

1,325 posts in this topic

Recommended Posts

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

...

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...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?)

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×