Contribute
Register

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

Status
Not open for further replies.
I've tried both
0x19160004
and
0x19160000
I was only able to change the resolution settings with 0x19160000 with the QHD display, but I'm going to try 0x19160004 with the patch that you posted.
@adrians I was not able to get any other screen resolution with that patch, stuck at 3200! With ......0004. I reverted to 0x19160000 and immediately was presented with a better screen resolution and no glitches. Although for initial install I needed to use 0004 otherwise the screen would go black on the QHD screen with only using the 0x1916000 and not come back on.
 
Last edited:
hey all, just wanted to report back and say my charging freezing issue is fixed even in UEFI Clover install. Thanks to all who helped, especially bozma88 and RehabMan. In short, I decided to start from scratch, and:

flash 1.3.2 BIOS
Reset settings to stock, picked settings matching the OP
Reset the EC per suggested by unplugging battery and holding down power button for 30 seconds
Set DVMT to 96MB
Followed instructions per OP, used original Files-v8.zip and haven't patched my own DSDT yet

Everything boots and is stable, and I've tried multiple unplug/replugs. Hope this helps!
 
If you're referring to my USB guide, you are misinformed.
The SSDT you create is configuration for USBInjectAll.kext.
If you remove USBInjectAll.kext, the custom SSDT (typically named SSDT-UIAC.aml) has no effect.

I understand that, however if I keep USBInjectAll.kext with this SSDT I see all ports (HS01-HS15, SS01-SS10, USR1-2), and when I remove the kext and keep the SSDT I see only the working ports (HS01-HS05, SS01-SS02).

Maybe I'm missing something?


With USBInjectAll+SSDT_UIAC_9360:
upload_2017-3-7_7-34-15.png

With SSDT only:
upload_2017-3-7_7-38-7.png
 
hey all, just wanted to report back and say my charging freezing issue is fixed even in UEFI Clover install. Thanks to all who helped, especially bozma88 and RehabMan. In short, I decided to start from scratch, and:

flash 1.3.2 BIOS
Reset settings to stock, picked settings matching the OP
Reset the EC per suggested by unplugging battery and holding down power button for 30 seconds
Set DVMT to 96MB
Followed instructions per OP, used original Files-v8.zip and haven't patched my own DSDT yet

Everything boots and is stable, and I've tried multiple unplug/replugs. Hope this helps!

Thats great news! We're narrowing down the cause.

Seeing as I had tried vanilla installing numerous times (including freezing from usb boot install) then the EC is the likely culprit. We now need to:
(i) find a more elegant way to reset EC without removing the board each time
(ii) isolate what in EC specifically is triggering the freeze issue (and why on specific laptops) and prevent it from setting

One other question. You said you set DVMT to 96MB. Does that mean 0x785=03?
EDIT - ignore this last question. I tied it myself and it works.
 
Last edited:
The system sets darkwake as needed (via NVRAM) depending on what it is doing...
No need to specify it as zero.
I have never used kernel flag darkwake on any of my hacks.

9350-9360 line is plagued with sleep data corruption, and we don't have narrowed down the cause yet.
It may be:
- HWP and SSD deep-idle settings
- Failed to go into hibernation the right way
- Wrong/corrupted memory mapping during darkwakes <<<<---- my bet is on this

So I have to force it off until the sleep data corruption issue is understood.
What I came up so far is that, with an incomplete / non fully OS-managed PM like we have now, some features are turned off by default and there's no risk of getting data corruption.

My next step is to understand how to tune these values in order to have darkwakes, hibernatemode and autopoweroff OFF by default in our specific platform.
This way, I will feel more confident enabling HWP and maybe removing darkwake=0 boot flag.

As somewhere else suggested, deleting DarkawkeServices and IOPlatformSystemSleesPolicy keys in this plist is not the right solution, because they'll take default values. Forcing values via pmset is dangerous and does not last: every now and then, they get reset and you'll get data corruption after long sleep (experienced in first person).

Are these values already understood? I can't find any thread talking about this.

72eba150-fd51-11e6-84a2-a04684b4f1b0.png

 
I understand that, however if I keep USBInjectAll.kext with this SSDT I see all ports (HS01-HS15, SS01-SS10, USR1-2), and when I remove the kext and keep the SSDT I see only the working ports (HS01-HS05, SS01-SS02).

Maybe I'm missing something?


With USBInjectAll+SSDT_UIAC_9360:
View attachment 240158

With SSDT only:
View attachment 240159

Without USBInjecdtAll.kext, you are getting ACPI configuration of USB ports.
And your SSDT is clearly wrong.
Read USB guide, "Problem Reporting".
 
9350-9360 line is plagued with sleep data corruption, and we don't have narrowed down the cause yet.
It may be:
- HWP and SSD deep-idle settings
- Failed to go into hibernation the right way
- Wrong/corrupted memory mapping during darkwakes <<<<---- my bet is on this

So I have to force it off until the sleep data corruption issue is understood.
What I came up so far is that, with an incomplete / non fully OS-managed PM like we have now, some features are turned off by default and there's no risk of getting data corruption.

My next step is to understand how to tune these values in order to have darkwakes, hibernatemode and autopoweroff OFF by default in our specific platform.
This way, I will feel more confident enabling HWP and maybe removing darkwake=0 boot flag.

As somewhere else suggested, deleting DarkawkeServices and IOPlatformSystemSleesPolicy keys in this plist is not the right solution, because they'll take default values. Forcing values via pmset is dangerous and does not last: every now and then, they get reset and you'll get data corruption after long sleep (experienced in first person).

Are these values already understood? I can't find any thread talking about this.

View attachment 240216

Hibernation (deep sleep, ACPI S4, "suspend to disk") is usually disabled on hacks as it is almost universally unreliable...
Making sleepimage a directory can be helpful in disabling it.
Details in the power management guide: https://www.tonymacx86.com/threads/guide-native-power-management-for-laptops.175801/

It would be interesting to find a way to change the defaults...
 
@bozma88 Just noticed another setting that might make sense to turn off in case it can cause the power plug freeze problems. Under POST behavior>Adapter Warnings, it's enabled by default and wondering if it would be best to turn that off possibly.
 
@bozma88 Just noticed another setting that might make sense to turn off in case it can cause the power plug freeze problems. Under POST behavior>Adapter Warnings, it's enabled by default and wondering if it would be best to turn that off possibly.
I think that freeze issue is caused by EC error due to duplicate SSDT injection that many users performed erroneously.
Anyway, that warning is only for chargers <45W, like the USB-C one that I'm using.
It warns you that the system and charging will be slightly slower (turbo boost gets partially disabled).

By the way, this laptop has an undocumented BIOS recovery mode (search the web). Maybe by entering that recovery the EC gets reset. Otherwise, one can try by keeping the power button pushed for 10+ seconds. Another way is to fully drain the battery until LVC (low-voltage-cutoff) kicks in.
 
my experience:
Model QHD, i7, 16/512gb
No freezes while in clover ((un)plugged the charger several times)
freezes when booting with charger plugged, ever time, even after sleep
freezes when booting without charger plugged in before the laptop got into sleep the first time.
No freezer when booting without the charger plugged in and doing a sleep directliy after loading OSX

I did build my own DSDT, SSDT-NVMe-Pcc.aml and HackNVMEFamily
I partly did the iMessage guide (only the config.plist editing) (partly because I do not have my wifi card yet)
I did not patch the keyboard as I have a German keyboard
I removed the eject.menu file
I do not have my wifi card yet (on its way from china) so I use a TP-Link USB Wifi adapter
My Bios version is 1.3.2 and my options are set as listed in the guide, even the optional ones.

I attached my Clover :) Hopefully I didn't do anything wrong
 

Attachments

  • CLOVER_17_03_07_1931.zip
    3 MB · Views: 77
Last edited:
Status
Not open for further replies.
Back
Top