Jump to content

New Driver for Realtek RTL8111

Mieze

By Mieze,
in LAN and Wireless

 Share
1,592 posts in this topic

Recommended Posts

Mieze
Mieze
Posted
  • Author
Posted

Hello dmazar,

 

do you have any new results with regard to the windows issue? I'm currently preparing release 1.0.2 in which I will add rx checksum offload for TCP and UDP over IPv6.

 

Mieze

Link to comment
Share on other sites
dmazar
dmazar
Posted
Posted

Hello dmazar,

do you have any new results with regard to the windows issue? I'm currently preparing release 1.0.2 in which I will add rx checksum offload for TCP and UDP over IPv6.

Mieze

Hi Mieze. Nothing from me unfortunately. No time and no enough knowledge. :(

 

I hope somebody will resolve this annoying thing since I want to use your driver.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Hello dmazar,

 

please try this. Good luck!

 

Mieze

 

Tested here... and it works fine after warm boot from Win7! Nice work, I think you fixed it... I will now do some more testing (warm boot after Linux, cold boot, etc).

 

(edit)Tested:

- cold boot to OS X

- cold boot to Windows; warm to OS X

- warm to Windows; warm to OS X

- cold to Linux; warm to OS X

- warm to Linux; warm to OS X

 

All work: Windows 7, Ubuntu 12.04LTS.

 

(edit) Got to love that -- one line of code:


   /* Set RxMaxSize register */
   WriteReg16(RxMaxSize, kRxBufferPktSize);

  • Like 1
Link to comment
Share on other sites
dmazar
dmazar
Posted
Posted

Hi Mieze. Based on RehabMan's test and on some tests here on my ProBook it looks you found the solution. I'll check it later today on my desktop and then we'll celebrate. :)

 

I can not check it fully on my ProBook because I got another issue. In 90 % of the cases when I start OSX with your driver, Ethernet ends up with "Cable unplugged". I need to reset the router or wait 3-5 minutes until link get's recognised as up and running. See here:


4/24/13 2:00:14.000 PM kernel[0]: PMAP: PCID enabled
4/24/13 2:00:14.000 PM kernel[0]: Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64
...
4/24/13 2:00:16.000 PM kernel[0]: getFeatures() ===>
4/24/13 2:00:16.000 PM kernel[0]: getFeatures() <===
4/24/13 2:00:16.000 PM kernel[0]: createWorkLoop() ===>
4/24/13 2:00:16.000 PM kernel[0]: createWorkLoop() <===
4/24/13 2:00:16.000 PM kernel[0]: getWorkLoop() ===>
4/24/13 2:00:16.000 PM kernel[0]: getWorkLoop() <===
4/24/13 2:00:16.000 PM kernel[0]: createOutputQueue() ===>
4/24/13 2:00:16.000 PM kernel[0]: createOutputQueue() <===
4/24/13 2:00:16.000 PM kernel[0]: getPacketBufferConstraints() ===>
4/24/13 2:00:16.000 PM kernel[0]: getPacketBufferConstraints() <===
4/24/13 2:00:16.000 PM kernel[0]: PCI:
4/24/13 2:00:16.000 PM kernel[0]: 00: ec 10 68 81 07 00 10 00 06 00 00 02 10 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 10: 01 20 00 00 00 00 00 00 0c 40 00 a0 0f 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 20: 0c 00 00 a0 0f 00 00 00 00 00 00 00 3c 10 7c 16
4/24/13 2:00:16.000 PM kernel[0]: 30: 00 00 00 00 40 00 00 00 00 00 00 00 11 01 00 00
4/24/13 2:00:16.000 PM kernel[0]: 40: 01 50 c3 ff 08 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 50: 05 70 80 00 00 00 e0 fe 00 00 00 00 95 40 00 00
4/24/13 2:00:16.000 PM kernel[0]: 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 70: 10 b0 02 02 c1 8c 90 05 10 20 10 00 11 3c 07 00
4/24/13 2:00:16.000 PM kernel[0]: 80: 43 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 90: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: b0: 11 d0 03 00 04 00 00 00 04 08 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: d0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: PCI power management capabilities: 0xffc3.
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: PME# from D3 (cold) supported.
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: PCIe link capabilities: 0x00073c11, link control: 0x0143.
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: Warning: PCIe ASPM enabled.
4/24/13 2:00:16.000 PM kernel[0]: IOMem: 0xffffff80a708e000
4/24/13 2:00:16.000 PM kernel[0]: 00: 10 1f 74 fe 39 31 00 00 ff ff ff ff c0 02 80 00
4/24/13 2:00:16.000 PM kernel[0]: 10: 00 f0 79 05 00 00 00 00 78 00 00 00 a8 d2 ea 93
4/24/13 2:00:16.000 PM kernel[0]: 20: 00 b0 18 26 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 40: 00 00 20 2f 0e 07 02 00 eb 50 eb 93 3d 54 eb 93
4/24/13 2:00:16.000 PM kernel[0]: 50: 01 08 0f 18 60 54 82 01 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 60: 00 18 00 00 00 00 00 01 18 31 00 00 00 00 80 70
4/24/13 2:00:16.000 PM kernel[0]: 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24 4b
4/24/13 2:00:16.000 PM kernel[0]: 80: 00 60 05 00 00 00 00 00 86 0d ec 93 07 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: d0: e0 9e 81 3c 00 00 00 00 00 00 00 07 00 fe 73 82
4/24/13 2:00:16.000 PM kernel[0]: e0: 60 20 00 00 00 f0 18 26 00 00 00 00 2f 00 ff ff
4/24/13 2:00:16.000 PM kernel[0]: f0: 3f 80 00 04 00 00 00 00 ff ff 03 00 00 00 00 00
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: EEE support enabled
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: RTL8168E/8111E: (Chipset 14) at 0xffffff80a708e000, 10:1f:74:fe:39:31
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: MSI interrupt index: 1
4/24/13 2:00:16.000 PM kernel[0]: newVendorString() ===>
4/24/13 2:00:16.000 PM kernel[0]: newVendorString() <===
4/24/13 2:00:16.000 PM kernel[0]: newModelString() ===>
4/24/13 2:00:16.000 PM kernel[0]: newModelString() <===
4/24/13 2:00:16.000 PM kernel[0]: getFeatures() ===>
4/24/13 2:00:16.000 PM kernel[0]: getFeatures() <===
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() ===>
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() <===
4/24/13 2:00:16.000 PM kernel[0]: getHardwareAddress() ===>
4/24/13 2:00:16.000 PM kernel[0]: getHardwareAddress() <===
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() ===>
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: kIOEthernetWakeOnMagicPacket added to filters.
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() <===
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() ===>
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() <===
4/24/13 2:00:16.000 PM kernel[0]: registerWithPolicyMaker() ===>
4/24/13 2:00:16.000 PM kernel[0]: registerWithPolicyMaker() <===
4/24/13 2:00:16.000 PM kernel[0]: setPowerState() ===>
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: Already in power state 1.
4/24/13 2:00:16.000 PM kernel[0]: configureInterface() ===>
4/24/13 2:00:16.000 PM kernel[0]: setPowerState() <===
4/24/13 2:00:16.000 PM kernel[0]: configureInterface() <===
4/24/13 2:00:16.000 PM kernel[0]: RTL8111: Ethernet address 10:1f:74:fe:39:31
4/24/13 2:00:16.000 PM kernel[0]: getFeatures() ===>
4/24/13 2:00:16.000 PM kernel[0]: getFeatures() <===
4/24/13 2:00:16.000 PM kernel[0]: getChecksumSupport() ===>
4/24/13 2:00:16.000 PM kernel[0]: getChecksumSupport() <===
4/24/13 2:00:16.000 PM kernel[0]: getChecksumSupport() ===>
4/24/13 2:00:16.000 PM kernel[0]: getChecksumSupport() <===
4/24/13 2:00:16.000 PM kernel[0]: enable() ===>
4/24/13 2:00:16.000 PM kernel[0]: Ethernet [RealtekRTL8111]: No medium selected. Falling back to autonegotiation.
4/24/13 2:00:16.000 PM kernel[0]: selectMedium() ===>
4/24/13 2:00:16.000 PM kernel[0]: selectMedium() <===
4/24/13 2:00:16.000 PM kernel[0]: setOffset79() ===>
4/24/13 2:00:16.000 PM kernel[0]: setOffset79() <===
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() ===>
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() <===
4/24/13 2:00:16.000 PM kernel[0]: enable() <===
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() ===>
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() <===
4/24/13 2:00:16.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:00:16.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() ===>
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() <===
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() ===>
4/24/13 2:00:16.000 PM kernel[0]: getPacketFilters() <===
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() ===>
4/24/13 2:00:16.000 PM kernel[0]: setMulticastMode() <===
4/24/13 2:00:16.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:00:16.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:00:16.000 PM kernel[0]: 12.595371: setWOW_PARAMETERS:wowevents = 2(1)
4/24/13 2:00:16.000 PM kernel[0]: Transcript Offline - Buffer Pool Allocate [181000] failed
...
!!! Reset router or wait 3-5 minutes !!!
...
4/24/13 2:01:32.000 PM kernel[0]: getPacketFilters() ===>
4/24/13 2:01:32.000 PM kernel[0]: getPacketFilters() <===
4/24/13 2:01:32.000 PM kernel[0]: 87.930267: setWOW_PARAMETERS:wowevents = 0(0)
4/24/13 2:01:54.000 PM kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 100-Megabit, Full-duplex, flow-control
4/24/13 2:01:54.000 PM kernel[0]: getPacketFilters() ===>
4/24/13 2:01:54.000 PM kernel[0]: getPacketFilters() <===
4/24/13 2:01:54.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:01:54.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:01:54.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:01:54.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:01:54.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:01:54.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:01:56.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:01:56.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:01:56.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:01:56.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:01:56.000 PM kernel[0]: setMulticastList() ===>
4/24/13 2:01:56.000 PM kernel[0]: setMulticastList() <===
4/24/13 2:02:02.000 PM kernel[0]: getPacketFilters() ===>
4/24/13 2:02:02.000 PM kernel[0]: getPacketFilters() <===
4/24/13 2:02:02.000 PM kernel[0]: 117.948683: setWOW_PARAMETERS:wowevents = 2(1)
[/codeBOX]

The interrupt for link change just does not get fired when driver is started, but get's fired after router reset or after 3-5 minutes. And then everything will work. This issue does not depend how I start OSX - it happens in any case. Soft/Warm reboot from Windows/OSX/Linux.

 

I do not remember that I had this issue in my previous tests with earlier driver. But checked that earlier version today, and I have the same issue now. I do not have that issue on my desktop. One difference between RehabMan and me is that he is booting BIOS Chameleon, while I am booting with UEFI Clover. I do not have legacy Chameleon or Clover right now and can not check if the same would happen in that case.

 

Any idea why I have this issue? Is it possible to trigger link detection early when driver is starting instead of waiting for that interrupt?

 

Anyway, back to original After-Windows issue. Even with this "router reset" help I have the following situation now:

- older driver versions: boot Windows -> restart into OSX + router reset = net is not working

 

- new 1.0.3 driver: boot Windows -> restart into OSX + router reset = net IS working!!!

So, it looks that one is resolved.

 

Thank you !!! :)

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

I can not check it fully on my ProBook because I got another issue. In 90 % of the cases when I start OSX with your driver, Ethernet ends up with "Cable unplugged". I need to reset the router or wait 3-5 minutes until link get's recognised as up and running.

 

The interrupt for link change just does not get fired when driver is started, but get's fired after router reset or after 3-5 minutes. And then everything will work. This issue does not depend how I start OSX - it happens in any case. Soft/Warm reboot from Windows/OSX/Linux.

 

Does the connection LED on the router indicate an established connection? What happens when you pull the cable and replug it during this time period? Have you tried to exchange the cable or put another switch between the router and the machine?

 

I do not remember that I had this issue in my previous tests with earlier driver. But checked that earlier version today, and I have the same issue now. I do not have that issue on my desktop. One difference between RehabMan and me is that he is booting BIOS Chameleon, while I am booting with UEFI Clover. I do not have legacy Chameleon or Clover right now and can not check if the same would happen in that case.

 

I don't think that the bootloader matters.

 

Any idea why I have this issue? Is it possible to trigger link detection early when driver is starting instead of waiting for that interrupt?

 

With exception of the early 8111B/8168B chips the link change interrupt works as it should. The NIC gets reset during the initialization procedure and if you don't get a link change interrupt it's probably because the NIC is unable to establish a link.

 

According to your log data you got WoL enabled. Does the same thing happen when you disable it?

 

Mieze

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I can not check it fully on my ProBook because I got another issue. In 90 % of the cases when I start OSX with your driver, Ethernet ends up with "Cable unplugged". I need to reset the router or wait 3-5 minutes until link get's recognised as up and running. See here:

 

For what its worth, I do not see this on my ProBook. ProBook is directly connected to a Linksys/Cisco e4200 (v1).

Link to comment
Share on other sites
dmazar
dmazar
Posted
Posted

Ok, test of 1.0.3 from my P8P67-M desktop: :trumpet::afro::guitar: all is fine now!!! Driver works like a charm.

 

Regarding ProBook, will test it in different environment over the weekend. Just a note that all works fine in Win and Linux (no issues) and also with Linx2Mac's driver.

 

Also, srcs contains rtl8168_check_link_status() which is called from rtl8168_open() and from rtl8168_interrupt(), while OSX version checkLinkStatus(); is called only from interrupt handler. Does this difference has any meaning?

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

Regarding ProBook, will test it in different environment over the weekend. Just a note that all works fine in Win and Linux (no issues) and also with Linx2Mac's driver.

 

Also, srcs contains rtl8168_check_link_status() which is called from rtl8168_open() and from rtl8168_interrupt(), while OSX version checkLinkStatus(); is called only from interrupt handler. Does this difference has any meaning?

These drivers are different because they set up a timer routine to periodically check for the link status in order to cope with the B revision issue with the exception of lnx2mac which waits for the link to come up for a certain timespan and then never checks again for link changes. As there is a small chance that link detection works well (10% according to your post), I assume that this is a timing issue: The interrupt might be still disabled while the link comes up.

 

Mieze

Link to comment
Share on other sites
saltspork
saltspork
Posted
Posted

I had a quick chance to test the latest debug version from GitHub today and it works fine on 8111B now! No performance issues either, a quick run of iperf showed >900Mb/s in both directions with relatively low CPU load.

 

Great work creating an alternative driver.

  • Like 1
Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted (edited)

I had a quick chance to test the latest debug version from GitHub today and it works fine on 8111B now! No performance issues either, a quick run of iperf showed >900Mb/s in both directions with relatively low CPU load.

 

Great work creating an alternative driver.

 

Hello saltspork,

 

thanks for the test run! That's really good news. I will add support for the B chips in release builds with the next version.

 

Hello,

 

Has anybody got it running with a 8111C without problems?

Because a few posts ago i saw somebody who had problems with it.

 

Thanks,

Greetz

 

Try version 1.0.3 which I have pushed to githup a few minutes ago because I managed to fix a few bugs during the last week. The prebuild binary has been updated to version 1.0.3 too.

 

Mieze

Edited by Mieze
Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

The Realtek driver doesn't seem to work in /Extra. I moved it to /S/L/E. I think we're unable to use it on a bootable flash drive (required for OS X installation).

Are you sure that the permissions are set to root:wheel 755? I managed to load the driver even from desktop provided the permissions are correct.

 

Mieze

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

The Realtek driver doesn't seem to work in /Extra. I moved it to /S/L/E. I think we're unable to use it on a bootable flash drive (required for OS X installation).

 

It should work if installed to /Extra/Extensions

I don't think the boot loader loads any kexts from /Extra

 

Realize if you're using kernel cache, nothing is loaded from /Extra/Extensions either...

Link to comment
Share on other sites
Maniac10
Maniac10
Posted
Posted

The latest version is working great so far! A bit chatty though :P

 

26/04/13 09:16:17,000 kernel[0]: getFeatures() ===>
26/04/13 09:16:17,000 kernel[0]: getFeatures() <===
26/04/13 09:16:17,000 kernel[0]: createWorkLoop() ===>
26/04/13 09:16:17,000 kernel[0]: createWorkLoop() <===
26/04/13 09:16:17,000 kernel[0]: getWorkLoop() ===>
26/04/13 09:16:17,000 kernel[0]: getWorkLoop() <===
26/04/13 09:16:17,000 kernel[0]: createOutputQueue() ===>
26/04/13 09:16:17,000 kernel[0]: createOutputQueue() <===
26/04/13 09:16:17,000 kernel[0]: getPacketBufferConstraints() ===>
26/04/13 09:16:17,000 kernel[0]: getPacketBufferConstraints() <===
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: PCI power management capabilities: 0xffc3.
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: PME# from D3 (cold) supported.
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: PCIe link capabilities: 0x00077c11, link control: 0x0000.
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: EEE support enabled
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: RTL8168E-VL/8111E-VL: (Chipset 16) at 0xffffff80efc06000, xx:xx:xx:xx:xx:xx
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: MSI interrupt index: 1
26/04/13 09:16:17,000 kernel[0]: newVendorString() ===>
26/04/13 09:16:17,000 kernel[0]: newVendorString() <===
26/04/13 09:16:17,000 kernel[0]: newModelString() ===>
26/04/13 09:16:17,000 kernel[0]: newModelString() <===
26/04/13 09:16:17,000 kernel[0]: getFeatures() ===>
26/04/13 09:16:17,000 kernel[0]: getFeatures() <===
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() ===>
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() <===
26/04/13 09:16:17,000 kernel[0]: getHardwareAddress() ===>
26/04/13 09:16:17,000 kernel[0]: getHardwareAddress() <===
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() ===>
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: kIOEthernetWakeOnMagicPacket added to filters.
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() <===
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() ===>
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() <===
26/04/13 09:16:17,000 kernel[0]: registerWithPolicyMaker() ===>
26/04/13 09:16:17,000 kernel[0]: registerWithPolicyMaker() <===
26/04/13 09:16:17,000 kernel[0]: configureInterface() ===>
26/04/13 09:16:17,000 kernel[0]: configureInterface() <===
26/04/13 09:16:17,000 kernel[0]: setPowerState() ===>
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: Already in power state 1.
26/04/13 09:16:17,000 kernel[0]: setPowerState() <===
26/04/13 09:16:17,000 kernel[0]: RTL8111: Ethernet address 50:e5:49:52:98:ee
26/04/13 09:16:17,000 kernel[0]: getFeatures() ===>
26/04/13 09:16:17,000 kernel[0]: getFeatures() <===
26/04/13 09:16:17,000 kernel[0]: getChecksumSupport() ===>
26/04/13 09:16:17,000 kernel[0]: getChecksumSupport() <===
26/04/13 09:16:17,000 kernel[0]: getChecksumSupport() ===>
26/04/13 09:16:17,000 kernel[0]: getChecksumSupport() <===
26/04/13 09:16:17,000 kernel[0]: enable() ===>
26/04/13 09:16:17,000 kernel[0]: Ethernet [RealtekRTL8111]: No medium selected. Falling back to autonegotiation.
26/04/13 09:16:17,000 kernel[0]: selectMedium() ===>
26/04/13 09:16:17,000 kernel[0]: selectMedium() <===
26/04/13 09:16:17,000 kernel[0]: setOffset79() ===>
26/04/13 09:16:17,000 kernel[0]: setOffset79() <===
26/04/13 09:16:17,000 kernel[0]: setMulticastMode() ===>
26/04/13 09:16:17,000 kernel[0]: setMulticastMode() <===
26/04/13 09:16:17,000 kernel[0]: enable() <===
26/04/13 09:16:17,000 kernel[0]: setMulticastMode() ===>
26/04/13 09:16:17,000 kernel[0]: setMulticastMode() <===
26/04/13 09:16:17,000 kernel[0]: setMulticastList() ===>
26/04/13 09:16:17,000 kernel[0]: setMulticastList() <===
26/04/13 09:16:17,000 kernel[0]: setMulticastMode() ===>
26/04/13 09:16:17,000 kernel[0]: setMulticastMode() <===
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() ===>
26/04/13 09:16:17,000 kernel[0]: getPacketFilters() <===
26/04/13 09:16:18,000 kernel[0]: en1: BSSID changed to xx:xx:xx:xx:xx:xx
26/04/13 09:16:18,000 kernel[0]: en1::IO80211Interface::postMessage bssid changed
26/04/13 09:16:18,000 kernel[0]: AirPort: Link Up on en1
26/04/13 09:16:18,000 kernel[0]: en1: BSSID changed to f8:d1:11:37:7b:10
26/04/13 09:16:18,000 kernel[0]: en1::IO80211Interface::postMessage bssid changed
26/04/13 09:16:18,000 kernel[0]: AirPort: RSN handshake complete on en1
26/04/13 09:16:18,000 kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 100-Megabit, Full-duplex, flow-control
26/04/13 09:16:18,000 kernel[0]: getPacketFilters() ===>
26/04/13 09:16:18,000 kernel[0]: getPacketFilters() <===
26/04/13 09:16:18,000 kernel[0]: setMulticastMode() ===>
26/04/13 09:16:18,000 kernel[0]: setMulticastMode() <===
26/04/13 09:16:18,000 kernel[0]: setMulticastList() ===>
26/04/13 09:16:18,000 kernel[0]: setMulticastList() <=== ----> repeats many times

 

post-158318-0-25473800-1366992008_thumb.png

Link to comment
Share on other sites
Mrengles
Mrengles
Posted
Posted

Hello Mieze

 

I'm looking forward to finally using your Realtek ethernet Driver because I just ordered a Gigabyte GA-Z77N-WIFI with dual onboard Realtek NICs. Will this driver work with Apples Link Aggregation (802.3ad) implementation?

 

I plan on using my new build as a small office file server and would benefit from the extra speed and redundancy of NIC teaming. Otherwise maybe I'll put it on the edge of the network and move the Xserve around a little bit.

 

Keep up the great work girl!

 

Mrengles (Robert)

 

PS> Ich bin bei der Planung einer Reise nach Deutschland in diesem Sommer. Ich halte Sie auf dem Laufenden mit den Details. :thumbsup_anim:

Link to comment
Share on other sites
dmazar
dmazar
Posted
Posted

Hi Mieze, I've done some additional testing on my HP ProBook.

 

I've change "environment", changed router and the cable, disabled wake on lan - and still have the issue. Most of the time interrupts are just not happening (interruptOccurred() is not called). The same is with Chameleon and Clover BIOS boot.

 

I have found out that if I set the driver to call checkLinkStatus() few seconds after enable() is called, then this gets the link up and interrupts starts to be triggered. I've added additional watch dog timer for this, and all is working fine now with this.

My test code is here (WatchDog.diff): https://dl.dropboxus...roBookTests.zip

- enable() starts this watch dog timer (after 1 sec), but only the first time it is called

- watch dog action checks if the link status is changed, and if it is not, then is schedules itself again

- if the link status changed, then it calls checkLinkStatus() which brings the link up and this "enables" interrupts; watch dog is turned off then since interrupts are taking care of everything from then on

 

I would rather find out a reason why those interrupts are not deliver to the driver as they are on my desktop, but for now above workaround is good enough for me. Any chance to include something like this in your code?

 

Another observation: when I restart from Windows or Linux into OSX, green led (link) is always on during restart. It's on when system restarts, during POST screen, during Clover GUI and during OSX boot. But if I restart from OSX, then green led is turned off when OSX shuts down and stays off during restart. It's off during POST, Clover GUI and get's on only when your driver resets the nic. It looks like your driver shuts down the nic in a different way then Windows and Linux. Any idea what is different here?

 

I am mentioning this because sometimes (not always) after warm restart from Windows to OSX all is working properly - interrupts are delivered to the driver from the beginning. But after restart from OSX to OSX this never happens. Maybe we are missing something again, but this time during disabling the nic? If you think it's worth it, you may take a look at regs dumps from the above link (RegDumps/*). It helped once, maybe it will give you some idea again.

 

One more thing: interruptOccurred() checks for rxInterrupt, then txInterrupt, then LinkChg. When the interrupts are delivered on my ProBook, the first one contains flags for rx and for link change, meaning rxInterrupt() is executed first and then checkLinkStatus(). I did not noticed any issue with this, but maybe checkLinkStatus() should be executed first? And then ... I do not know if simlar mix happens when link goes down - maybe then checkLinkStatus() should be executed at the end.

  • Like 1
Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

Hi Mieze, I've done some additional testing on my HP ProBook.

 

I've change "environment", changed router and the cable, disabled wake on lan - and still have the issue. Most of the time interrupts are just not happening (interruptOccurred() is not called). The same is with Chameleon and Clover BIOS boot.

 

I have found out that if I set the driver to call checkLinkStatus() few seconds after enable() is called, then this gets the link up and interrupts starts to be triggered. I've added additional watch dog timer for this, and all is working fine now with this.

My test code is here (WatchDog.diff): https://dl.dropboxus...roBookTests.zip

- enable() starts this watch dog timer (after 1 sec), but only the first time it is called

- watch dog action checks if the link status is changed, and if it is not, then is schedules itself again

- if the link status changed, then it calls checkLinkStatus() which brings the link up and this "enables" interrupts; watch dog is turned off then since interrupts are taking care of everything from then on

 

I would rather find out a reason why those interrupts are not deliver to the driver as they are on my desktop, but for now above workaround is good enough for me. Any chance to include something like this in your code?

 

This would be a last resort in case we fail to find a clean solution.

 

Another observation: when I restart from Windows or Linux into OSX, green led (link) is always on during restart. It's on when system restarts, during POST screen, during Clover GUI and during OSX boot. But if I restart from OSX, then green led is turned off when OSX shuts down and stays off during restart. It's off during POST, Clover GUI and get's on only when your driver resets the nic. It looks like your driver shuts down the nic in a different way then Windows and Linux. Any idea what is different here?

 

OS X is different because it doesn't shut down the network drivers properly but instead calls systemWillShutdown(IOOptionBits specifier) to give the driver a chance to put the hardware into an appropriate state, i. e. the driver calls disable() in the methods implementation. Yes, this could be a starting point for a solution.

 

I am mentioning this because sometimes (not always) after warm restart from Windows to OSX all is working properly - interrupts are delivered to the driver from the beginning. But after restart from OSX to OSX this never happens. Maybe we are missing something again, but this time during disabling the nic? If you think it's worth it, you may take a look at regs dumps from the above link (RegDumps/*). It helped once, maybe it will give you some idea again.

 

As RehabMan can not reproduce the issue with his ProBook, I was wondering what is different in his setup and noticed that he uses a 1Gbit capable router while you have a 100Mbit connection. Have you checked with gigabit ethernet too? It might be a PHY configuration related issue because checkLinkStatus() does some tweaks when a 10M or 100M link has been established?

 

Two more questions: what happens when you boot (cold and warm) with the cable unplugged and connect it later? Do you get a working connection immediately? Does it occur on cold boot and wakeup from sleep too?

 

One more thing: interruptOccurred() checks for rxInterrupt, then txInterrupt, then LinkChg. When the interrupts are delivered on my ProBook, the first one contains flags for rx and for link change, meaning rxInterrupt() is executed first and then checkLinkStatus(). I did not noticed any issue with this, but maybe checkLinkStatus() should be executed first? And then ... I do not know if simlar mix happens when link goes down - maybe then checkLinkStatus() should be executed at the end.

This is correct because rxInterrupt() does not interfere with the link status change and txInterrupt() can not occur while the link is down. This order also guarantees that completion of tx requests is handled properly.

 

Mieze

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

I'm looking forward to finally using your Realtek ethernet Driver because I just ordered a Gigabyte GA-Z77N-WIFI with dual onboard Realtek NICs. Will this driver work with Apples Link Aggregation (802.3ad) implementation?

 

Hello Robert,

 

as far as as I know there is nothing special required for a driver to work with Link Aggregation. Although I haven't tried myself I'm quite confident that it will work fine.

 

PS> Ich bin bei der Planung einer Reise nach Deutschland in diesem Sommer. Ich halte Sie auf dem Laufenden mit den Details. :thumbsup_anim:

 

Das ist wirklich eine tolle Nachricht. Ich freue mich riesig! :thumbsup_anim:

 

Mieze

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...