[FIX] Coffee Lake Intel UHD Graphics 630 on macOS Mojave: Kernel panic due to divide-by-zero

[andythedev]

This is:

I appreciate the work you've done but i think you're overlooking the fact that sometimes there's value in community discussion.

It wasn't a request for help, it wasn't an issue report (the issue I referenced has already been well documented in this forum) - just a discussion.

That being said, now we're definitely going off topic... Apologies OP.

 

[RehabMan]

I appreciate the work you've done but i think you're overlooking the fact that sometimes there's value in community discussion.

It wasn't a request for help, it wasn't an issue report (the issue I referenced has already been well documented in this forum) - just a discussion.

That being said, now we're definitely going off topic... Apologies OP.

Reporting symptoms/results without the input (PR files) that cause it does not lead to useful discussions.

 

[Austere.J]

I have identified the real issue that caused the kernel panic.

The current patch is now deprecated and may have an impact on no display after waking up.

For whoever watch this thread, please stay tuned. I will reply to this thread once I have updated it with the new patch.

 

[Austere.J]

I have updated the new patch and the new story.

The previous patch should be discarded. Please use the new patch and leave comments if you have any issue.

 

[bavariancake]

Hi @Austere.J!
First of all, many thanks for working on these issues! Your initial div-by-0 fix made my hackintosh actually usable, and I'm sure many others too (I realize it's ironic it's Thanksgiving, but your work is very much appreciated.)

I've tried your most recent fix to set the max link rate, but I could not get it to work. With any configuration, I still get a div-by-0 kernel panic (see crash.txt).

I've tried 0x14/HBR2, 0x06/RBR, 0x1E/HBR3, 0x0A/HBR with CoreDisplayFixup and the latest WhateverGreen for each permutation via Clover boot selections (see attached config.plist). I've updated to the latest RehabMan Clover build v2.4k r4701.RM-4963 (2018-10-10). I've rebuilt my kextcache between each step with "sudo kextcache -i /".

At this point I wasn't sure if the patch was applied properly, so I checked "
/System/Library/Extensions/AppleIntelCFLGraphicsFramebuffer.kext/Contents/MacOS/AppleIntelCFLGraphicsFramebuffer" for the source hex <554889e5 48ff05a5 4607008b 96c02500 008a8e>, and it does contain one match. "bdmesg" doesn't show a failure of a kext patch being applied, so I created an arbitrary bad replacement designed to fail (see BADPATCH), but no logs appear in bdmesg. However, the initial div-by-0 fix does work, so kext patching is functional at least for that patch.

The output of AGDCDiagnose when using the initial div-by-0 patch is in display.txt (I have a 4k display).

Any suggestions or ideas?

 

[Austere.J]

Hi @Austere.J!
First of all, many thanks for working on these issues! Your initial div-by-0 fix made my hackintosh actually usable, and I'm sure many others too (I realize it's ironic it's Thanksgiving, but your work is very much appreciated.)

I've tried your most recent fix to set the max link rate, but I could not get it to work. With any configuration, I still get a div-by-0 kernel panic (see crash.txt).

I've tried 0x14/HBR2, 0x06/RBR, 0x1E/HBR3, 0x0A/HBR with CoreDisplayFixup and the latest WhateverGreen for each permutation via Clover boot selections (see attached config.plist). I've updated to the latest RehabMan Clover build v2.4k r4701.RM-4963 (2018-10-10). I've rebuilt my kextcache between each step with "sudo kextcache -i /".

At this point I wasn't sure if the patch was applied properly, so I checked "
/System/Library/Extensions/AppleIntelCFLGraphicsFramebuffer.kext/Contents/MacOS/AppleIntelCFLGraphicsFramebuffer" for the source hex <554889e5 48ff05a5 4607008b 96c02500 008a8e>, and it does contain one match. "bdmesg" doesn't show a failure of a kext patch being applied, so I created an arbitrary bad replacement designed to fail (see BADPATCH), but no logs appear in bdmesg. However, the initial div-by-0 fix does work, so kext patching is functional at least for that patch.

The output of AGDCDiagnose when using the initial div-by-0 patch is in display.txt (I have a 4k display).

Any suggestions or ideas?

Hi bavariancake,
Sorry for the late reply.
I have noticed this issue and it might be related to the framebuffer port patching.

Anyway, please use the following patches right now until I have time to fully investigate framebuffer ports.

ALT: Set the maximum link rate in DPCD buffer to 0x14 (HBR2) for laptops with 4K display (by FireWolf)
Find: 4883C304 4883FB08 72D0
Repl: 807DC100 7504C645 C114

 

[bavariancake]

Hi bavariancake,
Sorry for the late reply.
I have noticed this issue and it might be related to the framebuffer port patching.

Anyway, please use the following patches right now until I have time to fully investigate framebuffer ports.

Can confirm, 0x14 (HBR2) works with this patch on my 4k display (I haven't tried using the external HDMI port). Previously the UI would be choppy after the display went to sleep, but now it's still smooth/accelerated on wake-up. That's a nice improvement!

Interestingly, 0x0A (HBR) seems to work after boot, but causes the display to be split in half after resuming from sleep.

In general, is it preferable to use a lower link rate? Otherwise, the driver would just set the highest supported link rate and be done with it, I would assume.

 

[Austere.J]

Can confirm, 0x14 (HBR2) works with this patch on my 4k display (I haven't tried using the external HDMI port). Previously the UI would be choppy after the display went to sleep, but now it's still smooth/accelerated on wake-up. That's a nice improvement!

Interestingly, 0x0A (HBR) seems to work after boot, but causes the display to be split in half after resuming from sleep.

In general, is it preferable to use a lower link rate? Otherwise, the driver would just set the highest supported link rate and be done with it, I would assume.

Thanks for your reply.

I would highly recommend you to use 0x14 (HBR2) instead, as it is a common max link rate value reported by 4K displays.

The driver could adjust the final link rate based on some specific situations.

 

[bavariancake]

Just wanted to follow up.

After booting 100+ times with this new patch, I no longer get an intermittent hang on boot as I did with the fix lane number patch. Acceleration works every time, even after resuming from my half-baked sleep config. I have not tried using HDMI yet, however.

Anyway, this is great progress, I'm quite happy about it

 

[bavariancake]

So the ALT patch no longer works for me with 10.14.2, and AppleIntelCFLGraphicsFramebuffer has been updated. This patch worked for 10.14.0 and 10.14.1. I've tested the normal max link rate patch, but neither of them work for me (reboot after IGPU init as usual). A workaround for now is to overwrite AppleIntelCFLGraphicsFramebuffer.kext with the 10.14.1 version.

Could you create a new ALT patch for the new kext?

What tools do you use to disassemble kexts? I've found a few things online, but hoping there's a "standard" tool that most are using.

Thanks!