Jump to content

New Driver for Realtek RTL8111


Mieze
1,593 posts in this topic

Recommended Posts

Thanks for the config space dump. Ok, next try. It might have been a wrong rx config. Please try the attached version.

 

Mieze

Same result with this one. No Recv Packets in Network Utility.

Link to comment
Share on other sites

Thanks! Can you please send me a dump of the NIC's memory space (BAR2 + BAR3 form a 64bit memory address) from Windows while the NIC is in operation (link up).

 

Mieze

Link to comment
Share on other sites

Thanks! Can you please send me a dump of the NIC's memory space (BAR2 + BAR3 form a 64bit memory address) from Windows while the NIC is in operation (link up).

 

Mieze

BAR2 is zero (FYI: RW-Everything numbers BAR starting at one). I can send the others (BAR3/BAR5, that look like SystemMemory). How many bytes do you need?

 

FYI: PCI_config was with link down (I was using WiFi).

Link to comment
Share on other sites

256 Bytes are enough because there are no registers beyond this barrier. I've checked the docs again: BAR1 is IO-Space which should be identical to the memory space, BAR2 is unused and BAR3 (lower 32bits) + BAR4 (upper 32bits) form a 64bit memory space address which is the one we need.

 

Mieze

Link to comment
Share on other sites

I found a firm lead. RxMaxSize was set to 2000, the rx buffer size, while windows and linux both use 1523. I changed the register value back to 1523. Let's see if it resolves the issue...

 

Mieze

 

 

P. S.: For the latest code please see http://www.insanelymac.com/forum/topic/287161-new-driver-for-realtek-rtl8111/?p=1991311

Link to comment
Share on other sites

I found a firm lead. RxMaxSize was set to 2000, the rx buffer size, while windows and linux both use 1523. I changed the register value back to 1523. Let's see if it resolves the issue...

 

Mieze

Unfortunately, no change.

Link to comment
Share on other sites

Reviewing the code I discovered a copy & paste error in the initialization sequence. The code for the newer NICs was missing completely so that it couldn't work. Here is the reworked code together with binaries.

 

Mieze

 

P. S.: The more feedback I get, the easier it is to eliminate bugs and improve the code. Therefore I would like to ask anybody with a Realtek GB NIC to test it on her/his system and report back!

 

As I published a newer development release in between the code can be found here: http://www.insanelymac.com/forum/topic/287161-new-driver-for-realtek-rtl8111/page-24?do=findComment&comment=1991840

Edited by Mieze
Link to comment
Share on other sites

Reviewing the code I discovered a copy & paste error in the initialization sequence. The code for the newer NICs was missing completely so that it couldn't work. Here is the reworked code together with binaries.

 

Mieze

Definitely making progress...  This one seems to be working.  Hopefully, this message is posted using the driver on my new Lenovo U430 (first time on internet with OS X on this laptop!).

 

But it isn't stable... the first attempt to post this resulted in a flood of "replaceOrCopyPacket() failed." messages in system.log.  I will continue to test...

 

P.S. So far I've only seen that happen once. And there has only been one repaceOrCopyPacket() message since (after rebooting), and it did not continue and cause a loss of connectivity. I've even done a few downloads from Software Update (itunes update, etc) and they worked. I'll keep an eye on this issue. Wondering if I should switch to the Release build...

Link to comment
Share on other sites

But it isn't stable... the first attempt to post this resulted in a flood of "replaceOrCopyPacket() failed." messages in system.log.  I will continue to test...

 

This is neither a driver nor a stability issue. First, it's a memory allocation error which is outside the scope of the driver and it's self healing because when the packet buffer pool becomes exhausted the kernel increases its size so that the problem should disappear after a while. Second, this is a common problem which can be seen on many machines. On my new development system equipped with an Intel 82574L add-on card using Apple's I82574L.kext, I keep getting this error message too. Third, the network stack can live very well with a few dropped packets due to buffer allocation failure.

 

Therefore I assume that this might be some kind of hackintosh related problem. I noticed the issue on my test machine (Foxconn D42s with Atom D425) too, while my server (MSI B75MA-P45 with i3 3225) hasn't lost a single packet during the last 40 hours. Anyway, in case the problem turns out to be a serious problem, I might tweak the code in order to find a workaround, for example by preallocation of a few packets.

 

Please send me the kernel logs as they could be a starting point for further research.

 

Mieze

Link to comment
Share on other sites

This is neither a driver nor a stability issue. First, it's a memory allocation error which is outside the scope of the driver and it's self healing because when the packet buffer pool becomes exhausted the kernel increases its size so that the problem should disappear after a while. Second, this is a common problem which can be seen on many machines. On my new development system equipped with an Intel 82574L add-on card using Apple's I82574L.kext, I keep getting this error message too. Third, the network stack can live very well with a few dropped packets due to buffer allocation failure.

In this particular case, it killed connectivity completely until a reboot.

 

But when I was researching the SMB issues a while back this was one area I considered... pre-allocating/maintaining a pool of receive buffers is probably a good idea.

 

This machine only has 4GB of RAM, so maybe an issue? Also, I have not upgraded it to 10.9.1 so perhaps there are some bugs fixed in the network stack. I plan to upgrade to 10.9.1 later today...

 

 

Please send me the kernel logs as they could be a starting point for further research.

 

There isn't much in the logs except many replaceOrCopyPacket() errors in rapid and un-ending succession until my reboot... Looks like perhaps a complete failure (corruption?) in the memory pool provided by the base class.

Link to comment
Share on other sites

P. S.: The more feedback I get, the easier it is to eliminate bugs and improve the code. Therefore I would like to ask anybody with a Realtek GB NIC to test it on her/his system and report back!

 

Mieze,

For those of us with older chipsets that were already supported with the previous driver, do you want us to test with this "RealtekRTL8111-V1.2.0-development5.zipor with the original posted version?

 

g\

 

EDIT: looks like your previous posts have been amended to link to that dev5 build so i will use that.

Link to comment
Share on other sites

This machine only has 4GB of RAM, so maybe an issue? Also, I have not upgraded it to 10.9.1 so perhaps there are some bugs fixed in the network stack. I plan to upgrade to 10.9.1 later today...

 

As kernel memory is always physical memory, RAM is probably the key! My test system, the Atom, has to live with only 2 GB but it serves only one purpose: Realtek driver testing so that it seems so work without mayor problems. The server has to live with only 4GB of RAM at the moment too (I pulled 2 DIMMs for the development machine because RAM is quite expensive these days) but it runs without display so that 4 GB might be enough. The development machine (Asrock B85M Pro4 / 4GB) on the other hand is showing more problems. 4GB is simply not enough for a desktop system with HD4600 onboard graphics.

 

Mieze

Mieze,

For those of us with older chipsets that were already supported with the previous driver, do you want us to test with this "RealtekRTL8111-V1.2.0-development5.zipor with the original posted version?

 

g\

 

EDIT: looks like your previous posts have been amended to link to that dev5 build so i will use that.

 

Yes, please! Realtek has restructured the underlying linux driver which affects all NICs, not only the new ones. Think of it as a completely new driver.

 

I removed the older files because I discovered a serious bug in the initializations code making it unsuitable for use with some chipsets so that is makes no sense to provide it for download anymore.

 

Mieze

Link to comment
Share on other sites

As kernel memory is always physical memory, RAM is probably the key! My test system, the Atom, has to live with only 2 GB but it serves only one purpose: Realtek driver testing so that it seems so work without mayor problems. The server has to live with only 4GB of RAM at the moment too (I pulled 2 DIMMs for the development machine because RAM is quite expensive these days) but it runs without display so that 4 GB might be enough. The development machine (Asrock B85M Pro4 / 4GB) on the other hand is showing more problems. 4GB is simply not enough for a desktop system with HD4600 onboard graphics.

I will eventually upgrade this machine to 8GB. But Apple does sell the Haswell MacBookAir with as little as 4GB, so it must be a scenario they test. When you start mixing hackintosh drivers in there, I realize it is not Apple's problem anymore (even if it is!).

 

At any rate, I haven't seen it repeat yet, so maybe it was a fluke. In the kext dev work I've done, I've seen plenty of weird things that happen on first boot after installing new/updated kexts (kernel cache issue?), so maybe it was related to that too...

 

I'll keep an eye on it anyway...

Link to comment
Share on other sites

 

Yes, please! Realtek has restructured the underlying linux driver which affects all NICs, not only the new ones. Think of it as a completely new driver.

 

FYI i am now running this on my z68 system with chipset ID 16 and so far so good. I don't use this system that heavily anymore but i will report any issues i find. So far it seems perfectly stable and performance is great. Let me know if there is anything in particular you would like me to test, otherwise i will just keep using the system as i normally do and be on the lookout for any issues that pop up.

 

g\

Link to comment
Share on other sites

FYI i am now running this on my z68 system with chipset ID 16 and so far so good. I don't use this system that heavily anymore but i will report any issues i find. So far it seems perfectly stable and performance is great. Let me know if there is anything in particular you would like me to test, otherwise i will just keep using the system as i normally do and be on the lookout for any issues that pop up.

 

Thanks, that is exactly what I was hoping to get: experiences from a real world scenario.

 

Mieze

Link to comment
Share on other sites

Thanks, that is exactly what I was hoping to get: experiences from a real world scenario.

 

Mieze

May have spoken too soon. Accessing local network or localhost seems to be working well but i am having a lot of trouble with internet access on this machine:

 

4 18:33:51 Che-Guevara.local ocspd[1767]: tcp_connection_handle_destination_prepare_complete 56 failed to connect
Feb  4 18:33:51 Che-Guevara.local ocspd[1767]: tcp_connection_destination_prepare_complete 57 connectx to 23.7.133.163#80 failed: 64 - Host is down
Feb  4 18:33:51 Che-Guevara.local ocspd[1767]: tcp_connection_handle_destination_prepare_complete 57 failed to connect
Feb  4 18:33:51 Che-Guevara.local Safari[479]: CFNetwork SSLHandshake failed (-9806)
Feb  4 18:33:51 Che-Guevara.local ocspd[1767]: tcp_connection_destination_prepare_complete 58 connectx to 23.7.139.27#80 failed: 64 - Host is down
...
And just goes on and on like this and web pages do not load, update services timeout, etc.
 
Please let me know what i can provide to help troubleshoot.
 
Ignore the above. After updating the driver for some reason the router address went missing from my manual IP settings (it was just blank). The manual ip and subnet mask were still there. Anyway it works fine after putting the router address back in. Nothing to see here..
g\
Link to comment
Share on other sites

 

Ignore the above. After updating the driver for some reason the router address went missing from my manual IP settings (it was just blank). The manual ip and subnet mask were still there. Anyway it works fine after putting the router address back in. Nothing to see here..

 

Well, according to your problem descriptions it was obvious that it must have been a network configuration issue because routing is beyond the scope of the driver. It only handles packets.

 

Mieze

Link to comment
Share on other sites

Hello Mieze

 

I have Gigabyte GA-945GCM-S2L with RTL8111C chip.

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 0x5f51.
unknown chip version (7c800000)
Ethernet [RealtekRTL8111]: RTL8168B/8111B: (Chipset 0) at 0x2e8d1000, ff:ff:ff:ff:ff:ff

More logs...

Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]:Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]:Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
RealtekRTL8111: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]:Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]:Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]:Link up on en0, 1-Gigabit, Full-duplex, flow-control 

Im currently using Realtek original driver, but hoping that your driver will support this.

Link to comment
Share on other sites

Hi Mieze,

 

the chipset 14 is working good by now the only strange thing is that is not getting the right macadress,

 

 

Ethernet [RealtekRTL8111]: RTL8168E/8111E: (Chipset 14) at 0xffffff80ef82e000, aa:aa:aa: 0:52:9e

 

No, it's not normal. Is there a reversal of digits or are there digits which are completely wrong. What's the correct mac address?

 

Mieze

Hello Mieze

 

I have Gigabyte GA-945GCM-S2L with RTL8111C chip.

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 0x5f51.
unknown chip version (7c800000)
Ethernet [RealtekRTL8111]: RTL8168B/8111B: (Chipset 0) at 0x2e8d1000, ff:ff:ff:ff:ff:ff

Something is not right here. According to Realtek there is no chip with this ID. What did you do? Did you built from source? Why did you change the interrupt mitigate value? Have you tried earlier versions of the driver? The 8111C is supported since version 1.0. Please give me more information so that I can track down the issue.

 

Mieze

Link to comment
Share on other sites

@Mieze:

Thanks for the great driver and the ongoing development.

 

RealtekRTL8111-V1.2.0-development5 seems to work fine with an RTL8168, chipset 17. Here is the log:

getFeatures() ===>
getFeatures() <===
createWorkLoop() ===>
createWorkLoop() <===
getWorkLoop() ===>
getWorkLoop() <===
createOutputQueue() ===>
createOutputQueue() <===
getPacketBufferConstraints() ===>
getPacketBufferConstraints() <===
Ethernet [RealtekRTL8111]: PCI power management capabilities: 0xffc3.
Ethernet [RealtekRTL8111]: PME# from D3 (cold) supported.
Ethernet [RealtekRTL8111]: PCIe link capabilities: 0x00077c11, link control: 0x0040.
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]: RTL8168F/8111F: (Chipset 17) at 0xffffff80f5935000, [...]
Ethernet [RealtekRTL8111]: MSI interrupt index: 1
newVendorString() ===>
newVendorString() <===
newModelString() ===>
newModelString() <===
getFeatures() ===>
getFeatures() <===
getPacketFilters() ===>
getPacketFilters() <===
getHardwareAddress() ===>
getHardwareAddress() <===
getPacketFilters() ===>
Ethernet [RealtekRTL8111]: kIOEthernetWakeOnMagicPacket added to filters.
getPacketFilters() <===
getPacketFilters() ===>
getPacketFilters() <===
registerWithPolicyMaker() ===>
registerWithPolicyMaker() <===
setPowerState() ===>
configureInterface() ===>
configureInterface() <===
getFeatures() ===>
getFeatures() <===
getChecksumSupport() ===>
getChecksumSupport() <===
getChecksumSupport() ===>
getChecksumSupport() <===
Ethernet [RealtekRTL8111]: Already in power state 1.
setPowerState() <===
enable() ===>
Ethernet [RealtekRTL8111]: No medium selected. Falling back to autonegotiation.
selectMedium() ===>
selectMedium() <===
setOffset79() ===>
setOffset79() <===
setMulticastMode() ===>
setMulticastMode() <===
enable() <===
setMulticastMode() ===>
setMulticastMode() <===
setMulticastList() ===>
setMulticastList() <===
setMulticastMode() ===>
setMulticastMode() <===
getPacketFilters() ===>
getPacketFilters() <===
getPacketFilters() ===>
getPacketFilters() <===
setMulticastMode() ===>
setMulticastMode() <===
setMulticastList() ===>
setMulticastList() <===
setMulticastList() ===>
setMulticastList() <===
setMulticastList() ===>
setMulticastList() <===
setMulticastList() ===>
setMulticastList() <===
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
getPacketFilters() ===>
getPacketFilters() <===
setMulticastList() ===>
setMulticastList() <===
setMulticastList() ===>
setMulticastList() <===
setMulticastList() ===>
setMulticastList() <===
setMulticastList() ===>
setMulticastList() <===
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.
Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.

Will continue using this version and post, if I notice something.

Link to comment
Share on other sites

Why did you change the interrupt mitigate value? Have you tried earlier versions of the driver?

Might be my fork. My fork uses 0x5f51 for intrMitigate as it works better with the ProBook.

Link to comment
Share on other sites

Mieze

 

It was Rehabman's fork which i built from source. I will try to change the value of interrupt to yours and let you know

 

Thank You!

If you're going to report issues in this thread and ask for help, you should use Mieze's build.

Link to comment
Share on other sites

×
×
  • Create New...