Jump to content

Mieze

Developers
  • Content Count

    1,380
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by Mieze

  1. This project is dedicated to the memory of Carlos Gato Vaca. I spent the last 2 weeks writing a driver for my Killer E2200 NIC because there is no stable working driver for recent Atheros chips under OS X. Most of the hardware specific code is based on Johannes Berg's alx driver for Linux and the OS X driver framework was taken from my Realtek driver. Key Features of the Driver Supports Qualcomm Atheros AR816x, AR817x, Killer E220x, Killer E2400 and Killer E2500. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). Support for TCP/IPv6 and UDP/IPv6 checksum offload. Makes use of the chip's TCP Segmentation Offload (TSO) feature with IPv4 and IPv6 in order to reduce CPU load while sending large amounts of data. Fully optimized for Mountain Lion, Mavericks and Yosemite (64bit architecture) but should work with Lion too, provided you build from source with the 10.7 SDK. Wake on LAN support. VLAN support is implemented but untested as I have no need for it. Supports Energy Efficient Ethernet (EEE). The driver is published under GPLv2. Known Issues None. FAQ Could you add support for AR813x and AR815x? Sorry, no, because I used a different linux driver as the code base than Shailua which doesn't support these chips so that it would be too much work to add support for them. WoL from S5 doesn't work with this driver but under Windows it's working. Is this a driver bug? No it isn't, the driver is working as it should because OS X doesn't support WoL from S5. You may also install the driver to to /Library/Extensions or use Clover to inject it. In case you are experiencing repeated connection drops with EEE enabled, please select a medium without EEE manually in order to resolve the problem. Installation Goto /S/L/E and delete ALXEthernet.kext. Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. Reboot. Install the new driver and recreate the kernel cache. I recommend to use Kext Wizard or a similar utility for the installation. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface. Troubleshooting Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be retrieved with "grep kernel /var/log/system.log" in Terminal. Starting with Sierra use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me. Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any ALXEthernet.kext from your system because it could prevent the driver from working properly. Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard, different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable. Changelog Version 2.2.2 (2017-09-25)Fixes a problem which may cause trouble when trying to change the MAC address. Version 2.1.0d1 (2015-11-29) Supports Energy Efficient Ethernet (EEE). Added support for Killer E2400. Version 2.0.1 (2015-08-12) Improved flow control support in 100MBit mode. Version 2.0.0 (2015-04-21) Uses Apple's private driver interface introduced with 10.8. Supports packet scheduling with QFQ. Please note that 2.0.0 is identical to 2.0.0d1. Only the version number has changed. Version 1.0.1 (2015-03-01) Reworked media selection and reporting. Resolved the NIC disabled by BIOS issue. Improved flow control support. Version 1.0.0 (2014-10-05)Official release which is identical to 1.0.0d7. Version 1.0.0d7 (2014-08-18)Fixed Wake on LAN. Version 1.0.0d6 (2014-08-16) Detects situations when the BIOS left the NIC disabled and outputs an error messages. Small optimizations and improved error handling. Version 1.0.0d5 (2014-08-13)Removed the mbuf_pullup() call in outputPacket() as the NIC seems to accept packets with noncontiguous headers. Version 1.0.0d4 (2014-08-12)Fixed TSO with IPv4 and IPv6. Version 1.0.0d3 (2014-08-10) Added support for TCP and UDP checksum offload over IPv6. Cleaned up the code and improved error handling. Getting the driver The source code can be found on GitHub: https://github.com/Mieze/AtherosE2200Ethernet There is also a prebuilt binary for 10.8 and above in the download section: http://www.insanelymac.com/forum/files/file/313-atherose2200ethernet/ The latest development version can be found here: http://www.insanelymac.com/forum/topic/300056-solution-for-qualcomm-atheros-ar816x-ar817x-and-killer-e220x/?p=2192549 Mieze
  2. Sorry, no idea at the moment and I don't have the time to get involved because I'm very busy with preparations for an exam at university next week.
  3. @audio geekThis is not a driver issue as it originates in the higher levels of the network stack. In case you you got infrequent connection dropouts you might want to disable EEE as it may cause this problem.
  4. A New Driver for Realtek RTL8111 Due to the lack of an OS X driver that makes use of the advanced features of the Realtek RTL81111/8168 series I started a new project with the aim to create a state of the art driver that gets the most out of those NICs which can be found on virtually any cheap board on the market today. Based on Realtek's Linux driver (version 8.035.0) I have written a driver that is optimized for performance while making efficient use of system resources and keeping the CPU usage down under heavy load. Key Features of the Driver Supports Realtek RTL8111/8168 B/C/D/E/F/G found on recent boards. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload under IPv4. Support for TCP/IPv6 and UDP/IPv6 checksum offload. Fully optimized for Mountain Lion (64bit architecture) but should work with Lion too. As of now there is no support for Snow Leopard but it can be added if someone will create the necessary patches. Supports Wake on LAN. Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2. Limitations As checksum offload doesn't work with jumbo frames they are currently unsupported and will definitely never be. No support for 32bit kernels. Installation Before you install the driver you have to remove any installed driver for RTL8111/8168. Goto /S/L/E and delete the old driver (Lnx2mac, AppleRealtekRTL8169, etc.). Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. If you forget this step you might experience strange problems with certain Apple domains, iTunes and iCloud later. Reboot. Install the new driver and recreate the kernel cache. I recommend to use Kext Wizard or a similar utility for the installation. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface. Troubleshooting Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be found in /var/log/system.log. For Sierra and above use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any other Realtek kext from your system because they could prevent the driver from working properly. Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable. FAQ How can I retrieve the kernel logs?In Terminal type "grep kernel /var/log/system.log". ​I want to disable Energy Efficient Ethernet (EEE) but I don't know how?​Take a look at the driver's Info.plist file. There you will find an option named <key>enableEEE</key>. Change its value from <true/> to <false/>. Don't forget to recreate the kernel cache after changing the value.​ WoL from S5 doesn't work with this driver but under Windows it's working. Is this a driver bug?No it isn't, the driver is working as it should because OS X doesn't support WoL from S5. Current status The driver has been successfully tested under 10.8.x and 10.9 with the B, C, D, E, F and G versions of the RTL8111/8168 and is known to work stable on these devices. Changelog Version 2.2.2 (2018-01-21) Force ASPM state to disabled/enabled according to the config parameter setting. Requires 10.12 or newer. Version 2.2.1 (2016-03-12): Updated underlying linux sources from Realtek to 8.041.00. Added support for RTL8111H. Implemented Apple’s polled receive driver model (RXPOLL). Requires 10.11 or newer. Support for older versions of OS X has been dropped. Version 2.0.0 (2015-06-21): ​Uses Apple's private driver interface introduced with 10.8. Supports packet scheduling with QFQ. Please note that 2.0.0 is identical to 2.0.0d2. Only the version number has changed. Version 1.2.3 (2014-08-23):Reworked TSO4 and added support for TSO6. Version 1.2.2 (2014-08-44): ​Added an option to disable Active State Power Management (ASPM, default disabled) as ASPM seems to result in unstable operation of some chipsets. ​Resolved a problem with Link Aggregation after reboot. Added a workaround for the multicast filter bug of chipset 17 (RTL8111F) which prevented Bonjour from working properly​ ​Version 1.2.0 (2014-04-24): Updated underlying linux sources from Realtek to 8.037.00. Improved interrupt mitigate to use a less aggressive value for 10/100 MBit connections. ​Version 1.1.3 (2013-11-29): Improved transmit queue handling made it possible to reduce CPU load during packet transmission. Improved deadlock detection logic in order to avoid false positives due to lost interrupts. Version 1.1.2 (2013-08-03): Improved SMB performance in certain configurations. Faster browsing of large shares. ​Version 1.1.0 (2013-06-08): Support for TCP/IPv6 and UDP/IPv6 checksum offload added (can be disabled in Info.plist). Maximum size of the scatter-gather-list has been increased from 24 to 40 segments to resolve performance issues with TSO4 when offloading large packets which are highly fragmented. TSO4 can be disabled in Info.plist without rebuild. Statistics gathering has been improved to deliver more detailed information (resource shortages, transmitter resets, transmitter interrupt count). The interrupt mitigate settings has been changed to improve performance with SMB and to reduce CPU load. Configuration option added to allow for user defined interrupt mitigate settings without rebuild. Version 1.0.4 (2013-05-04):Moved setLinkStatus(kIONetworkLinkValid) from start() to enable(). Cleaned up getDescCommand(). Version 1.0.3 (2013-04-25):​The issue after a reboot from Windows has been eliminated. Version 1.0.2 (2013-04-22):​Added support for rx checksum offload of TCP and UDP over IPv6. Version 1.0.1 (2013-03-31): Improved behavior when rx checksum offload isn't working properly. Adds the chipset's model name to IORegistry so that it will show up in System Profiler. Known Issues There are still performance problems with regard to SMB in certain configurations. My tests indicate that Apple's Broadcom driver shows the same behavior with those configurations. Obviously it's a more general problem that is not limited to my driver. WoL does not work in certain configurations. Old systems with 3 and 4 series chipsets exhibit performance issues in recent versions of macOS because there is no optimized power management for these systems in macOS anymore as Apple dropped support for the underlying hardware a long time ago. In case you are affected, please upgrade your hardware or find an alternative solution because I have no plans for a workaround. Sorry, but I don't think that it's worth the effort. Getting the driver The source code can be found here: https://github.com/M...driver_for_OS_X There is also a pre-build binary for Mavericks and Yosemite: http://www.insanelym...n-and-wireless/ Building from Source I'm using XCode 4.6.3 for development. You can get a free copy of XCode after becoming a member of the Apple developer program. The free membership is sufficient in order to get access to development tools and documentation.
  5. 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 Series 82578LM 82578LC 82578DM 82578DC 6 and 7 Series 82579LM 82579V 8 and 9 Series I217LM I217V I218LM I218V I218LM2 I218V2 I218LM3 100 Series (since V2.1.0d0) I219LM I219V 200 Series (since V2.3.0d0) I219LM I219V 300 Series (since V2.4.0d0) I219LM I219V Key Features of the Driver Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). Support for TCP/IPv6 and UDP/IPv6 checksum offload. Makes use of the chip's TCP Segmentation Offload (TSO) feature with IPv4 and IPv6 in order to reduce CPU load while sending large amounts of data (disabled). Fully optimized for Sierra (64bit architecture) but should work with older 64bit versions of macOS too, provided you build from source with the appropriate SDK for the target OS. Support for Energy Efficient Ethernet (EEE). VLAN support is implemented but untested as I have no need for it. The driver is published under GPLv2. Current Status The driver has been tested successfully with I217V, I218V and 82579V under 10.9.5 and above. The attached archive includes source code as well as a prebuilt binary (debug version) for Mavericks and Yosemite. Known Issues There seem to be problems while using VMware with version 1.x.x of the driver. In case you are affected use version 2.0.0 or newer. FAQ Could you add support of for...? Well, you are probably asking me to add support for one of the older NICs like the 82571/2/3/4L or 82583 and the answer will be no as I dropped support for these chips intentionally. They are broken and I lost more than 2 weeks trying to make it work on the 82574L without success. I was asked to add support for I210, I211 and I350 but as these chips have a completely different architecture, which isn't supported by the underlying Linux driver, this is impossible, sorry. Does it work with Snow Leopard or 32 bit kernels? No and I have no plans to make a version for 32 bit kernels or anything older than Lion. WoL from S5 doesn't work with this driver but under Windows it's working. Is this a driver bug? No it isn't, the driver is working as it should because OS X doesn't support WoL from S5. Installation Goto /S/L/E and delete AppleIntelE1000e.kext. Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. Reboot. Install the new driver and recreate the kernel cache. I recommend to use Kext Wizard or a similar utility for the installation. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface. Troubleshooting Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be retrieved with "grep kernel /var/log/system.log" in Terminal. Starting from Sierra use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me. Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any AppleIntelE1000e.kext from your system because it could prevent the driver from working properly. Delete the following files: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard, different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable. Changelog Version 2.4.0 (2018-04-14) Added support for 300 series versions of I219LM and I219V. Updated underlying Linux source code. Version 2.3.0 (2017-06-20) Added support for 200 series versions of I219LM and I219V. Version 2.2.0 (2016-09-23) Disabled TSO to work around a hardware bug. Version 2.1.0 (2016-05-24) Added support for I219LM and I219V Version 2.0.0 (2015-04-22) First official release which is identical to 2.0.0d2 (only the version number has been changed). Version 2.0.0d2 (2015-04-04) Changed the tx descriptor write back policy for 82579, I217 and I218 to prevent random tx deadlocks. Version 2.0.0d1 (2015-03-14) Uses Apple's private driver interface introduced with 10.8. Supports packet scheduling with QFQ Solves the VMware issue. Version 1.0.0d6 (2015-03-04) Reworked TSO6 support to avoid problems with VMware. Wake-on-LAN now working. Version 1.0.0d5 (2015-02-27) Reworked TSO4 support to eliminate the bug of 1.0.0d4. Added some debug code in order to collect information about the VMware related issue. Version 1.0.0d4 (2015-02-25) Set total length field of the IP-header to zero for TSO4 operations. Report EEE activation state in kernel log message when the link has been established. Version 1.0.0d3 (2015-02-11) Reworked media selection and EEE support (EEE is now activated when both link partners support it. It can be disabled selecting the medium manually). Duplex setting for 10/100 MBit connections is now reported correctly. The number of tx descriptors has been reduced from 2048 to 1024. The code has been cleaned up and obsolete files have been removed. Version 1.0.0d2 (2015-01-31) First development release. Getting the Driver The source code can be found on GitHub: https://github.com/Mieze/IntelMausiEthernet There is also a prebuilt binary for 10.11 and above in the download section: http://www.insanelymac.com/forum/files/file/396-intelmausiethernet/ Build from Source for 10.8 Register as a developer on Apple's developer website. A free membership is sufficient. Download a copy of Xcode 5.1.1 and install it on your machine. In the project select 10.8 as the "Base SDK" and the "Deployment Target". Call "Archive" from the menu "Product" and save the built driver. Credits Thanks to RehabMan and Yung Raj for running tests and pointing me in the right direction while I was trying to fix TSO. Special thanks to Yung Raj for motivating me when I was about to give up.
  6. I see no reason why anybody would need WoL as Apple drivers support mDNS offload so that the machine stays visible while sleeping and can be woken up with a connection request using protocols like SSH for example? Mieze
  7. In order to use the device with the Apple driver, it's firmware must be updated with macOS 10.13.3 but as the AQC111's device id 0x11b1 isn't supported natively by Apple's driver, I doubt that it will update the firmware and even in case it does, there is no guarantee that Apple's firmware will work on this chip, it might as well render the chip unusable. Mieze
  8. Mieze

    New Driver for Realtek RTL8111

    Sure, I will add support for new devices as soon as Realtek releases Linux driver sources so that I can learn how to handle them. Mieze
  9. Mieze

    New Driver for Realtek RTL8111

    It's Apple's Bonjour daemon listening for requests. Mieze
  10. First of all, if you don't know how to clean the system caches of your Mac OS version, ask Google. Second, there is no driver problem with static IP addresses because address handling is far beyond the scope of a driver. The driver handles packets, nothing more and nothing less. In case it continues to crash, fix your system. Mieze
  11. Please delete system caches and see if it resolves the issue. Mieze
  12. Thank you for the feedback. I received a similar problem report form from vit9696 but I neither can reproduce the issue on my test system, nor do I have a conclusive explanation for it. Instead of that I noticed a strange behavior of the power LED during sleep on my test machine. Although the system seems to sleep and wake properly, the power LED stays on in sleep state which indicates, that the machine doesn't manage to complete the transition to sleep state (S3) completely. This never happened before updating to Mojave and it indicates that there is a general power management issue, which may also be related to the crash. Anyway, it would be helpful if you could provide me a kernel panic report of the machine showing the incident? Are you using Gigabit Ethernet for your LAN? How fast is your internet connection? I also attach the prebuilt binary (requires Mojave) to this post so that anybody interested in testing version 2.5.0d0 of the driver or having the same problem can try it too. It should also fix the no network after wakeup issue that some users with LM-versions of the NIC reported in the past, as it doesn't release control of the chip during sleep anymore Mieze IntelMausiEthernet-V2.5.0d0.zip
  13. Introduction With Whatevergreen.kext we already have a workaround for the AMD GPU wakeup issue which first arose with the release of El Capitan, but as a workaround is just a second class solution for a problem I decided to trace back the reason for the issue to it's origin and this post is the result of my research. As I used a R9 270X to do my research, which is the only AMD GPU I have, my patch has only been verified to work properly with this chip but according to the information sources I used, I have no reason to believe it won't work on other AMD GPU's too. In case there is still some uncertainty left in a particular point, I will mention this explicitly. Materials Used The Linux kernel sources of the Radeon driver in order to get a better understanding of the GPU's internals: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/radeon?h=next-20171013 A copy of the ACPI 6.0 specs in order to find out how to dump the chip's control register space. A disassembler, e.g. objdump in Terminal or the trial version of Hopper Disassembler. What I Did As it's been a well known fact that wakeup with AMD GPUs still works with El Capitan and Sierra provided you select the IGPU as primary GPU enabled CSM and use Legacy VBIOS of the AMD GPU in BIOS setup. I was wondering what is different with UEFI VBIOS and decided to I create dumps of the GPU's control register space while using Legacy VBIOS with CSM enabled and while using UEFI VBIOS with CSM disabled in order to find out. Comparing the register space contents it became obvious where the root of the problem lies and how it can be fixed with a DSDT patch. Technical Background Using Legacy VBIOS only the primary GPU is initialized by the VBIOS, i.e. only the IGPU is initialized while the AMD GPU is left untouched. When OS X boots up the framebuffer controller kext will find the AMD GPU in vanilla state, initialize it properly and wakeup will work as expected. That's also the reason why you have to blind boot in this configuration. Using UEFI VBIOS the AMD GPU will be initialized too, provided it has a display connected to one of it's ports. You'll see the BIOS splash screen and will be able to access the BIOS settings but unfortunately macOS's framebuffer controller kext will notice that the GPU has already been initialized and skips the basic setup so that the configuration made by the VBIOS will be used and this is the point where things start to go wrong because this configuration seems to be broken causing wakeup to fail. First of all you have to locate the AMD GPU in your DSDT. In my case it can be found at _SB.PCI0.PEG0.PEGP but it needs to be renamed to GFX0 for AppleGraphicsDevicePolicy.kext (AGDP) to work properly. This can be done manually or using a Clover patch (this is what I did) and I assume that this problem has been already solved before. The reason why I mention it explicitly here, is that you should be aware of it and don't get confused when your AMD GPU has a different name in the DSDT than in IORegistry. Second, we need to get access to the GPU's control register space. According to the Linux sources, PCI Base Address Register 2 (BAR2) is used to address the control register space on Radeon HD5000, HD6000 and HD7000 GPUs. It's a 64bit base address register but newer GPUs (BONAIRE and above, i.e. Radeon HD8000 and HD9xxx) are different as the use BAR5 instead of BAR2. Unlike BAR2, BAR5 is a 32bit base address register. On my R9 270X (PITCAIRN) BAR5 is zero so that I decided to use this as an indication to use BAR2 but I must confess that I haven't checked if it works for all supported GPUs too. In case my patch doesn't work for you, be aware that this might be a pitfall! The Radeon driver's source code tells us that the first display controller engine's registers can be found starting at offset 0x6800. It also tells us a lot about the meaning of the register contents. Using Legacy VBIOS my R9 270X's display controller engine's registers are still at their default values when macOS boots: 00006800 01 00 00 00 08 80 00 0a 00 00 00 00 00 00 00 00 |................| 00006810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006820 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006850 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006860 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006870 00 00 00 00 08 80 00 14 00 00 00 00 00 00 00 00 |................| 00006880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006890 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068b0 00 00 00 00 10 00 00 00 00 00 00 20 00 00 00 20 |........... ... | 000068c0 00 00 00 20 10 00 00 00 00 00 00 20 00 00 00 20 |... ....... ... | 000068d0 00 00 00 20 00 00 00 00 00 20 00 00 00 00 00 00 |... ..... ......| 000068e0 00 00 00 20 00 00 00 00 00 00 00 00 00 20 00 00 |... ......... ..| 000068f0 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 20 |..... ......... | With UEFI VBIOS the display controller engine's registers look quite different. Using the Linux driver sources you can easily make sense out of these values and will discover that I've got a 4K display connected to my R9 270X which is configured to it's native resolution using 32 bits per pixel. 00006800 01 00 00 00 0a 80 00 0a 00 00 00 00 00 00 00 00 |................| 00006810 00 00 00 00 00 00 00 00 00 0f 00 00 f4 00 00 00 |................| 00006820 f4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006830 00 00 00 00 00 0f 00 00 70 08 00 00 00 00 00 00 |........p.......| 00006840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006850 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................| 00006860 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006870 00 00 00 00 08 80 00 14 00 00 00 00 00 00 00 00 |................| 00006880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00006890 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000068b0 00 00 00 00 10 00 00 00 00 00 00 20 00 00 00 20 |........... ... | 000068c0 00 00 00 20 10 00 00 00 00 00 00 20 00 00 00 20 |... ....... ... | 000068d0 00 00 00 20 00 00 00 00 00 20 00 00 00 00 00 00 |... ..... ......| 000068e0 00 00 00 20 00 00 00 00 00 00 00 00 00 20 00 00 |... ......... ..| 000068f0 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 20 |..... ......... | The rest was just a little bit of laborious work and trial and error, comparing register contents, understanding their meanings and see what happens when you reset these registers to their default values. If you try to play around with your GPU's control registers a little bit more, be prepared to get a garbled screen for a few seconds. After all I've managed to create a DSDT patch which fixes the wrong registers while preserving screen output during boot and, most important, solves the wakeup issue. The Patch Putting things together I created a DSDT patch to fix the incorrectly initialized registers. With this patch applied, I now have working wakeup with my R9 270X under Sierra (10.12.6) using UEFI VBIOS with CSM disabled in UEFI setup. No kext patches or additional kexts are needed anymore for sleep/wake to work properly with my R9 270X anymore. I can see the BIOS splash screen on my display and can access UEFI setup but the best of all is that there hasn't been a single wakeup issue since I applied this patch. Device (PEGP) { Name (_ADR, Zero) // _ADR: Address OperationRegion (PCIB, PCI_Config, Zero, 0x0100) Field (PCIB, AnyAcc, NoLock, Preserve) { Offset (0x10), BAR0, 32, BAR1, 32, BAR2, 64, BAR4, 32, BAR5, 32 } Method (_INI, 0, NotSerialized) // _INI: Initialize { If (LEqual (BAR5, Zero)) { Store (BAR2, Local0) } Else { Store (BAR5, Local0) } OperationRegion (GREG, SystemMemory, And (Local0, 0xFFFFFFFFFFFFFFF0), 0x8000) Field (GREG, AnyAcc, NoLock, Preserve) { Offset (0x6800), GENA, 32, GCTL, 32, LTBC, 32, Offset (0x6810), PSBL, 32, SSBL, 32, PTCH, 32, PSBH, 32, SSBH, 32, Offset (0x6848), FCTL, 32, Offset (0x6EF8), MUMD, 32 } Store (Zero, FCTL) Store (Zero, PSBH) Store (Zero, SSBH) Store (Zero, LTBC) Store (One, GENA) Store (Zero, MUMD) } } In case you have in-detail questions or need AML code for debugging (code to dump BARs or to dump the GPUs control register space) please let me know. I'm willing to share all my information in order support further research. Below you can find the register dumps I created attached to this post. FAQ Do I still have to select the IGPU as the primary display? No. Although I haven't tried this on my own, user chh1 confirmed that this is no longer required when using the patch (please see http://www.insanelymac.com/forum/topic/328549-tracing-back-the-amd-gpu-wakeup-issue-to-its-origin/?do=findComment&comment=2519884). Nevertheless I still recommend to select the IGPU as primary as there is absolutely no reason not to do so, in particular as the IGPU will be unusable for multimedia acceleration on Haswell based systems when it's not the primary one (IGPU's dev id is different when it's not the primary one). ​When I boot into macOS I always end up with a black screen. Does your patch solve this problem too? No, it doesn't. This patch solves the wakeup issue, nothin more and nothing less. The black screen after boot is either the result of a connector problem (please create a connector patch for your graphics card using the well-known methods) or the result of a problem with AGPM as certain system definitions (in particular recent iMacs) select special configurations for graphics power management. In order to achieve proper operation of AGPM it is crucial that your GPUs have correct names in the DSDT matching those listed in the AGPM configuration for the system definition (IGPU for the Intel GPU and GFX0 for the AMD GPU on iMac15,1, iMac17,1 and iMac18,x). You may patch your DSDT manually or use a Clover DSDT-patch to fix the device names. Credits vit9696 for developing Whatevergreen.kext and pointing me to the right direction. RehabMan for developing ACPIDebug.kext The Linux Radeon driver kernel developers for providing me with the background information I needed. Legacy.bin.zip UEFI.bin.zip
  14. Of course it's a typo and it should read "No-hda-gfx" but apart from that it can be injected in the same way as other properties. Mieze
  15. I just saw your post and wanted to share this piece of code which I used to dump the GPU's register space in order to investigate the wakeup issue. It adds the dump as property GBUF to the GPU's IORegistry entry while the system is booting so that it my be retrieved using IORegistryExplorer later. Have fun! Device (PEGP) { Name (_ADR, Zero) // _ADR: Address OperationRegion (PCIB, PCI_Config, Zero, 0x0100) Field (PCIB, AnyAcc, NoLock, Preserve) { Offset (0x04), CMDR, 16, Offset (0x10), BAR0, 32, BAR1, 32, BAR2, 64 } OperationRegion (GREG, SystemMemory, And (BAR2, 0xFFFFFFFFFFFFFFF0), 0x8000) Field (GREG, AnyAcc, NoLock, Preserve) { Offset (0x681C), SBS0, 32 } OperationRegion (GREF, SystemMemory, And (BAR2, 0xFFFFFFFFFFFFFFF0), 0x00010000) Field (GREF, AnyAcc, NoLock, Preserve) { GSRC, 524288 } Name (GBUF, Buffer (0x00010000) {}) Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Or (CMDR, 0x02), CMDR) Sleep (One) CopyObject (GSRC, GBUF) Store (Package (0x02) { "GBUF", GBUF }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } Mieze
  16. Since I replaced my my R9 270X with an RX570 a half year ago, I noticed that this strange kernel message was showing up after wakeup from sleep: kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms Although it doesn't seem to do much harm to the system, DisplayPort audio used to work well anyway, I'm curious like all cats and decided to investigate the issue. As I'm using system definition iMac18,3 it was the most obvious step to take a look at the IOReg dump of an original Apple machine of that type and compared it with mine. Checking device HDEF, I noticed that the iMac18,3 doesn't have the "hda-gfx" property on that device anymore but instead of it a "No-hda-gfx" property so that I decided to edit my HDEF's method _DSM in order to adopt this change and it made the error message after wakeup disappear. Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x06) { "No-hda-gfx", Buffer (0x08) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }, "layout-id", Buffer (0x04) { 0x01, 0x00, 0x00, 0x00 }, "PinConfigurations", Buffer (Zero) {} }) } Mieze
  17. Yes, the driver supports LACP. I successfully tested it in combination with a Realtek RTL8111E using my Realtek driver. Mieze
  18. Mieze

    New Driver for Realtek RTL8111

    Sorry, but this is off-topic.
  19. In the past there have always been reports of kernel panics after every major update of macOS and I also received some of them from users which upgraded to Mojave. It always turned out that the driver is innocent and I have no reason to assume that it's different this time. Anyway, I ran some tests with 10.14.1 this afternoon using the prebuilt binary from the download section and there haven't been any issues. Version 2.4.0 of IntelMausiEthernet works perfectly with Mojave. In case you are experiencing any problems, it's most likely because something went wrong during the update and you should try to fix your system. Mieze
  20. Being asked to add support for Realtek's Fast Ethernet PCIe NICs to my RTL8111 driver I got tired of answering the same old question again and again so that I finally decided to write a separate driver for these chips and to make a few of you guys and gals happy. As of now the driver supports the following members the RTL810X Fast Ethernet family: RTL8101E RTL8102E RTL8103E RTL8401E RTL8105E RTL8402 RTL8106E RTL8106EUS RTL8107E Here is a list of the driver's basic features: Supports Sierra (maybe El Capitan). 64 bit architecture only. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload under IPv4. Support for TCP/IPv6 and UDP/IPv6 checksum offload. Supports Wake on LAN. Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2. Built using Xcode 4.6.3. Changelog Version 2.0.1 (2018-05-10): Fixes a problem with retrieval of the permanent MAC address on some chips. Version 2.0.0 (2017-04-04): Uses Apple's private driver interface introduced with 10.8. Adds support for the RTL8107E. Supports packet scheduling with QFQ. Adds support for flow control and EEE. Version 1.0.0 (2014-05-24): First offical release. Installation Before you install the driver you have to remove any installed driver for RTL810X. Goto /S/L/E and delete the old driver. Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. If you forget this step you might experience strange problems with certain Apple domains, iTunes and iCloud later. Install the new driver and recreate the kernel cache. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface. Troubleshooting Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be retrieved with "grep kernel /var/log/system.log" in Terminal. Starting from Sierra use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me.  Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any other Realtek kext from your system because they could prevent the driver from working properly. Delete the following files: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard, different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable. Getting the driver There is a prebuilt binary in the Download section of this site: http://www.insanelymac.com/forum/files/file/259-realtekrtl8100-binary/ The source code can be found on Github: https://github.com/Mieze/RealtekRTL8100 Mieze
  21. @Sabrina13 and @kenzobengy: According to your description, this is not a driver issue. In case you can rule out a hardware problem, it's most likely a messed up network configuration or a DHCP related problem. Mieze
  22. Version 2.0.1

    13,573 downloads

    Driver for Realtek's RTL810X Fast Ethernet family of NICs which supports these chips: RTL8101E RTL8102E RTL8103E RTL8401E RTL8105E RTL8402 RTL8106E RTL8106EUS RTL8107E Features: Version 2.0.0 requires Sierra (may work on El Capitan too but this is untested). Previous versions of OS X are supported by version 1.0.0. 64 bit architecture only. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload under IPv4. Support for TCP/IPv6 and UDP/IPv6 checksum offload. Supports Wake on LAN. Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2.
  23. It's your call. Both methods work fine. Anyway you have to remove AppleIntelE1000e.kext in order to avoid conflicts. Mieze
  24. Most likely because your network configuration is messed up so that the names of the devices have been exchanged.
×