This would also explain the low upload speed. The log messages are ok.Unfortunately you are the first user with an RTL8111C (RTL8168C/8111C: (Chipset 5)) to test the driver so that I have no experience with that chip but the issue reminds me of a report from a user with a MSI Z77MA-G45. Maybe you should take a look at this:I would suggest to disable checksum offload as he did and see if it helps. In case it doesn't, check the network statistics of the machine on the other side. Especially look out for bad packets. Using Wireshark to create a packet dump might also be helpful.By the way, are you using the driver on the GA EP-45-EXTREME like your signature suggests? Are both ports connected to the switch?
![]() ![]()
Due to the shortcomings of the current Realtek 81xx Hackintosh drivers (such as lack of or limited support of 8111E, 32/64-bit, sleep issues), I endeavored to port the Linux RTL81xx driver to Mac OS X. Porting a driver is never a trivial task, but this one brought two interesting challenges. How to make Realtek nic use r8168 driver. Ask Question Asked 2 years. The card used the r8169 driver, which seems to be buggy and unreliable (as in here). Since the solution seems to be to use the r8168 driver, I. (exactly as it happened to lumi in Make Linux load specific driver for given device (Realtek.
What is their configuration (DHCP, static IP or.)?Mieze. This would also explain the low upload speed.
The log messages are ok.Unfortunately you are the first user with an RTL8111C (RTL8168C/8111C: (Chipset 5)) to test the driver so that I have no experience with that chip but the issue reminds me of a report from a user with a MSI Z77MA-G45. Maybe you should take a look at this:I would suggest to disable checksum offload as he did and see if it helps. In case it doesn't, check the network statistics of the machine on the other side. Especially look out for bad packets. Using Wireshark to create a packet dump might also be helpful.By the way, are you using the driver on the GA EP-45-EXTREME like your signature suggests? Are both ports connected to the switch? What is their configuration (DHCP, static IP or.)?MiezeI am using that MB, only port 0 connected to a router with DHCP ip allocations.
Hello dmazar,thanks for your feedback. The extremely high number of packets with bad header checksums might probably indicate that checksum offload isn't working properly after you have used Windows. As all drivers (Win, Linux and OS X) load firmware into the NIC, I assume that the Windows driver leaves the NIC with settings that are incompatible with the OS X driver and don't get replaced completely. Unfortunately the firmware has been provided by Realtek without any documentation so that there is little I can do to resolve the issue. I guess the problem doesn't show up when you shut down the system after using windows and do a cold boot into OS X?Mieze. Did some more tests.If I am in Windows and then shutdown, wait few seconds and turn the comp on and boot to OSX - it does not work.
I have to shut it down from OSX again and then start into OSX and then it works.Tested sequences from Windows:1. Windows - soft restart into Ubuntu - soft restart into OSX, net works2. Windows - soft restart into OSX (net does not work) - soft restart into OSX, net does not work3. Windows - soft restart into OSX (net does not work) - shutdown and start into OSX, net works4. Windows - shutdown and start into OSX (net does not work) - shutdown and start into OSX, net worksFrom sequences 3 and 4: Simple shutdown from Windows is not enough. Your driver needs to be started on my controller twice. At first boot (warm or cold) it does something, but not enough.
Second cold restart (shutdown/start) is needed, and then it works fine.Is there anything that can be learned from this and done?Plus, it looks to me that the same thing is happening when removing some other driver from OSX and installing this one - required several restarts/shutdowns to get it working after install. Did some more tests.If I am in Windows and then shutdown, wait few seconds and turn the comp on and boot to OSX - it does not work. I have to shut it down from OSX again and then start into OSX and then it works.Tested sequences from Windows:1. Windows - soft restart into Ubuntu - soft restart into OSX, net works2. Windows - soft restart into OSX (net does not work) - soft restart into OSX, net does not work3. Windows - soft restart into OSX (net does not work) - shutdown and start into OSX, net works4.
Windows - shutdown and start into OSX (net does not work) - shutdown and start into OSX, net worksFrom sequences 3 and 4: Simple shutdown from Windows is not enough. Your driver needs to be started on my controller twice. At first boot (warm or cold) it does something, but not enough.
Second cold restart (shutdown/start) is needed, and then it works fine.Is there anything that can be learned from this and done?As the chip supports WoL it uses standby power so that it won't be off completely until you pull the plug off the wall or flick the PSU's switch. Maybe it's a firmware related problem? Plus, it looks to me that the same thing is happening when removing some other driver from OSX and installing this one - required several restarts/shutdowns to get it working after install.I had the suspect that the lnx2mac driver also causes problems when you switch over to my driver.
![]()
This might be a firmware issue but it could be as well that the driver left something in the system preferences that is the reason for the strange behavior. As my driver is the only Realtek driver for OS X that makes use of the chip's advanced features (checksum offload and TCP segmentation offload) in order to improve performance, it's interaction with the network stack is far more complex.Here is another funny thing I discovered during my tests. I removed the lnx2mac driver from my test system and installed my driver. Although it was working I noticed that https connections to Apple websites. ICloud, App Store, iTunes Store and developer.apple.com stopped working.
The strange thing was that replies to connection requests from those servers where considered to have a bad IP header checksums by the NIC but everything else, including https connections to other servers, was working flawlessly. Ironically the problem disappeared after I wiped out the disk, reinstalled OS X and my driver. This time everything was working fine.After all I came to the conclusion that rx checksum offload is responsible for many of the known problems.
In the next release I will address this issue and change the way received packets are handled when checksum verification in hardware failed. Instead of marking these packets as bad, they will be considered as unchecked letting the network stack repeat verification in software. So far this strategy seems to work without speed impacts and might even be a practical solution for boards with broken NICs like the MSI Z77MA-G45.Mieze. Tested Slice's version:Same issue, but slightly worse regarding Windows.That's funny! I've been in a personal conversation with Slice during the last days.
He was trying to convince me that my driver has a power management issue causing this kind of trouble and that he already found a solution for his driver. Obviously the issue isn't related to power management at all but as we both started with Realtek's linux driver 8.035.0 its no wonder that both drivers are affected. Anyway, thanks for the information. At least we know now that PM is not the place to look for in order to find a solution.Mieze. Here is another funny thing I discovered during my tests. I removed the lnx2mac driver from my test system and installed my driver.
Although it was working I noticed that https connections to Apple websites. ICloud, App Store, iTunes Store and developer.apple.com stopped working. The strange thing was that replies to connection requests from those servers where considered to have a bad IP header checksums by the NIC but everything else, including https connections to other servers, was working flawlessly.
Ironically the problem disappeared after I wiped out the disk, reinstalled OS X and my driver. This time everything was working fine.After all I came to the conclusion that rx checksum offload is responsible for many of the known problems. In the next release I will address this issue and change the way received packets are handled when checksum verification in hardware failed.
Instead of marking these packets as bad, they will be considered as unchecked letting the network stack repeat verification in software. So far this strategy seems to work without speed impacts and might even be a practical solution for boards with broken NICs like the MSI Z77MA-G45.MiezeGlad you were able to figure out this bug! Let me know if you need any help testing. As the chip supports WoL it uses standby power so that it won't be off completely until you pull the plug off the wall or flick the PSU's switch.
Maybe it's a firmware related problem?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.
What should I start with or what to try to compare? Carefully go through all init process or go straight to this rtl8168hwphyconfig?
R8169 identifies my card as RTLGIGAMACVER33, uses rtl8168e1hwphyconfig and uses FIRMWARE8168E2 (tlnic/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. 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. What should I start with or what to try to compare?
Carefully go through all init process or go straight to this rtl8168hwphyconfig? R8169 identifies my card as RTLGIGAMACVER33, uses rtl8168e1hwphyconfig and uses FIRMWARE8168E2 (tlnic/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 rtl8168hwphyconfig. 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.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. But I have a better idea.
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 andtraceroute 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!MiezePS: Do you need a binary or can you compile from source?
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 intopktSize = (descStatus1 & 0x1fff );Good luck!MiezeEdit: 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. This project is dedicated to the memory of Mausi, the cat I loved more than anybody else.A few days before Christmas I started my latest project, a new driver for recent Intel onboard LAN controllers. My intention was not to replace hnak's AppleIntelE1000e.kext completely but to deliver best performance and stability on recent hardware. That's why I dropped support for a number of older NICs.
Currently the driver supports:5 Series82578LM82578LC82578DM82578DC6 and 7 Series82579LM82579V8 and 9 SeriesI217LMI217VI218LMI218VI218LM2I218V2I218LM3100 Series (since V2.1.0d0)I219LMI219V200 Series (since V2.3.0d0)I219LMI219V300 Series (since V2.4.0d0)I219LMI219VKey Features of the DriverSupport for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission.No-copy receive and transmit. Hi every body, I am a new user of mac os.
I use IMaC late 2017 mac os high sierra 10.13.6(17G65). I want to use Titan V as an external eGPU for molecular dynamic simulation.
First I downloadWebdriver-387.10.10.15.15.108.pkg. And it cannot detect my eGPU (I use sonnet breakaway box 350 watts).My question are: i) what driver NVIDIA is suitable for this mac os version and it should be compatible with Titan V ii) what procedures should I follow to complete installation and make it working?Thank you so muchTeerachat. I don't know whether my LAN device will work on MAC and Which version of mac but i still want to run MAC on my PC, Also i checked my CPU-GPU and it turned out that i can Run MAX High sierra but i realized that some people have trouble with Sound and Internet connection so Here's the NAME of my LAN device:PCIVEN10EC&DEV8136&SUBSYS012310EC&REV054&45F2A70&0&00E1 as (LAN DEVICE took the name from device manager in windows).also from compatibleIds i got this:PCIVEN10EC&DEV8136&REV05Is it Supported on any version of macOS?.
Related:Realtek Sound Driver For Mac - Realtek Sound Driver Xp - Realtek Sound Driver Hd - Acer Realtek Sound Driver
Pages : <1 | 2 | 3 ![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2023
Categories |