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

[egore]

Did some further research after I thought a bit about this. 250 is the maximum range of the under/over-volt registers, as they're only 8-bit on the Dell. So unless there's a super-resistant die lattice out there, it's likely that you've just not enabled the registers for overclocking (which in turn should enable undervolting).

Also - and more pertinently, there should be higher GB scores with each step you undervolt, as you are further away from the TDP ceiling. What are the GB differences, say at 0, -125, -250?

I'm sure you are correct here. Currently at -600 -600 -75 and running strong. lol -75 for cache is active though, as a setting any lower causes a freeze. CPU and GPU appear not to be active, as -600 is likely unrealistic.

How do I go about enabling undervolting in the BIOS?

 

[jkbuha]

Setting: CFG Lock, Variable: 0x4DE
Option: Disabled, Value: 0x0
Option: Enabled, Value: 0x1 (default)

Setting: OverClocking Feature, Variable: 0x64D
Option: Disabled, Value: 0x0 (default)
Option: Enabled, Value: 0x1

Setting: XTU Interface, Variable: 0x64E
Option: Disabled, Value: 0x0 (default)
Option: Enabled, Value: 0x1

0x4DE -> 00
0x64D -> 01
0x64E -> 01

That should get you going. Then experiment with undervolting and report back.

 

[egore]

Setting: CFG Lock, Variable: 0x4DE
Option: Disabled, Value: 0x0
Option: Enabled, Value: 0x1 (default)

Setting: OverClocking Feature, Variable: 0x64D
Option: Disabled, Value: 0x0 (default)
Option: Enabled, Value: 0x1

Setting: XTU Interface, Variable: 0x64E
Option: Disabled, Value: 0x0 (default)
Option: Enabled, Value: 0x1

0x4DE -> 00
0x64D -> 01
0x64E -> 01

That should get you going. Then experiment with undervolting and report back.

0x4DE -> 00 (was already set)
0x64D -> 01 (changed)
0x64E -> 01 (changed)

VoltageShift values:
-(any number) -(any number) -75 (max before freeze)
No improvement/change in GeekBench scores.

In other words, it appears the BIOS modifications did not unlock undervolt capabilities. No change in results from prior to changing the BIOS.

 

[the-darkvoid]

0x4DE -> 00 (was already set)
0x64D -> 01 (changed)
0x64E -> 01 (changed)

VoltageShift values:
-(any number) -(any number) -75 (max before freeze)
No improvement/change in GeekBench scores.

In other words, it appears the BIOS modifications did not unlock undervolt capabilities. No change in results from prior to changing the BIOS.

User @arehep mentions in this post that it should work without BIOS unlock. I only got undervolting working reliably through EFI var settings though.

 

[Johann7]

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?

 

[kylec]

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.

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?

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.

 

[the-darkvoid]

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.

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.

 

[kylec]

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?

 

[the-darkvoid]

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?

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:

<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?

 

[kylec]

It is puzzling.