Contribute
Register

How to enable 'Kaby Lake' Intel 6xx Graphics (10.12.6+)

Status
Not open for further replies.
pl0nk said:
A quickie before zzz-time: after many hours using Clover-injected kexts and no GFX trouble, I installed the kexts on system disk (removed them from clover kexts) and rebooted a couple times. kexts loaded fine but failure is as random as a ever: first boot I used for 30mn with no problem before rebooting again. next few boots "crashed" in under 2mn, exactly in the same fashion as before, so having the kexts Clover-injected was not the cause of the random issues. (note: didn't even try to add extra hidpi res at this point: I obviously want the thing to be stable in the "standard" setting before I go and add more uncertainty to the mix). I've shutdown and will run more tests tomorrow from a cold boot. Will report.
Click to expand...

No "Problem Reporting" files attached.
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
 
Report attached.

After experimenting a bit more, I can add the following elements:
  • The compositing corruption is visible in Screen Sharing (launched from a different box obviously), until I either turn off or switch the current input on my P2715Q (which is connected to the problematic system and to another one). After doing that it seems the framebuffer is disconnected and the remote display refreshes and is no longer corrupted. Turning the display back on / switching back to the correct input still shows corrupted graphics however.
  • The bug is apparently completely random, however it seems to have a higher likelihood of being triggered when selecting (clicking on) an unselected window.
  • The graphics corruption is always preceded by a few seconds of lag where the system becomes (graphically) completely unresponsive.
  • Running dmesg immediately after recovering responsiveness shows a dmesg buffer filled with "DumpGPURestart" errors (attached in the provided archive)
 

Attachments

  • Files5.zip
    3.2 MB · Views: 83
pl0nk said:
Report attached.

After experimenting a bit more, I can add the following elements:
  • The compositing corruption is visible in Screen Sharing (launched from a different box obviously), until I either turn off or switch the current input on my P2715Q (which is connected to the problematic system and to another one). After doing that it seems the framebuffer is disconnected and the remote display refreshes and is no longer corrupted. Turning the display back on / switching back to the correct input still shows corrupted graphics however.
  • The bug is apparently completely random, however it seems to have a higher likelihood of being triggered when selecting (clicking on) an unselected window.
  • The graphics corruption is always preceded by a few seconds of lag where the system becomes (graphically) completely unresponsive.
  • Running dmesg immediately after recovering responsiveness shows a dmesg buffer filled with "DumpGPURestart" errors (attached in the provided archive)
Click to expand...

Configuration looks as expected.
Time to experiment with different ig-platform-id values, different FakePCIID RM,device-id.
Note that you can inject RM,device-id from ACPI, which can lead to quicker turn around with testing (easier to replace a file in ACPI/patched, than to edit a kext, rebuild cache). And ig-platform-id experiments can be done within Clover options.

For example, this SSDT will inject RM,device-id=<16 59 00 00>:
Code: 
DefinitionBlock("", "SSDT", 2, "hack", "RM-IGPU", 0)
{
    Method (_SB.PCI0.IGPU._DSM, 4, NotSerialized)
    {
        If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
        Return (Package()
        {
            "RM,device-id", Buffer() { 0x16, 0x59, 0x00, 0x00 },
        })
    }
}

Monitor is connected via HDMI port? (that's what ioreg shows as connector-type... and you want to insure it matches the hardware).

Also experiment with Skylake graphics spoof.

FYI: No need for AddDTGP and FixACST in config.plist/ACPI/DSDT/Fixes. And you might want to review whether FixRTC and FixTMR are really needed. And EmuVariableUefi-64.efi may be required for your hardware (likely that native NVRAM is not working). Using the port limit patch for XHCI is not a good idea... remove and create custom SSDT for USBInjectAll such that you're within the 15-port limit.
 
Last edited:
RehabMan said:
Configuration looks as expected.
Time to experiment with different ig-platform-id values, different FakePCIID RM,device-id.
Note that you can inject RM,device-id from ACPI, which can lead to quicker turn around with testing (easier to replace a file in ACPI/patched, than to edit a kext, rebuild cache). And ig-platform-id experiments can be done within Clover options.

Monitor is connected via HDMI port? (that's what ioreg shows as connector-type... and you want to insure it matches the hardware).
Click to expand...

pl0nk said:
If it matters, I'm using the onboard DP output connected to a Dell P2715Q for 4k@60Hz.
Click to expand...

RehabMan said:
Also experiment with Skylake graphics spoof.

FYI: No need for AddDTGP and FixACST in config.plist/ACPI/DSDT/Fixes. And you might want to review whether FixRTC and FixTMR are really needed. And EmuVariableUefi-64.efi may be required for your hardware (likely that native NVRAM is not working). Using the port limit patch for XHCI is not a good idea... remove and create custom SSDT for USBInjectAll such that you're within the 15-port limit.
Click to expand...

pl0nk said:
Note: in those files i have disabled Clover's NVRAM emulation driver as I was switching from one SMBIOS definition to the other to avoid having incoherent/garbage values carried over.
Click to expand...
 
pl0nk said:
If it matters, I'm using the onboard DP output connected to a Dell P2715Q for 4k@60Hz.
Click to expand...

Your ioreg shows mismatched connector-type <00 08 00 00> (HDMI).
So you need to patch the framebuffer so it matches DP <00 04 00 00>.
Probably won't matter for the primary problem, but another detail to take care of such that everything is "correct".

Note: in those files i have disabled Clover's NVRAM emulation driver as I was switching from one SMBIOS definition to the other to avoid having incoherent/garbage values carried over.
Click to expand...

Keep in mind lack of working NVRAM can cause other strange things to happen that may further cloud any test results.
 
RehabMan said:
Configuration looks as expected.
Time to experiment with different ig-platform-id values, different FakePCIID RM,device-id.
Note that you can inject RM,device-id from ACPI, which can lead to quicker turn around with testing (easier to replace a file in ACPI/patched, than to edit a kext, rebuild cache). And ig-platform-id experiments can be done within Clover options.
Click to expand...
I honestly don't really have the time nor the inclination to poke blindly at a list of values (the quicker alternative for me being either swapping the CPU for an i5/i7 or getting a supported dGPU). A little bit of educated guessing tells me that:
  • Apple could have added the 0x3e91 id to their driver code (like they did for 0x3e92), but didn't, probably for a reason.
  • The only Gen9/9.5 iGPUs that have less than 24 execution units (besides the offending 0x3e91 I'm testing) are the HD510 and the HD610. The list of related CPUs on this page and this one shows none of the CPUs ever used by Apple in any of their products. Is there evidence of successful builds using iGPU on any of these CPUs? I think the G4560 (listed there) is known to be iGPU incompatible for instance.
  • The fact that the problem cannot be consistently reproduced across every boot/reboot would point the hardware guy in me toward a hardware state / initialisation problem (with the silicon randomly happening to be in the "correct" state).
Therefore I think it is reasonable to assume that Apple IGPU drivers do not (yet?) support 0x3e91 (and/or possibly Gen9/9.5 GPUs with less than 24 EUs), and that is probably the cause for the problems I am experiencing. Faking id alone will likely not solve what appears to be a more complex driver-related issue.

That said, if you can suggest one or two specific/targeted tests you'd like me to run I will do it, otherwise I think the i3-8xxx CPUs should probably not be considered for builds relying on iGPU (unless a subsequent OSX update adds driver support).

RehabMan said:
FYI: No need for AddDTGP and FixACST in config.plist/ACPI/DSDT/Fixes. And you might want to review whether FixRTC and FixTMR are really needed.
Click to expand...
I will check again. On my previous build it was either those or enabling kernel patching (for RTC at least), else KP if memory serves me right.

RehabMan said:
Your ioreg shows mismatched connector-type <00 08 00 00> (HDMI).
So you need to patch the framebuffer so it matches DP <00 04 00 00>.
Probably won't matter for the primary problem, but another detail to take care of such that everything is "correct".
Click to expand...
I should follow the explanations here: https://www.tonymacx86.com/threads/intel-hd-graphics-framebuffer-edits-desktop.125239/ I suppose?

RehabMan said:
Keep in mind lack of working NVRAM can cause other strange things to happen that may further cloud any test results.
Click to expand...
Agreed (I have re-enabled NVRAM emu). However I have been able to reproduce the exact same problems with NVRAM enabled: they are not related to the lack of NVRAM.

I should mention that I took a look at /var/log/system.log immediately after triggering the bug and spotted no relevant message there, which is why I didn't attach this info. The only consistently recurring bits are showing up in dmesg (DumpGPURestart and iokit-get-properties AAPL,IOGraphics_LER_...).

Finally I also noticed that the display took an unusual long time (probably just under a full minute) to wake up from sleep (display sleep, not computer sleep which I have disabled). This is without corruption happening before/after display sleep.
 
pl0nk said:
I honestly don't really have the time nor the inclination to poke blindly at a list of values (the quicker alternative for me being either swapping the CPU for an i5/i7 or getting a supported dGPU). A little bit of educated guessing tells me that:
Click to expand...

My suggestion was not to "blindly" poke at anything.

Apple could have added the 0x3e91 id to their driver code (like they did for 0x3e92), but didn't, probably for a reason.
Click to expand...

The reason is typically that they have no plans to use that hardware in any of their products.
Which means spoof/patch for us.

The only Gen9/9.5 iGPUs that have less than 24 execution units (besides the offending 0x3e91 I'm testing) are the HD510 and the HD610.
Click to expand...

HD510 and HD610 are GT1, and Apple has had spotty support for GT1. In cases where they had the support, it was removed in later revisions (Capri/HD2500, for example).

Therefore I think it is reasonable to assume that Apple IGPU drivers do not (yet?) support 0x3e91 (and/or possibly Gen9/9.5 GPUs with less than 24 EUs), and that is probably the cause for the problems I am experiencing. Faking id alone will likely not solve what appears to be a more complex driver-related issue.
Click to expand...

Spoofing to get the drivers to load is just an initial step. Further patching always possible... and likely required.

That said, if you can suggest one or two specific/targeted tests you'd like me to run I will do it, otherwise I think the i3-8xxx CPUs should probably not be considered for builds relying on iGPU (unless a subsequent OSX update adds driver support).
Click to expand...

Most people will use it only for installation, then enable a dedicated graphics card anyway.

I should follow the explanations here: https://www.tonymacx86.com/threads/intel-hd-graphics-framebuffer-edits-desktop.125239/ I suppose?
Click to expand...

I just use a hex editor to look at the ig-platform-id data, then create a patch for config.plist...KextsToPatch.

I should mention that I took a look at /var/log/system.log immediately after triggering the bug and spotted no relevant message there, which is why I didn't attach this info.
Click to expand...

Keep in mind Sierra and later do not use /var/log/system.log for kernel logs (refer to new 'log' command, eg. 'man log').

Finally I also noticed that the display took an unusual long time (probably just under a full minute) to wake up from sleep (display sleep, not computer sleep which I have disabled). This is without corruption happening before/after display sleep.
Click to expand...

Could be related, or could be another/separate issue.
 
RehabMan said:
Configuration looks as expected.
Time to experiment with different ig-platform-id values, different FakePCIID RM,device-id.
Note that you can inject RM,device-id from ACPI, which can lead to quicker turn around with testing (easier to replace a file in ACPI/patched, than to edit a kext, rebuild cache). And ig-platform-id experiments can be done within Clover options.

For example, this SSDT will inject RM,device-id=<16 59 00 00>:
Code: 
DefinitionBlock("", "SSDT", 2, "hack", "RM-IGPU", 0)
{
    Method (_SB.PCI0.IGPU._DSM, 4, NotSerialized)
    {
        If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
        Return (Package()
        {
            "RM,device-id", Buffer() { 0x16, 0x59, 0x00, 0x00 },
        })
    }
}
Click to expand...

Do you need FAKEPCIID.kext to use this ssdt? Also, do you have a suggested device id for HD630? I'm having the same freeze (but not the corruption unless I enable HWP/speedshift)
details: https://www.tonymacx86.com/threads/...accelfencemachine-errors.240066/#post-1645771
 
Build 1
Fatal1ty Z270 Gaming-ITX/ac |  i7 7700K |  Radeon Other
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top