Jump to content
Mieze

IntelMausiEthernet.kext for Intel onboard LAN

965 posts in this topic

Recommended Posts

Just as a write this, I managed to reproduce the problem (still doing backups and testing simultaneously ... it must have found some unique data to send)

 

This time it happened with my DSDT patched to rid of GBES declarations/tests as you described.

 

So, as I predicted, the DSDT is not the problem. I'll keep looking, but given that it only happens in a relatively rare heavy traffic scenario, I'm not as worried about it.

 

The patch I developed was originally made for 9 series mainboards which also had a code sequence writing to the PCI power management register (see below) so that I'm not surprised that it didn't help you as there is no write access to the register.

        Device (GLAN)
        {
            Name (_ADR, 0x00190000)
            OperationRegion (GLBA, PCI_Config, Zero, 0x0100)
            Field (GLBA, AnyAcc, NoLock, Preserve)
            {
                DVID,   16, 
                        Offset (0xCC), 
                        Offset (0xCD), 
                PMEE,   1, 
                    ,   6, 
                PMES,   1
            }

            Method (_PRW, 0, NotSerialized)
            {
                Return (GPRW (0x0D, 0x04))
            }

            Method (_DSW, 3, NotSerialized)
            {
                Store (Arg0, PMEE)
            }

            Method (GPEH, 0, NotSerialized)
            {
                If (LEqual (DVID, 0xFFFF))
                {
                    Return (Zero)
                }

                If (LAnd (PMEE, PMES))
                {
                    Store (One, PWST)
                    Store (One, PMES)
                    Notify (GLAN, 0x02)
                }
            }
        } 

I've logged and analyzed dozens of these incidents and found nothing. I checked the NIC's config registers, the descriptors and the packets without finding any hint. There is no indication for a systematic error and no common ground for these transmitter deadlocks. Most of the logged packets where TSO operations, which is no wonder when you are moving large amounts of data with TCP, but I also found small ACKs and UDP datagrams. The packets as well as the descriptors were correct and matched each other. The fact that it only happens under load is just a consequence of the design: you can't have a transmitter deadlock without transmitter activity and you need transmitter activity in order to detect it.

 

The reason why I'm quite sure that there is something interfering is the fact that users reported the same issue with the Realtek and the Atheros drivers too. For example see http://www.insanelymac.com/forum/topic/300056-solution-for-qualcomm-atheros-ar816x-ar817x-and-killer-e220x/?p=2128204 and in those cases where the issue was resolved it turned out that it was related to power management or a wrong BIOS setting, e.g. external interference.

 

Mieze

Share this post


Link to post
Share on other sites
Advertisement

The patch I developed was originally made for 9 series mainboards which also had a code sequence writing to the PCI power management register (see below) so that I'm not surprised that it didn't help you as there is no write access to the register.

        Device (GLAN)
        {
            Name (_ADR, 0x00190000)
            OperationRegion (GLBA, PCI_Config, Zero, 0x0100)
            Field (GLBA, AnyAcc, NoLock, Preserve)
            {
                DVID,   16, 
                        Offset (0xCC), 
                        Offset (0xCD), 
                PMEE,   1, 
                    ,   6, 
                PMES,   1
            }

            Method (_PRW, 0, NotSerialized)
            {
                Return (GPRW (0x0D, 0x04))
            }

            Method (_DSW, 3, NotSerialized)
            {
                Store (Arg0, PMEE)
            }

            Method (GPEH, 0, NotSerialized)
            {
                If (LEqual (DVID, 0xFFFF))
                {
                    Return (Zero)
                }

                If (LAnd (PMEE, PMES))
                {
                    Store (One, PWST)
                    Store (One, PMES)
                    Notify (GLAN, 0x02)
                }
            }
        } 
I've logged and analyzed dozens of these incidents and found nothing. I checked the NIC's config registers, the descriptors and the packets without finding any hint. There is no indication for a systematic error and no common ground for these transmitter deadlocks. Most of the logged packets where TSO operations, which is no wonder when you are moving large amounts of data with TCP, but I also found small ACKs and UDP datagrams. The packets as well as the descriptors were correct and matched each other. The fact that it only happens under load is just a consequence of the design: you can't have a transmitter deadlock without transmitter activity and you need transmitter activity in order to detect it.

 

The reason why I'm quite sure that there is something interfering is the fact that users reported the same issue with the Realtek and the Atheros drivers too. For example see http://www.insanelymac.com/forum/topic/300056-solution-for-qualcomm-atheros-ar816x-ar817x-and-killer-e220x/?p=2128204 and in those cases where the issue was resolved it turned out that it was related to power management or a wrong BIOS setting, e.g. external interference.

 

Mieze

 

It would be nice if there was a way to fix the stalled transmitter without bringing down the link.

 

Possible?

Share this post


Link to post
Share on other sites

It would be nice if there was a way to fix the stalled transmitter without bringing down the link.

 

Possible?

 

In order to recover from this condition you need to reset the NIC and it will be difficult to achieve without loosing the link. Of course you don't need to tell the network stack about it but I doubt that this is a good idea because of the side effects. Trying to find the cause is a more promising approach from my point of view.

 

Mieze

Share this post


Link to post
Share on other sites

In order to recover from this condition you need to reset the NIC and it will be difficult to achieve without loosing the link. Of course you don't need to tell the network stack about it but I doubt that this is a good idea because of the side effects.

I thought of the same idea (delay reporting the link down condition, until it is clear it is not coming back up).

 

But didn't even bother because of the rarity of this problem and because doing so would require a relatively long delay (10 sec, maybe more). That said, it would be possible to restrict this delay only to the case of a forced reset due to deadlocked transmitter, which makes it a bit more acceptable. I think if the link didn't go down, the system would recover better from the problem.

 

But I understand your reluctance to hack around this problem...

Share this post


Link to post
Share on other sites

I thought of the same idea (delay reporting the link down condition, until it is clear it is not coming back up).

 

But didn't even bother because of the rarity of this problem and because doing so would require a relatively long delay (10 sec, maybe more). That said, it would be possible to restrict this delay only to the case of a forced reset due to deadlocked transmitter, which makes it a bit more acceptable. I think if the link didn't go down, the system would recover better from the problem.

 

But I understand your reluctance to hack around this problem...

 

As long as you don't know exactly what went wrong the only reliable method to restore full operation is a complete reset but once you located the cause of the problem it's usually easier to eliminate it instead of creating a workaround.

 

Mieze

Share this post


Link to post
Share on other sites

It appears I am having the same problem as RehabMan. Same error after extended high speed transfers to NAS storage device:

kernel[0]: Ethernet [IntelMausi]: Tx stalled? Resetting chipset. txDirtyDescIndex=796, STATUS=0x40080083, TCTL=0x3103f0fa.

This is the device I am using:

Intel 82579V PCI Express Gigabit Ethernet:

  Name:	Intel Ethernet Controller
  Type:	Ethernet Controller
  Bus:	PCI
  Slot:	Built In
  Vendor ID:	0x8086
  Device ID:	0x1503
  Subsystem Vendor ID:	0x1458
  Subsystem ID:	0xe000
  Revision ID:	0x0004
  BSD name:	en0
  Kext name:	IntelMausiEthernet.kext
  Location:	/System/Library/Extensions/FakeSMC.kext/Contents/PlugIns/IntelMausiEthernet.kext
  Version:	2.0.0

As seen in the iStat screenshot, the transfers can go for quite a while before failing, whereas other times it will fail in just a short period of time. I'm using rsync to copy over a lot of files, with an until loop to retry the command after 10 seconds until it exits cleanly. Directory-intensive transfers lower the overall throughput, to the effect that it rarely stalls, whereas large movie transfers see stalling more frequently. Another thing I have noticed is that if I create more "noise" in the traffic, for example browsing a lot of directories on the NAS share or opening up quick-look previews while the large transfer is going, it seems to crash more often.

Attached is my DSDT (which appears to not contain any special power-management calls like your previous post), a system log of all IntelMausi debug errors over a long period of time, and one log of all the system events surrounding one crash. There are no specific power management features that I can toggle in the BIOS, and I get crashes whether WOL is enabled or not. Ethernet configuration is set to basic full-duplex as recommended, however, even with EEE and flow-control the crashes persist, although flow-control appears to not be enabled/supported on my hardware.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 4
	eflags=8c0<ACCEPT_RTADV,TXSTART,ARPLL>
	options=6b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4,TSO6>
	ether 90:2b:34:XX:XX:XX 
	inet6 fe80::922b:34ff:XXXX:XXXX%en0 prefixlen 64 scopeid 0x4 
	inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
	inet6 2002:4b6f:e5a4::922b:34ff:XXXX:XXXX prefixlen 64 autoconf 
	inet6 2002:4b6f:e5a4::a85c:e70a:223a:2590 prefixlen 64 autoconf temporary 
	nd6 options=1<PERFORMNUD>
	media: autoselect (1000baseT <full-duplex>)
	status: active
	type: Ethernet
	link quality: 100 (good)
	scheduler: QFQ 
	link rate: 1.00 Gbps

I appreciate all the work you have done on this and thank you for looking in to this problem.

Logs.zip

post-199409-0-99609800-1439109125_thumb.png

DSDT.aml.zip

Share this post


Link to post
Share on other sites

@RehabMan:  Intel's datasheets of the 82579 and the I217 contain the following advice with regard to the transmit descriptor handling policy.

post-983225-0-74133700-1439139065_thumb.png

The strange thing is that neither the Windows nor the Linux driver follow this advice but on my I217, which was affected of random tx deadlocks in early development versions of the driver too, setting TXDCTL=0 eliminated the problem. That's why I added this workaround in version 2.0.0d2 but as I don't have an 82579 to test on, I haven't been able to verify it on this NIC.

/**
 * intelConfigureTx - Configure Transmit Unit after Reset
 * @adapter: board private structure
 *
 * Configure the Tx unit of the MAC after a reset.
 **/
void IntelMausi::intelConfigureTx(struct e1000_adapter *adapter)
{
    struct e1000_hw *hw = &adapter->hw;
    UInt32 tctl, tarc;
    UInt32 txdctl;
    
    /* Setup the HW Tx Head and Tail descriptor pointers */
    intelInitTxRing();
    
    /* Set the Tx Interrupt Delay register */
    intelWriteMem32(E1000_TIDV, adapter->tx_int_delay);
    /* Tx irq moderation */
    intelWriteMem32(E1000_TADV, adapter->tx_abs_int_delay);
    
    txdctl = intelReadMem32(E1000_TXDCTL(0));

    if (chipType == board_pch_lpt) {
        txdctl = 0;
        intelWriteMem32(E1000_TXDCTL(0), txdctl);
    }
    /* erratum work around: set txdctl the same for both queues */
    intelWriteMem32(E1000_TXDCTL(1), txdctl);

    /* Program the Transmit Control Register */
    tctl = intelReadMem32(E1000_TCTL);
    tctl &= ~E1000_TCTL_CT;
    tctl |= E1000_TCTL_PSP | E1000_TCTL_RTLC | (E1000_COLLISION_THRESHOLD << E1000_CT_SHIFT);
    
    /* errata: program both queues to unweighted RR */
    if (adapter->flags & FLAG_TARC_SET_BIT_ZERO) {
        tarc = intelReadMem32(E1000_TARC(0));
        tarc |= 1;
        intelWriteMem32(E1000_TARC(0), tarc);
        tarc = intelReadMem32(E1000_TARC(1));
        tarc |= 1;
        intelWriteMem32(E1000_TARC(1), tarc);
   }
   intelWriteMem32(E1000_TCTL, tctl);

   hw->mac.ops.config_collision_dist(hw);
}

EDIT: Checking the source code again I discovered that the workaround I described above is only applied to the I217 and I218 while the 82579 still uses the default transmit descriptor handling policy. Please change

if (chipType == board_pch_lpt) {  

into

if ((chipType == board_pch_lpt) || (chipType == board_pch2lan)) { 

in order to apply it to the 82579 too. Please report back. In case of a positive result I will include the workaround in the next update. Good luck!

 

Mieze

Edited by Mieze

Share this post


Link to post
Share on other sites

@RehabMan:  Intel's datasheets of the 82579 and the I217 contain the following advice with regard to the transmit descriptor handling policy.

attachicon.gifBildschirmfoto 2015-08-09 um 18.49.58.png

The strange thing is that neither the Windows nor the Linux driver follow this advice but on my I217, which was affected of random tx deadlocks in early development versions of the driver too, setting TXDCTL=0 eliminated the problem. That's why I added this workaround in version 2.0.0d2 but as I don't have an 82579 to test on, I haven't been able to verify it on this NIC.

/**
 * intelConfigureTx - Configure Transmit Unit after Reset
 * @adapter: board private structure
 *
 * Configure the Tx unit of the MAC after a reset.
 **/
void IntelMausi::intelConfigureTx(struct e1000_adapter *adapter)
{
    struct e1000_hw *hw = &adapter->hw;
    UInt32 tctl, tarc;
    UInt32 txdctl;
    
    /* Setup the HW Tx Head and Tail descriptor pointers */
    intelInitTxRing();
    
    /* Set the Tx Interrupt Delay register */
    intelWriteMem32(E1000_TIDV, adapter->tx_int_delay);
    /* Tx irq moderation */
    intelWriteMem32(E1000_TADV, adapter->tx_abs_int_delay);
    
    txdctl = intelReadMem32(E1000_TXDCTL(0));

    if (chipType == board_pch_lpt) {
        txdctl = 0;
        intelWriteMem32(E1000_TXDCTL(0), txdctl);
    }
    /* erratum work around: set txdctl the same for both queues */
    intelWriteMem32(E1000_TXDCTL(1), txdctl);

    /* Program the Transmit Control Register */
    tctl = intelReadMem32(E1000_TCTL);
    tctl &= ~E1000_TCTL_CT;
    tctl |= E1000_TCTL_PSP | E1000_TCTL_RTLC | (E1000_COLLISION_THRESHOLD << E1000_CT_SHIFT);
    
    /* errata: program both queues to unweighted RR */
    if (adapter->flags & FLAG_TARC_SET_BIT_ZERO) {
        tarc = intelReadMem32(E1000_TARC(0));
        tarc |= 1;
        intelWriteMem32(E1000_TARC(0), tarc);
        tarc = intelReadMem32(E1000_TARC(1));
        tarc |= 1;
        intelWriteMem32(E1000_TARC(1), tarc);
   }
   intelWriteMem32(E1000_TCTL, tctl);

   hw->mac.ops.config_collision_dist(hw);
}

EDIT: Checking the source code again I discovered that the workaround I described above is only applied to the I217 and I218 while the 82579 still uses the default transmit descriptor handling policy. Please change

if (chipType == board_pch_lpt) {  
into

if ((chipType == board_pch_lpt) || (chipType == board_pch2lan)) { 
in order to apply it to the 82579 too. Please report back. In case of a positive result I will include the workaround in the next update. Good luck!

 

Mieze

 

Thanks... I'll give it a try. No time to test for a while (due to the intermittent nature of the problem, it is very time consuming), but I'll let you know when I do.

Share this post


Link to post
Share on other sites

 

What do you mean by: 

  1. Call "Archive" from the menu "Product" and save the built driver.

 

The first clause should be clear. In order to save the driver select it in the Organizer, which is opened automatically, and click "Export". Now select "Save Built Products", click "Next" and select a directory where the products should be saved, for example the desktop, and confirm with "Export". Finally open the saved folder in Finder and you'll find a subdirectory hierarchy called "System/Library/Extensions" in it. There you will find your driver.

 

Mieze

Share this post


Link to post
Share on other sites

The first clause should be clear. In order to save the driver select it in the Organizer, which is opened automatically, and click "Export". Now select "Save Built Products", click "Next" and select a directory where the products should be saved, for example the desktop, and confirm with "Export". Finally open the saved folder in Finder and you'll find a subdirectory hierarchy called "System/Library/Extensions" in it. There you will find your driver.

 

Mieze

I would like to apologise for not being familiar with xcode, but i am really only getting into hackintoshing in general since yesterday. When i open organizer i do not get an export option (i do get an export screenshot option). As for saving, that is greyed out and so is export.

Some screenshots:

https://puu.sh/jwOAc/03da255ecc.png

https://puu.sh/jwOBm/bb25a4b910.png

https://puu.sh/jwOCk/63c56e0e9c.png

http://puu.sh/jwP0R/c55cf82150.png 

Share this post


Link to post
Share on other sites

The first clause should be clear. In order to save the driver select it in the Organizer, which is opened automatically, and click "Export". Now select "Save Built Products", click "Next" and select a directory where the products should be saved, for example the desktop, and confirm with "Export". Finally open the saved folder in Finder and you'll find a subdirectory hierarchy called "System/Library/Extensions" in it. There you will find your driver.

 

Mieze

Xcode has seriously brain damaged defaults when it comes to build products...

Not sure what they were thinking...

 

I set Xcode->Preferences->Locations->Advanced->Custom "Relative to Workspace".

This way you can find your build results in ./Build relative to the project instead of some far off place with a random garbage name.

Share this post


Link to post
Share on other sites

In older versions of Xcode the button is called "Distribute…".

XD I installed the latest version but then reverted to 5.1.1 because i was so confused on what to do. Thanks, everything is working great :D

Share this post


Link to post
Share on other sites

Woohoo! I complied with the changes you suggested above and it doesn't seem to be crashing! I copied a large file from one network share to another (maximally stressing both upload and download), as well as random I/O on the network as well. Usually, this always guarantees a crash, but it's been holding up this time!

However, the console appears to be flooded with 

Ethernet [IntelMausi]: replaceOrCopyPacket() failed.

and 

Ethernet [IntelMausi]: Not enough descriptors. Stalling.
Ethernet [IntelMausi]: Restart stalled queue!

Other than that it is--at least initially--working. I'll report back if I get any disconnects, but thanks for the fix!

 

I attached the binary for 10.10 for anyone who can't compile themselves.

Console.log.zip

IntelMausiEthernet.kext.zip

Share this post


Link to post
Share on other sites

Oops, you are right. I don't use Xcode much, but I poked around a bit and got it to recompile as 2.0.0. And now... nooooo! Still failed like before, although it looks like it put up with more of a beating than the original V2 version used to take. Also, I might have posted prematurely on the v1.0.0 post, but I tested it hard for a good 30 mins without failure, whereas this one failed after about 10 minutes.

Console.log.zip

IntelMausiEthernetV2.kext.zip

Share this post


Link to post
Share on other sites

@The Edge3000: This is a hardware issue which is independent of the driver version. It affects version 1.0.x as well as 2.0.x. Please send me a complete ACPI dump of your machine (DSDT and SSDTs). 

 

Mieze

Edited by Mieze

Share this post


Link to post
Share on other sites

 @The Edge3000: Looks ok. I found nothing which might interfere. Let's see what results RehabMan will have.  :unsure:

 

EDIT: Are you sure you have disabled all of these items in the UEFI setup?

  • Network stack
    Disables or enables booting from the network to install a GPT format OS, such as installing the OS from the Windows Deployment Services server. (Default: Disable Link)

  • &  IPv6 PXE Boot Support
    Enables or disables IPv6 PXE Support. This item is configurable only when Network stack is enabled.

  • &  IPv4 PXE Boot Support
    Enables or disables IPv4 PXE Support. This item is configurable only when Network stack is enabled. 

  • LAN PXE Boot Option ROM

Allows you to decide whether to activate the boot ROM integrated with the onboard LAN chip. (Default: Disabled) 

 

Besides that, are you overclocking?

 

Mieze

Edited by Mieze

Share this post


Link to post
Share on other sites

Hey Mieze, sorry for the late response. Work got in the way, etc. 
 
To answer your question, both of those options are disabled. I am overclocking, but only by raising the CPU multiplier. I am not messing with any voltages or overclocking the BCLK.
 
I don't know if this would have any effect or not, but my BIOS mod (GA-Z77X-UD5H BIOS F16 mod11) per TweakTown forums includes the change "Intel GigabitLanX64 6.0.24 to 6.3.27"

Share this post


Link to post
Share on other sites

I don't know if this would have any effect or not, but my BIOS mod (GA-Z77X-UD5H BIOS F16 mod11) per TweakTown forums includes the change "Intel GigabitLanX64 6.0.24 to 6.3.27"

 

Frankly, I don't know. What does the change do?

 

Mieze

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   1 member

Announcements

  • Similar Content

    • By Mieze
      This project is dedicated to Lucy, my lovely little Tyrannofelis Rex. 
       

       
      LucyRTL8125Ethernet is an open source driver for the Realtek RTL8125 family of 2.5GBit Ethernet controllers.
       
      Key Features of the Driver
      Supports all versions of Realtek's RTL8125 2.5GBit Ethernet Controllers 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 over IPv4 and IPv6. Support for TCP/IPv4, UDP/IPv4, TCP/IPv6 and UDP/IPv6 checksum offload. Supports jumbo frames up to 9000 bytes (strongly recommended for 2.5GBit operation). Fully optimized for Catalina (doesn't work with Mojave and below). Note that older versions of macOS might not support 2.5GB Ethernet. Supports Wake on LAN (untested). Supports VLAN (untested). 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.  
      Current Status
      The driver has been tested successfully under Catalina (10.15.4 and above) and, according to first tests, is working stable. I haven't experienced any Kernel Panics during my tests and is working stable on my primary work machine. The driver has been designed to work with Catalina but might also work with Mojave, provided you build from source with Xcode 10.. Please keep in mind that support for 2.5GBit Ethernet was introduced in Mojave (or maybe High Sierra?) so that there is no way to make it work with Sierra or below.  
      Known Issues
      Using autoselect medium it seems to prefer negotiating a connection speed of 1Gbit with my switch so that I had to select 2.5GBit/s manually in order to achieve this speed but it might be different with other switches.   Installation
      You might want to install the driver to /L/E as usual but it's also ok to use Clover's injection function (installation in the EFI folder). Use your favorite kext installation tool for installation or perform the installation manually (for Clover injection). It's your call!  
      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 "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.  Delete the following files: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist 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 1.0.0d6 (2020-06-14) Fixed chip recognition. Version 1.0.0d3 (2020-04-20) First working development release.  
      Getting the driver
      Source code can be found on GitHub: https://github.com/Mieze/LucyRTL8125Ethernet You'll find the lastest prebuilt binary (version 1.0.0d6) here in this thread (see this post https://www.insanelymac.com/forum/topic/343542-lucyrtl8125ethernetkext-for-realtek-rtl8125/?do=findComment&comment=2725790).  
       
    • By sapnupuas69
      hello everyone, so my Intel HD 530 is not getting recognised by macOS. In the about my mac section, it shows as 'Display 7mb'
      Im using HDMI connected to motherboard. I can only boot into os with 0x12345678 or 0x193b0005 as Fake Id and 0x19120000 as platform id with Mac17,1 as smbios. I do have the latest version of Lilu and WhateverGreen installed in boot loader and in L/E too. 
      I have looked through many forum posts, and have not found a solution yet. 
       

      edit: i forgot to change the smbios in the picture, I tried changing to 17,1 and restart, still no luck
      EFI.zip
    • By MaLd0n
      First...
      If you need DSDT edits... -Extract tables with F4 key in Clover boot screen! -Run it and send me files! RunMe.app   Installation --Create a bootable copy of El Capitan /  Sierra / High Sierra / Mojave https://github.com/chris1111/Create-Install-Media/releases   --Install Clover in USB stick https://github.com/CloverHackyColor/CloverBootloader/releases   --Replace with my Clover folder https://www.olarila.com/topic/5676-clover-folder-for-all-chipsets/   --Install EL Capitan / Sierra / High Sierra and boot into system!     Post Installation   --Install Clover and replace with my folder   https://www.olarila.com/topic/5676-clover-folder-for-all-chipsets/     --Reboot and activate video!   Bingo! Now you need a fine tune! DSDT Time!   My DSDT GA P35-DS3   DSDT.MaLd0n.zip     Patches -FIX ERRORS AND WARNINGS -HPET -SATA -SLPB -DARWIN -LPC -HDEF -RTC -EHCI -UHCI -IRQs -SBUS -BUS1 -MCHC -ALS0 -SHUTDOWN -LAN -EC -PNLF --Native Power Management
       
      Use Clover, check Generate P and C States
       
      --Brightness
      Install .app, select the required permission and reboot. Work in F1 / F2 keys!
      NativeDisplayBrightness.app.zip


      https://github.com/Bensge/NativeDisplayBrightness/releases
      *in some cases .app don't work, check patches in config.plist inside Clover folder Post Install
       
      --AUDIO
       
      Device HDEF + AppleAlc + Lilu
       
      --install Lan driver by Mieze
        -Atheros   http://www.insanelymac.com/forum/files/file/313-atherose2200ethernet/   -Intel   http://www.insanelymac.com/forum/files/file/396-intelmausiethernet/   -Realtek   http://www.insanelymac.com/forum/files/file/88-realtekrtl8111-binary/   --Links   -FakeSMC   https://bitbucket.org/RehabMan/os-x-fakesmc-kozlek   -Audio   https://github.com/vit9696/AppleALC http://www.insanelymac.com/forum/topic/293863-applehda-patch-requests/   -Credits and thanks to the old and new people in the community who developed patches, kexts and bootloaders!   Slice, Kabyl, usr-sse2, jadran, Blackosx, dmazar, STLVNUB, pcj, apianti, JrCs, pene, FrodoKenny, skoczy, ycr.ru, Oscar09, xsmile, SoThOr, RehabMan, Download-Fritz, Zenit432, cecekpawon, Intel, Apple, Oracle, Chameleon Team, crazybirdy, Mieze, Mirone, Oldnapalm, netkas, Elconiglio, artut-pt, ErmaC, Pavo, Toleda, Master Chief and family, bcc9, The King, PMheart, Sherlocks, Micky1979, vit9696, vandroiy2013, Voodoo Team, Pike R. Alpha, lvs1974, Austere.J, CVad and many, many, many others!   We're all here to have fun and learn from each other!   ENJOY!  
    • By poisson-myfish
      So I have some less powerful hardware, that's why I'm installing High Sierra in 2020. Anyway, I'm trying to boot from the USB and I get the following errors:
      00:000 00:000 OCB: Missing DMG signature, aborting 00:585 00:585 OCB: LoadImage failed - Unsupported That's it. The logs begin and end there. The rest of the file is zeroes.
       
      Bootloader: OpenCore 0.5.9 Release
      Drivers:
      HfsPlus.efi
      OpenRuntime.efi
       
      Kexts:
      AppleALC.kext
      Lilu.kext
      RealtekRTL8111.kext
      SMCBatteryManager.kext
      SMCLightSensor.kext
      SMCProcessor.kext
      SMCSuperIO.kext
      VirtualSMC.kext
      WhateverGreen.kext
       
      ACPI:
      SSDT-EC.aml
      SSDT-HPET.aml
      SSDT-PLUG.aml
      Note: I used SSDTTime to make the DSDT dumps for this exact computer
       
      Hardware:
      Intel Core i3 (Haswell)
      An Intel VGA-Compatible Haswell iGPU
      An nVidia Geforce 920m GPU (part of the reason for installing High Sierra)
      USB: Intel 8 Series USB xHCI HC
      SATA: Intel 8 series SATA Controller
       
      If you need more details, here's my laptop https://www.asus.com/Laptops/X540LJ/ . I have the 512GB version with 4GB of RAM
       
      I found a lot of forum posts about people having the same error, except nothing solved mine. Also, I haven't found anything online about the error with the Missing DMG Signature.
       
      EDIT: If anybody needs my config.plist, feel free to ask for it and I'll happily post it
    • By Yosa Tristian
      Can someone help me?
      When I turn on the USB Wireless Adapter (Wifi Dongle), my mouse is lagging (like quick ejecting & rejecting).
      When I turn off the Wifi Dongle, my mouse runs smooth again.
       
      Mouse: Fantech G13 Rhasta II
      Wifi Dongle: TPLink TL-WN725N
      Wifi Dongle Driver : https://github.com/chris1111/Wireless-USB-Adapter
       
      And if you don't mind, can you check my hackintosh configuration? maybe something isn't right yet
      Send me Yosas-MacBook-Pro.zip
×