Jump to content

New Driver for Realtek RTL8111

Realtek RTL8111 driver

  • Please log in to reply
767 replies to this topic

#41
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Tested this: booted to Windows, then shutdown, then unplugged comp from power for 10-15 secs, then started OSX - and all the same as before, net is connected, but not usable. Required another shutdown and start into OSX to get it working.

I'm willing to try to to compare initalization with r8169 Linux driver (https://github.com/t...realtek/r8169.c). What should I start with or what to try to compare? Carefully go through all init process or go straight to this rtl8168_hw_phy_config()? r8169 identifies my card as RTL_GIGA_MAC_VER_33, uses rtl8168e_1_hw_phy_config() and uses FIRMWARE_8168E_2 (tl_nic/rtl8168e-2.fw, have it from Ubuntu). What is a chance to brick my controller by experimenting with this?

EDIT: Just an update: shutdown after Windows and unplugging the power and ethernet cable and waiting for 30 secs did the trick. Next boot to OSX resulted in working net.

Hello dmazar,

you'll have a hard time trying to track down the error, in particular because Realtek's 8.035.00 driver doesn't separate the firmware from the code at all. Everything is packed into that giant function rtl8168_hw_phy_config. The chance of bricking the NIC can't be ruled out and we don't know what the firmware does.

But I have a better idea. You could get a copy of Realtek's current Linux driver (version 8.035.00) and test it under Linux. http://218.210.127.1...3&GetDown=false
If it shows the same issue with regard to Windows as under OS X then you could contact their technical support and hopefully they will fix it for us.

Can you provide me two debug logs. One when network is working fine, and one after you rebooted from Windows and the network is dead. In the last case please also open Network Utility and watch the number of packets transferred as they are updated by a hardware statistics dump of the NIC. This allows us to take a look at the NIC's internal state.

Mieze

#42
dmazar

dmazar

    InsanelyMac Sage

  • Coders
  • 274 posts
  • Gender:Male

you'll have a hard time trying to track down the error, in particular because Realtek's 8.035.00 driver doesn't separate the firmware from the code at all. Everything is packed into that giant function rtl8168_hw_phy_config. The chance of bricking the NIC can't be ruled out and we don't know what the firmware does.

Well, that was kind of naive from me. Like I could jump in, change few registers and try to get it working. :)

But I have a better idea. You could get a copy of Realtek's current Linux driver (version 8.035.00) and test it under Linux. http://218.210.127.1...3&GetDown=false
If it shows the same issue with regard to Windows as under OS X then you could contact their technical support and hopefully they will fix it for us.

Got it:

[ 1.154796] r8168 Gigabit Ethernet driver 8.035.00-NAPI loaded
[ 1.154894] r8168 0000:08:00.0: irq 53 for MSI/MSI-X
[ 1.298849] r8168: This product is covered by one or more of the following patents: US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and US6,327,625.
[ 1.298852] r8168 Copyright © 2012 Realtek NIC software team <nicfae@realtek.com>
[ 17.289937] r8168: eth0: link down
[ 18.858229] r8168: eth0: link up
[ 19.284308] r8168: eth0: link up
Network still works fine in Ubuntu after restart from Windows. So the firmware theory is not valid any more, right? This thing is the same in yours and Linux drivers, right?

What changed now is that Windows -> restart into Linux -> restart into OSX results in non working net in OSX, while restart from Linux previously fixed it for OSX also. Shutdown and new start fixes it.

About additional logs: do you need something different from previous logs?

#43
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Network still works fine in Ubuntu after restart from Windows. So the firmware theory is not valid any more, right? This thing is the same in yours and Linux drivers, right?


Correct! Maybe I should check the PCI config space setup as this had to be rewritten from scratch because the Linux code was not portable and as far as I know this could be preserved across a reboot or while standby power is still present.

About additional logs: do you need something different from previous logs?


The log messages of the driver (debug build) when network is not working would be really helpful.

Mieze

#44
dmazar

dmazar

    InsanelyMac Sage

  • Coders
  • 274 posts
  • Gender:Male
The one from here is not ok: http://www.insanelym...20#entry1899870 ?

Network Utility/Info: there is no really a difference here with working and 'non-working' net. Send and Receive errors and Collisions are 0. It's just that Sent and Recv packets number are much smaller with 'non-working' net. But they still rise with time. By the way, ping, lookup and

traceroute are working fine. Safari: does not report any connection errors, just waits to receive some data, which is not coming.

#45
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

The one from here is not ok: http://www.insanelym...20#entry1899870 ?

Network Utility/Info: there is no really a difference here with working and 'non-working' net. Send and Receive errors and Collisions are 0. It's just that Sent and Recv packets number are much smaller with 'non-working' net. But they still rise with time. By the way, ping, lookup and

traceroute are working fine. Safari: does not report any connection errors, just waits to receive some data, which is not coming.


According to the logs the NIC is working but rx checksum offload seems to be unreliable after a reboot from Windows which brings the firmware theory back into the game because my driver and the linux driver have different strategies. When checksum verification in hardware failed the linux driver treats the packet as unchecked and lets the network stack perform the check while my driver considers it to be a bad packet.

Please try the attached version in which I adopted the strategy of the linux driver. Good luck!

Mieze

PS: Do you need a binary or can you compile from source?

#46
dmazar

dmazar

    InsanelyMac Sage

  • Coders
  • 274 posts
  • Gender:Male
Src is fine. Thanks!

Tested: still does not work after Windows.
Logs: Attached File  NetDebug.zip   10.81KB   3 downloads

The error moved from bad checksum to data size error:
ip:
356 total packets received
0 bad header checksums
0 with size smaller than minimum
159 with data size < data length
Hope this will trigger some more ideas :) .

#47
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Src is fine. Thanks!

Tested: still does not work after Windows.
Logs: Attached File  NetDebug.zip   10.81KB   3 downloads

The error moved from bad checksum to data size error:

ip:
356 total packets received
0 bad header checksums
0 with size smaller than minimum
159 with data size < data length
Hope this will trigger some more ideas :) .


Hello dmazar,

according to the documentation the NIC transfers the packet including the ethernet CRC into memory but as the CRC isn't needed by the protocol stack, the driver removes the last 4 bytes of a received packet. Maybe your NIC (Chipset 14) is different?

Locate the following line in the source code (its in RTL8111::rxInterrupt())

pktSize = (descStatus1 & 0x1fff) - 4;

Change it into

pktSize = (descStatus1 & 0x1fff);

Good luck!

Mieze

Edit: In case this doesn't help you might also try to increase the packet size a little bit. The buffers are all 2000 bytes in size so that there is enough headroom.

#48
dmazar

dmazar

    InsanelyMac Sage

  • Coders
  • 274 posts
  • Gender:Male
Tried, but does not help. I've dumped descStatus1 and descStatus2 from working and non working net and from linux (after Windows). Maybe it will help.
Attached File  NetDebug2.zip   2.26KB   0 downloads

Mainly, non working system contains packets with descStatus1 bits 20-23 as 6, while working system and linux do not have that.
Not working:

rxInterrupt(): descStatus1=0x3462c500, descStatus2=0x40000000, pktSize=1536
rxInterrupt(): descStatus1=0x3462c500, descStatus2=0x40000000, pktSize=1536
(packet sizes are invalid, increased by 256 by me)

#49
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Mainly, non working system contains packets with descStatus1 bits 20-23 as 6, while working system and linux do not have that.
Not working:

rxInterrupt(): descStatus1=0x3462c500, descStatus2=0x40000000, pktSize=1536
rxInterrupt(): descStatus1=0x3462c500, descStatus2=0x40000000, pktSize=1536
(packet sizes are invalid, increased by 256 by me)

The datasheet says:
  • Bit 22: Receive Watchdog Timer Expired: This bit is set whenever the received packet length exceeds 8192 bytes.
  • Bit 21: Receive Error summary: When set, indicates that at least one of the following errors has occurred: CRC, RUNT, RWT, FAE. This bit is valid only when LS (Last segment bit) is set.
Ok, we know now that these packets are really bad because of a reception error but I have no idea how to avoid this. :unsure:

Mieze

#50
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Hello dmazar,

two more questions to narrow down the issue:

1) Which Windows driver do you use? Driver from board's manufacturer, Realtek, included in Win?

2) When you use Ubuntu's native driver without the firmware, is it still able to cure the problem caused by the Win driver?

Mieze

#51
dmazar

dmazar

    InsanelyMac Sage

  • Coders
  • 274 posts
  • Gender:Male
Windows driver: Realtek, 10.6.2011., 7.46.610.2011. I think it's installed from mobo CD, but I do not know if it's updated from Windows Update.

Linux: there are two drivers:
- r8169 which is part of Linux - Windows -> reboot into Linux (net works) -> reboot into OSX (net works)
- r8168 from Realtek - Windows -> reboot into Linux (net works) -> reboot into OSX (net does not work)

Thanks for still thinking about this. If you think that some registers dumps at some point will help, just tell. I can do them from Linux and OSX driver.

#52
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Windows driver: Realtek, 10.6.2011., 7.46.610.2011. I think it's installed from mobo CD, but I do not know if it's updated from Windows Update.


Realtek released new Windows drivers during the last days. Maybe you should try them to see if they resolve the problem as I assume that they use a similar setup/firmware as the Linux drivers?

http://www.realtek.c...3&GetDown=false

Thanks for still thinking about this. If you think that some registers dumps at some point will help, just tell. I can do them from Linux and OSX driver.


We've found a lot of facts but what we need most now is a new theory how to reconcile them. As far as I know only chipset 14 is affected of the problem so that it might be the best approach to check the initialization steps that are specific to this chip. As soon as I have an idea I'll let you know.

Mieze

#53
genzai

genzai

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 169 posts
  • Gender:Male
  • Location:San Francisco
Hi Mieze,
Thank you so much for this dev work. Using lnx2mac which had a very slow dev cycle, i was having problems with extended high traffic use of the nic one one of my systems. It would just die until a reboot. I would also have to inactivate and reactivate if i unplugged and replugged the cable. Both these issues seem solved by your driver, and i am also getting a good %10 more bandwidth it seems. I have not tried the Slice driver yet but i am happy with yours. Maybe you guys should join forces :)

Anyway, i do use windows occasionally and would lobe to see that issue resolved. I will test it on my system to see if i have the same issue. One request i have is, since you say that offload wont work with jumbo frame is if you can allow offload to disabled when jumbo frames are used or if thats not possible release a version with jumbo frame support (and no offload). That would be helpful as sometimes i use this feature on internal network setups.
Thanks!
g\

#54
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Anyway, i do use windows occasionally and would lobe to see that issue resolved. I will test it on my system to see if i have the same issue. One request i have is, since you say that offload wont work with jumbo frame is if you can allow offload to disabled when jumbo frames are used or if thats not possible release a version with jumbo frame support (and no offload). That would be helpful as sometimes i use this feature on internal network setups.


As far as I know only chipset 14 is affected by the problem while the 8111E-VL (Chipset 16) and 8111F (Chipset 17) found on recent mainboards seem to work fine.

On the receiver side the driver should tolerate jumbo frames as long as they fit into a single buffer. Eventually you'll have to increase kRxBufferPktSize (current value 2000) to cope with your setup.

On the transmitter side it makes no sense to use jumbo frames as every devices works well with standard frames and disabling the offload features will result in a significant performance impact even on fast systems.

Mieze

#55
saltspork

saltspork

    InsanelyMac Protégé

  • Members
  • Pip
  • 4 posts
  • Gender:Male
  • Location:Adelaide, South Australia

Limitations

  • Support for the Realtek RTL8111B/8168B is still experimental and might not work at all. Therefore it is only included in debug builds and has never been tested successfully because I don't have access to a board with one of these outdated chips.
Known Issues
  • The code for RTL8111B/8168B NICs is untested and will probably not work as expected.


Hoping I can help out with that. I've got an old EP35-DS3 w/ 8111B that I don't really value for anything but testing.

I installed the debug version of your driver and it works mostly fine with the massive exception of TCP. There's also a lot of spam in the system log from a timer loop.

I've attached my system.log and netstat -s output. Let me know what else I can do to help test.

Attached File  netstat.txt   8.27KB   5 downloads
Attached File  system.log.txt   41.05KB   5 downloads

#56
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

I installed the debug version of your driver and it works mostly fine with the massive exception of TCP. There's also a lot of spam in the system log from a timer loop.


Hello saltspork,

thank you very much for the debug data. In order to get rid of the timer log messages comment out the following two lines in timerActionRTL8111B(IOTimerEventSource *timer):

DebugLog("timerActionRTL8111B() ===>\n");

DebugLog("timerActionRTL8111B() <===\n");

As only TCP isn't working I guess that this is an issue with TCP segmentation offload. Please change this method

UInt32 RTL8111::getFeatures() const
{
return (kIONetworkFeatureMultiPages | kIONetworkFeatureHardwareVlan | kIONetworkFeatureTSOIPv4 /*| kIONetworkFeatureTSOIPv6*/);
}

into

UInt32 RTL8111::getFeatures() const
{
return (kIONetworkFeatureMultiPages | kIONetworkFeatureHardwareVlan);
}

to disable it. Good luck!

I'm currently preparing a new release and will include improved 8111B support if we can get it working with TCP.

Mieze

#57
saltspork

saltspork

    InsanelyMac Protégé

  • Members
  • Pip
  • 4 posts
  • Gender:Male
  • Location:Adelaide, South Australia
Hi Mieze.

I've commented out all the bits above and while the debug messages are cleared up TCP still isn't working.

An updated system.log is attached although I doubt it will help much.

Thanks for your efforts in any case.

Attached File  system.log.txt   31.97KB   3 downloads

#58
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Hi Mieze.

I've commented out all the bits above and while the debug messages are cleared up TCP still isn't working.

An updated system.log is attached although I doubt it will help much.

Thanks for your efforts in any case.

Attached File  system.log.txt   31.97KB   3 downloads


Hello saltspork!

Thanks for the log data. What makes me wonder is the fact that TCP packets seem to go out but there is nothing coming back as if they all ended up in a black hole. No bad packets, no errors. Can you please describe the way you tested TCP?

Mieze

#59
saltspork

saltspork

    InsanelyMac Protégé

  • Members
  • Pip
  • 4 posts
  • Gender:Male
  • Location:Adelaide, South Australia

Thanks for the log data. What makes me wonder is the fact that TCP packets seem to go out but there is nothing coming back as if they all ended up in a black hole. No bad packets, no errors. Can you please describe the way you tested TCP?


At first I wasn't testing very scientifically but I've gone back and done things properly with Wireshark on both ends. First trying to SSH to a remote system, and then the same remote system trying to SSH to the Hackintosh.

I don't know enough about TCP to say anything for certain, but it appears that the driver spits out invalid TCP packets that aren't even worthy of acknowledgement from a remote system, literally.

I've attached pcap files from each end, nicely synchronised.

Attached File  pcap.tar.gz   3.29KB   3 downloads

#60
Mieze

Mieze

    Giant Cat

  • Coders
  • 548 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Update Notification

I released version 1.0.1 (source and binary) which includes two important changes:
  • Improved behavior when rx checksum offload isn't working. When hardware checksum verification of received packets fails, the driver now considers the packet as unchecked and hands it over to the network stack letting it repeat the verification in software instead of marking the packet as bad.
  • The NIC's model name is added to IORegistry so that System Profiler will show it properly.
The download URL is still the same.

Mieze





Also tagged with one or more of these keywords: Realtek, RTL8111, driver


3 user(s) are reading this topic

2 members, 1 guests, 0 anonymous users


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