DPCD Max Link Rate Fix fails in Whatevergreen v1.4.4

[CoronaHack]

Hi developers!

Recently I updated all the Lilu plugins, including WEG, to the latest version; the DPCD Max Link Rate Fix seems to not function anymore and produces a division by zero panic (Logs attached below).

PS: Using v1.4.4 with dpcd-max-link-rate removed (probes the maximum link rate value automatically) also produces the same panic.

Previously, using Whatevergreen v1.4.3 with enable-dpcd-max-link-rate-fix and dpcd-max-link-rate set to 0x14, I was able to boot into the system without facing a panic although both of the screens did not light up (may be a separate issue or related). And I could use a remote control software to enter userspace.

Additional Info:

• CPU: Intel Core i9 10980HK
• GPU: Intel UHD 630
• macOS: 10.15.7 19H2
• DVMT already set to 64MB in BIOS
• Main Display
  • Vendor:AUO
  • Model NO: AUOBC8C
  • Refresh Rate: 300Hz

PS: The laptop facing this issue has two screens; when I disable the first screen by injecting a fb that does not contain the main display's port 0x3E9B0007, the second display (4K 60Hz Touch Display) works as expected and the DPCD fix is not required.

However, whenever I try to light up the main display by either patching the port info or using a fb that contains the first port, I either get a panic when using Whatevergreen v1.4.4 with enable-dpcd-max-link-rate-fix or a black screen using Whatevergreen v1.4.3 with enable-dpcd-max-link-rate-fix.

Panic.txt Lilu-WEG-Debug.log

CC @0xFireWolf

[0xFireWolf]

(Boot Attempt #1)
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: ReadAUX() has been routed successfully
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x1e has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x1e has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x1e has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x1e has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x1e has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x1e has been set in the DPCD buffer.

(Boot Attempt #2)
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: ReadAUX() has been routed successfully
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.

(Boot Attempt #3)
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: Found ICL+ platforms. Will setup the fix for the ICL+ graphics driver.
kernel: (Lilu) WhateverGreen      igfx: @ MLR: [ICL+] Failed to route functions.

(Boot Attempt #4)
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: ReadAUX() has been routed successfully
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.
kernel: (Lilu) WhateverGreen      igfx: @ (DBG) MLR: wrapReadAUX: Maximum link rate 0x0a has been set in the DPCD buffer.

Your kernel log reflects at least 4 boot attempts, where the 3rd attempt boots with WEG v1.4.4, and others boot with previous versions. As you can see from the above lines, the maximum link rate (0x1E or 0x0A) is patched properly.

The maximum link rate fix fails in your 3rd attempt, because it cannot resolve the symbol. For some reasons, your processor is misclassified, and it should be Comet Lake instead of Ice Lake. Did you apply any FakeCPUID patch? If so, please remove them.

[CoronaHack]

TBH, I did not use any FakeCPUID patch. After looking into WEG and Lilu's source code, I noticed that the if statement for identifying Icelake in WEG is incorrect.

https://github.com/acidanthera/WhateverGreen/blob/80f4727765d79e7ce0c0d2dac4e2517981e50138/WhateverGreen/kern_igfx_clock.cpp#L158-L166

if (BaseDeviceInfo::get().cpuGeneration >= CPUInfo::CpuGeneration::IceLake) {

This line of code identifies any CPU model greater or equals to Icelake as Icelake, however, in Lilu's source code:

https://github.com/acidanthera/Lilu/blob/c776d451381a7253de4ab7793010820413d6b175/Lilu/Headers/kern_cpu.hpp#L86-L92

        CPU_MODEL_CANNONLAKE     =  0x66,
        CPU_MODEL_ICELAKE_Y      =  0x7D,
        CPU_MODEL_ICELAKE_U      =  0x7E,
        CPU_MODEL_ICELAKE_SP     =  0x9F, /* Some variation of Ice Lake */
        CPU_MODEL_COMETLAKE_S    =  0xA5, /* desktop CometLake */
        CPU_MODEL_COMETLAKE_Y    =  0xA5, /* aka 10th generation Amber Lake Y */
        CPU_MODEL_COMETLAKE_U    =  0xA6,

Possible CPU models greater than Icelake could also contain Cometlake ones.

[0xFireWolf]

Ah, I see, that’s why ICL’s readAUX() is resolved instead. Thanks for catching that, as I thought Comet Lake has a lower value than Ice Lake. I will submit a PR to resolve this issue, and I appreciate your bug report. Thanks.