Contribute
Register

[Guide] Dell XPS 13 9360 on MacOS Sierra 10.12.x - LTS (Long-Term Support) Guide

Status
Not open for further replies.
Anyone else getting big kernel_task cpu usage after wake? According to my research, this is Apple's way of trying to keep the machine cooler (and ultimately quieter) by 'fake throttling' the chip so other processes can't request more resources. However, the result is that the machine stays very warm, the fan barely engages and performance is reduced. I see usage of around 67% or so in kernel_task. I've already repasted and put in thermal pads on the heat pipes in an attempt to reduce overall temps, and it only had a mild effect.
I'm wondering if there's some post-sleep script that needs to run to reset the SMC or something to tell the fans to kick into higher gear. In Windows, using the Hardware Monitor, I'll see spikes of 100 degrees C on the package and all four cores which results in thermal throttling several times before the fan kicks in. But when they do, it'll run it much faster than I've ever noticed in MacOS. Any suggestions other than undervolting?
 
Johann7 said:
Anyone else getting big kernel_task cpu usage after wake? According to my research, this is Apple's way of trying to keep the machine cooler (and ultimately quieter) by 'fake throttling' the chip so other processes can't request more resources. However, the result is that the machine stays very warm, the fan barely engages and performance is reduced. I see usage of around 67% or so in kernel_task. I've already repasted and put in thermal pads on the heat pipes in an attempt to reduce overall temps, and it only had a mild effect.
Click to expand...
A recent post: https://www.tonymacx86.com/threads/...s-long-term-support-guide.213141/post-1893290

It must be a Mojave thing, because I don't get it on 10.13.6.

I'm wondering if there's some post-sleep script that needs to run to reset the SMC or something to tell the fans to kick into higher gear. In Windows, using the Hardware Monitor, I'll see spikes of 100 degrees C on the package and all four cores which results in thermal throttling several times before the fan kicks in. But when they do, it'll run it much faster than I've ever noticed in MacOS. Any suggestions other than undervolting?
Click to expand...

I've not seen much in this thread about how the OS controls what's going on with the CPU fan. Looking at the DSDT, I see a ThermalZone object that could potentially be messed around with (there is one trip-point defined there of 107 C which must be the system shutdown limit). And then there's _SB.PCI0.LPCB.EC, the Embedded Controller device. We should be able to set the passive and the active trip-point temperatures, somehow. Take a look at section 11.1.4 of the ACPI spec, if you're interested. The part I'm unsure about is how we would need to address the FAN device. You can see it in dmidecode output, but can that be translated into an ACPI _HID or something? Over my head.
 
kylec said:
A recent post: https://www.tonymacx86.com/threads/...s-long-term-support-guide.213141/post-1893290

It must be a Mojave thing, because I don't get it on 10.13.6.



I've not seen much in this thread about how the OS controls what's going on with the CPU fan. Looking at the DSDT, I see a ThermalZone object that could potentially be messed around with (there is one trip-point defined there of 107 C which must be the system shutdown limit). And then there's _SB.PCI0.LPCB.EC, the Embedded Controller device. We should be able to set the passive and the active trip-point temperatures, somehow. Take a look at section 11.1.4 of the ACPI spec, if you're interested. The part I'm unsure about is how we would need to address the FAN device. You can see it in dmidecode output, but can that be translated into an ACPI _HID or something? Over my head.
Click to expand...

The fan on Dell devices can be controller using SMM. I wrote a plugin for FakeSMC a while ago which can interact with the system fan:
https://github.com/the-darkvoid/OS-X-FakeSMC-kozlek/tree/smm-sensors/SMMSensors

I plan to do the same for VirtualSMC, but haven't had the time yet. Though the sensor plugin would only read, not change settings, the code interface can set the fan as well.
 
Interesting. There is an SSDT for the Dynamic Platform Thermal Framework that I hadn't looked at before. Also, I just found this GitHub issue: https://github.com/intel/dptf/issues/22#issuecomment-402861777

It suggests that the DPTF has a policy that uses passive/active trip point, but available in Windows only. I did an ACPI dump from Windows, and the DptfTabl SSDT looks much like what I have on OS X.

But, I discovered that my _STA methods in there have been renamed to XSTA. This must be the reason for the different fan behavior! What could be changing it?
 
kylec said:
But, I discovered that my _STA methods in there have been renamed to XSTA. This must be the reason for the different fan behavior! What could be changing it?
Click to expand...

I would assume that would be a Clover hotpatch renaming it. You could try and retarget the hotpatch to use a TgtBridge parameter if you want to prevent renaming the functions. Either that or wrap the functions into a separate hotpatch.

Just now I validated my config.plist, but the only _STA to XSTA rename I use already has a TgtBridge of "GPI0" specified:

XML: 
<dict>
    <key>Comment</key>
    <string>change _STA to XSTA in device GPI0 (TouchPad I2C)</string>
    <key>Disabled</key>
    <false/>
    <key>Find</key>
    <data>
        X1NUQQ==
    </data>
    <key>Replace</key>
    <data>
        WFNUQQ==
    </data>
    <key>TgtBridge</key>
    <data>
        R1BJMA==
    </data>
</dict>

That would mean that DptfTabl on OS X should be untouched. There might be an effect due to _OSI (OS selection) between Windows and macOS.

Edit:

Hmm.. I see the same XSTA instead of _STA as you are. The ACPI origin dump has _STA, but the version loaded through maciasl in macOS has XSTA. So either TgtBridge is not working as expected or Clover is doing something by itself based on another configuration setting?
 
It is puzzling.
 
kylec said:
It is puzzling.
Click to expand...

Turns out its an issue with TgtBridge not working as expected.

I'm testing with updated I2C patches as follows:

XML: 
<dict>
    <key>Comment</key>
    <string>change _STA to XSTA in device GPI0 (TouchPad I2C)</string>
    <key>Disabled</key>
    <false/>
    <key>Find</key>
    <data>
        FB1fU1RBAKAJk1M=
    </data>
    <key>Replace</key>
    <data>
        FB1YU1RBAKAJk1M=
    </data>
</dict>
<dict>
    <key>Comment</key>
    <string>change _CRS to XCRS in device TPD1 (TouchPad I2C)</string>
    <key>Disabled</key>
    <false/>
    <key>Find</key>
    <data>
        B6QKD6QAFDNf
    </data>
    <key>Replace</key>
    <data>
        B6QKD6QAFDNY
    </data>
</dict>

This also calls into question how 'destructive' _DSM to XDSM is as a patch. It might be interesting to see what happens if we leave things more 'vanilla'.
 
Dell XPS 9360 i5-8250U FHD Boot error on 10.14
 

Attachments

  • 20190131_010209.jpg
    20190131_010209.jpg
    1.3 MB · Views: 69
godwayne305 said:
Dell XPS 9360 i5-8250U FHD Boot error on 10.14
Click to expand...

Looks like macOS is trying to load firmware into your internal GPU. WhateverGreen.kext is supposed to prevent this.
Double check if your kexts are installed correctly in Clover.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top