Graphics corruption @ 60hz on DP

[RDPRDP]

DisplayPort - Windows 7 (1) - 3440x1440@60hz - OK
DisplayPort - Windows 10 (2) - 3440x1440@60hz - OK
DisplayPort - OSX / Clover- 3440x1440@50hz - OK
DisplayPort - OSX / Clover - 3440x1440@60hz - NG


My monitor just came back from LG for repair to the OSD joystick, and now suddenly I cannot consistently get 60hz via DP at native resolution, I can only do 50hz consistently at native resolution. I swear I could do this before, and my other configs will do it with the same hardware (dual boot). Since the same hardware with Windows works, I think its my config that has somehow been corrupted since the repair job happened (an amazing coincidence!). A picture is attached, I tried everything with SwitchResX, but still am out of luck.

The kicker is sometimes, just sometimes I can get it to work, but most of the time it doesn't and I have to resort to 50hz.


thanks,
RDP

 

[RDPRDP]

desperate bump

 

[Edhawk]

If you provide the following information it might help your cause:

1. I assume you are using the Nvidia Web Drivers with the GTX 960, please confirm which version of the Nvidia drivers you are running.
2. I assume you are running High Sierra 10.13.6. Which if any Supplemental Updates have you installed? Which version of macOS High Sierra are you running, the System Version can be confirmed in System Information > Software report.
3. What graphics kexts, boot arguments and settings are you using in Clover?
4. Copy of your CLOVER folder, with the Themes folder removed and your SN/MLB etc. redacted, so we can see what you are using.

Have you seen any different behaviour when you have replaced/swapped the DisplayPort cable &/or used a different DP port on the GPU?

If you have a second display, does this behaviour happen no matter which monitor you are using, under macOS?

 

[RDPRDP]

Thanks so much for replying, this is still giving me lots of trouble.

1. Web Drivers are 387.10.10.10.40.140. I was having problems installing them (as I could never resolve the OSX build 17G66 issue, not matter what I tried, and could not find a compatible Web Driver pair), and I ended up using this: https://github.com/Benjamin-Dobell/nvidia-update to do the install, which worked after TWO restarts (the first boot took forever to boot, and was "laggy").

2. Correct, I am on 10.13.6. Everything is up to date via the App Store, however, as a precaution and as recommend on this site as a way to get "things to automatically download Web Drivers" I also downloaded and installed : https://support.apple.com/kb/DL2026?locale=en_US , however this didn't help to install the Web Drivers, hence my using the method in the first part of this post. Note: I'm not sure if its ever supposed to change, but my build remains locked on 17G66.

3. Hmmm, I'm not terribly experienced, but I believe the answer is none for graphics kexts and boot args based on looking at my config.plist via Clover Configurator. Would the config.plist submission in #4 contain what you need to examine the rest of the settings?

4. Attached.

Cable - Different DP port: Not anything repeatable that I recall.

I'll try my second display (cable is DP to DVI) which is a 1900x1200 native panel @60hz tomorrow and update this thread.

I wonder if it could be EDID related, or some override in SwitchResX?


thanks,
RDP

 

[Edhawk]

RDP, just going though your CLOVER folder and would make the following comments:

/CLOVER/ACPI/patched folder:
You have a Power Management SSDT (ssd.aml) and a CPU over clock SSDT (SSDT-SB-OC.aml) do you need both SSDT's? Don't they do the same thing, but with the OC SSDT adding a few extra power steps?

The ssdt.aml wants to open with TextEdit not MaciASL, which is the normal app to use for ACPI tables. So I am wondering if it is actually doing anything for your system. I have opened the SSDT with MaciASL and saved it as SSDT-PM.aml, so it defaults to opening with MaciASL not TextEdit.

Additional SSDT's:
I would recommend you add the following SSDT's to your /CLOVER/ACPI/patched folder, as they are required for newer versions of macOS and to help your system work more smoothly when running macOS:

• SSDT-OSXI.aml - used with ACPI rename patch to get PC system to work better with macOS.
• SSDT-EC.aml - Fake Embedded Control device for your system
• SSDT-HPET.aml - Deals with clashes with macOS IRQ settings
• SSDT-IMEI.aml - the IMEI, HECI and MEI device is missing from your system DSDT

I have added these additional SSDT's to the attached CLOVER folder.

/CLOVER - Drivers folders:
Your CLOVER folder contains a number of .efi driver folders, these include the following:

1. drivers
2. drivers32UEFI
3. drivers64
4. drivers64UEFI

I would recommend you remove folders 2-4 inclusive and just leave the drivers folder, as the newer versions of Clover use this folder before any of the others.

The drivers folder usually contains these sub-folders, BIOS, OFF and UEFI, OFF is missing from your's but that isn't an issue. These are the current Clover efi driver locations of choice.

I take it from the presence of the drivers32UEFI folder that you at some point installed CLOVER with a legacy setting selected. If there are any other legacy options these can also be removed.

/CLOVER/drivers/UEFI folder:
Your /CLOVER/drivers/UEFI folder contains a specific apfs.efi driver. I would recommend you change this to the newer ApfsDriverLoader.efi driver, which as the name states will load the correct/installed APFS driver from your system. So there is less chance of the wrong APFS driver being used or loaded.

I would also look at removing the EmuVariableUefi.efi driver. This is usually helpful when installing macOS, but after you are up and running it is more likely to cause you problems than help fix anything.

/CLOVER/kexts folder:
You have a number of empty and unused folders within the /CLOVER/kexts folder. These can be deleted as they serve no real purpose. This includes all the numbers folders, leaving just the Other folder, as that is used.

Until I know which kexts you are using I can't really comment on whether they are useful, necessary, need updating or not required.

However, I would suggest you move from FakeSMC.kext to VirtualSMC.kext. FakeSMC.kext has not been updated for sometime. While VirtualSMC.kext and its associated sensor kext and efi driver are being actively developed and updated.

Your /CLOVER/kexts/Other folder only contains FakeSMC.kext, where are the other kexts you use for your system? Are they in /System/Library/Extensions (/S/L/E) or the /Library/Extensions (/L/E) folder?

If yes to either macOS drive location, I would recommend you move them to your /CLOVER/kexts/Other folder.

You can copy and paste the kexts from /S/L/E or /L/E to your /CLOVER/kexts/Other folder.

I have added a number of common kexts to the attached /CLOVER/kexts/Other folder. So you can try the attached with less issues arising, hopefully.

1. AHCI_3rdParty_SATA.kext
2. AirportBrcmFixup.kext
3. AppleALC.kext
4. AppleIntelE1000e.kext
5. BrcmFirmwareData.kext
6. BrcmPatchRAM2.kext
7. Lilu.kext
8. USBInjectAll.kext
9. VirtualSMC.kext
10. WhateverGreen.kext

Clean Up & Repair /S/L/E or /L/E folders:
When you come to removing the kexts from their current location, whether that be /S/L/E or /L/E you need to make sure you Repair permissions and rebuild the Kernel Cache. You need to do this BEFORE you reboot the system. Otherwise you will mess up your system, so it won't boot.

As you are using High Sierra you can use Kext Utility or Hackintool to Repair Permissions and Rebuild the Kernel Cache.

/CLOVER folder:
You don't need the pref.plist or the Clover.app_instal.log. These two documents can be deleted.

Config.plist:
Your config.plist requires a number of patches, fixes and options added to help it work better with macOS. Way too many to list here, in this already substantial post.

Testing Revised CLOVER folder:
Do not immediately replace your current CLOVER folder on your macOS drive with the one attached below.

I would recommend you install Clover_r5119 to a spare USB. Make sure it is set for UEFI booting only and to boot from the ESP. Don't worry about any other settings/customisations these will have been dealt with in the attached CLOVER folder.

Once you have installed Clover to the EFI Partition on the USB drive, you can replace the CLOVER folder on the USB with the one attached here.

Once this replacement has been completed you are ready to boot from the USB UEFI partition. You need to do this via the Boot Option menu/feature for your Asus motherboard, press whichever 'F' key Asus use, press the key when the Splash screen appears (can't remember off the top of my head but it might be F8, I know Gigabyte use F12).

You will know when you have booted from the USB drive as the Clover boot theme will be different from the one you normally use. Just select your High Sierra drive and see what happens with the new CLOVER boot setup.

This should be thought of as a work in progress, so it may not work first time. Just take a screenshot/photo of any Kernel Panics and post it here so I can see what is happening, or not as the case may be.

Hope this is helpful, let me know if the Clover folder works or not.

 

[RDPRDP]

Wow. Send me an invoice. Thats way more that I ever expected. Thank you.

I don't get kernel panics, but it does restart through the verbose process. Refer to point 5 please.

1. I read carefully what you wrote, then figured out that your attached clover folder had already done everything you mentioned. Amazing, thanks so much as finding the proper files would have taken me a very long time.

2. I have not at this stage touched the SSDT's as I am over my head without a tutorial to go through (and maybe most importantly, knowing which is the correct one as sometimes they change over time to other contributors....). Hope that is ok for the now, please let me know if I need to take action.

3. I'm using a USB stick to boot using the exact version you specified, no problems there.

4. You caught me, I have my kexts in L/E or S/L/E. I know you said I could move them, but before I do I wanted to show you what I have. Attached are five files. Its a real mess in SLE..... . Once you give the ok I will move everything over with the cleanup and rebuild you instructed me to perform (I will use Hackintool).

5. I have two startup screenshots, one is with no changes, the other is with USBInjectAll removed as in my L/E folder I already have a USBPorts.kext due to my custom config. Not sure if that was good for me to remove it, but it provides a different reset position in the sequence. I can alway put it back.


thanks so very much,

RDP

 

[RDPRDP]

Small update:

1. I notice the serial number is different using your files (as expected!). Will not try to change it back until instructed.

2. I found that I can boot the system using the temporary USB drive if I boot with option "without injected kexts".

3. Just flagging that I still have USBInjectAll.kext taken out and replaced by USBPorts.kext due to my custom USB port config.


thanks,
RDP

 

[Edhawk]

Your /Library/Extensions folder contains a number of kexts that in my opinion should be removed and placed in your /CLOVER/kexts/Other folder.

• AppleALC.kext
• FakeSMC.kext
• 5 No FakeSMC sensor kexts
• Lilu.kext
• USBPorts.kext

You do not seem to have WhateverGreen.kext installed, which is surprising as it is the default kext for IGPU and dGPU fixes. Even when using the Nvidia Web Drivers.

There are a few other kexts in your /L/E folder that I am not sure about:

• NIUSBAudioDriver.kext*
• NIUSBGuitarRigMobile*
• NIUSBMaschineController.kext*
• RDUSB0013Dev.kext
• RMEFirefaceUSB.kext
• RMEUSBNetworkDriver.kext
• Tap.kext
• Tun.kext

Three of the kexts listed above and denoted with and * are also present in your /S/L/E folder, this is not good. It can cause issues if there are duplicate kexts in the kernel cache, especially if they are of different versions of the same kext. In your case only the two NIUSBMaschineController.kext are different versions, the one in /L/E being the newer of the two.

If these kexts are required then they should be installed to /L/E, they need to be removed from /S/L/E. The others, like I said I am unsure about there use and necessity, so I am unable to give an opinion as to whether they should be in the /L/E folder or moved to the /CLOVER/kexts/Other folder.

Your /S/L/E folder also contains a few kexts that in my opinion shouldn't be present in this folder:

• AppleIntelE1000e.kext - Your ethernet kext
• FocusriteUSBAudio.kext
• JMicronATA.kext - third-party SATA/ATA controller kext
• NIUSBAudioDriver.kext*
• NIUSBGuitarRigMobile*
• NIUSBMaschineController.kext*
• NovationUSBAudio.kext

Copies of the screenshots you provided with the suspect kexts highlighted are attached.

Removing USBInjectAll.kext is fine, as you are using a custom USBPorts.kext. This wasn't visible/present in the CLOVER folder you provided, so I made an assumption you didn't have one for your system. Wrong Assumption obviously. That being the case the High Sierra Raise USB port limit patch should also be disabled in the config.plist.

 

[Edhawk]

Here is a revised CLOVER folder with a few kexts removed, including USBInjectAll.kext and the Broadcom Bluetooth kexts. Hopefully these were the ones that prevented you booting with the initial revised CLOVER folder. Plus the config.plist has been edited, so the USB port limit patch is disabled.

When you try using this CLOVER folder, you need to make sure that the kexts marked for removal from /L/E and /S/L/E have been removed! You need to make sure you have repaired permissions and rebuilt the kernel cache, BEFORE you reboot the system.

Add your USBPorts.kext to the /CLOVER/kexts/Other folder. That should be the only change/addition you need to make to get this CLOVER folder booting.

 

[RDPRDP]

I'm writing to you from another device, as my internet no longer works on my system with the old clover installation, maybe because I moved a network device kext to my test USB clover installation? Anyway, not the end of the world while we troubleshoot, if desperate I can boot from a good config taken with CarbonCopy Cloner. I could not boot the test USB clover again today, here are my comments and screenshots.

1st try - First reboot after thinking I did everything you asked.
1st try - no kext injection = self explanatory
2nd try - I tried one more time to rebuild the Kext cache and repair permissions. *** You mention rebuilding the kernel cache, is that the same as the rebuilding the kext cache?***

Comments:

Once again you did a lot for me, so I did not move my AppleALC or LiLu to the clover/others folder as the versions you supplied were newer.

I deleted the duplicate NI kexts in S/L/E, leaving the L/E entries intact.

I didn't touch the below, but they are:

RDUSB0014DEV.kext = By Roland, so I assume for my USB audio device, or a USB MIDI device.
RME (times 2) = RME USB audio device related, one is for network control of the USB audio device.
tap & tun = VPN related if I recall correctly.

I moved all the kexts you asked to the USB clover test kexts/other folder.