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

[bozma88]

Given this serious and unsolved issue, my advice is to try the automated Syscl installer after wiping your system disk. You find it on GitHub.
It is over-engineered in my opinion, patching a lot of things without precise knowledge of the resulting effects, but it might give you the chance to find what's making the laptop freeze after power plug/unplug.
Try and report back, if you have some spare time. Any help in making this guide better is welcome.

 

[jkbuha]

@syscl 's installer does not (yet) automatically/fully work on the 9360... the installer doesn't successfully compile (the initial DSDT edits that @bozma88 proposes are missing, so iasl bombs out with a compile error...). Even if these bugs are fixed, and DSDT compilation is successful, the 9360 (mine at least) does not boot and gives a KP.

Even after I've manually inserted each of the patches into my optimised DSDT, the freezing issue still occurs.

I now have two theories:

- It could be related to ACPI Backlight. Reason is that occasionally I can plug/unplug whilst the screen is off and osx is running (not sleeping)
- It could be related to EC/NVRAM/BIOS. Reason is that I can reset the EC controller, clear nvram and reset bios settings and the freezing issue goes away. But it always comes back.... just like in the movie...

 

[fv316]

Sup guys, long time!

So I finally got around to updating the hack. Formatted to 4k LBA, and updated to 10.12.4. Something I noticed is that Clover complains that my partitions are not aligned, not sure if this is relevant to macOS though. Either way I attempted shifting the partitions with gdisk, parted, gparted, as well as wiping everything and remaking by hand, and what got me really confused is that each tool has a different idea of what 'aligned' means: parted, gparted, and macOS all write the 1st partition after 6 empty sectors, while gdisk leaves 125 sectors. In both cases Clover claimed there was an alignment error. Do you think this has an impact on macOS? In any case I'm not sure its possible to pre-make the partitions as macOS definitely erases the drive when restoring from TimeMachine, and possibly during clean installation as well. I did an AmorphousDisk test and my values were comparable to yours.



I do a couple things differently to you though: I run HWP to disable turboboost, this almost eliminates coil-whine, keeps temps below 80C and squeezes a bit more out the battery. It'll probably also explains the reduced ssd read speeds. I also use AppleALC as cloverALC/CodecCommander crashed the bluetooth controller too often (along with AppleIntelLpssI2CController.kext hanging on boot). Since I use bluetooth headphones and mouse, bluetooth is more important to me than jack-sense.

I'm also hot patching everything, got most of the essentials down. This post is getting a bit long so won't go into details, but attaching Clover for anyone interested. Keep in mind nvme patches are gone due to 4k format. I've also noticed that none of the AAPL,GfxYTile group patches are necessary anymore, I don't get glitches without them.

 

[RehabMan]

Something I noticed is that Clover complains that my partitions are not aligned, not sure if this is relevant to macOS though.
...
In both cases Clover claimed there was an alignment error. Do you think this has an impact on macOS?

Those logs are not coming from Clover.

You should partition using Disk Utility.

I'm also hot patching everything,

Cool to see someone new try ACPI hotpatch (based on my guide)....

FYI: that OSID->XSID patch looks wrong... (you only need to take care of _OSI->XOSI....)

 

[stehor]

http://www.homedepot.com/p/GE-Polarized-Grounding-Adapter-2-Pack-14404/203684998 @fv316 old homes have ground issues that will cause coil whine this should fix it.sorry for being off topic

 

[fv316]

Those logs are not coming from Clover.

You should partition using Disk Utility.

Any idea what would be generating them, and if it would affect macOS performance? I actually got those errors after switching to 4k LBA, and then booting macOS installer, formatting drive with Disk Utility, and doing clean install. The other partition tools described above was me attempting to fix it.

Cool to see someone new try ACPI hotpatch (based on my guide)....

FYI: that OSID->XSID patch looks wrong... (you only need to take care of _OSI->XOSI....)

Yes ofc, I'd still be looking for the power button without your guides

That OSID->XSID patch was implemented because I had the same issue as #29, not sure if that was causing any problems without the patch, but better to not have code edits in unintended places.

http://www.homedepot.com/p/GE-Polarized-Grounding-Adapter-2-Pack-14404/203684998 @fv316 old homes have ground issues that will cause coil whine this should fix it.sorry for being off topic

Even though I live in a moderately new apartment building, and it seems the coil whine is caused mostly by cpu load, I'll definitely give that a try! Heck if $5 can make a difference, I'll do it twice

Edit: turns out I've actually already got 3-prong outlets, bummer.

 

[RehabMan]

Any idea what would be generating them, and if it would affect macOS performance? I actually got those errors after switching to 4k LBA, and then booting macOS installer, formatting drive with Disk Utility, and doing clean install. The other partition tools described above was me attempting to fix it.

No idea. I don't have any NVMe devices that can switch to 4k.
You should look at the offsets of the partitions it is complaining about and then try to infer what the problem is...

That OSID->XSID patch was implemented because I had the same issue as #29, not sure if that was causing any problems without the patch, but better to not have code edits in unintended places.

Renaming a method that is actually defined will have no effect.
The _OSI->XOSI is a special case, as _OSI is not defined anywhere... it is provided by the ACPI host. So we use an _OSI->XOSI rename, simply so we can direct all _OSI calls to our own method instead of the _OSI provided by the ACPI host.

By using OSID->XSID, you're changing all calls to OSID to be calls to XSID. And the actual method definition to XSID.
Net result: no change at all...

The only case you might want to rename OSID is the case where you find an OSID reference that is preceded by an underscore (eg. _OSID) because that might match the _OSI->XOSI patch (unintended). So you would want to be certain to rename OSID prior to _OSI->XOSI... Especially if it is difficult to make the _OSI->XOSI patch more selective.

 

[fv316]

The only case you might want to rename OSID is the case where you find an OSID reference that is preceded by an underscore (eg. _OSID) because that might match the _OSI->XOSI patch (unintended). So you would want to be certain to rename OSID prior to _OSI->XOSI... Especially if it is difficult to make the _OSI->XOSI patch more selective.

Yes exactly, there was 5 cases of _OSID being caught in the _OSI->XOSI patch, which is what the OSID->XSID is for. Would you say making the _OSI patch more selective would be a much better idea? I agree that one concise patch is better than two, but there is also the element of simplicity. Doing '_OSI '->XOSI sadly won't work. I'm attaching an unpatched dsdt incase you'd like to check.

 

[RehabMan]

Would you say making the _OSI patch more selective would be a much better idea?

It would be difficult.
Suggest you add a comment to your OSID patch stating the purpose...

 

[fv316]

Suggest you add a comment to your OSID patch stating the purpose...

Right, my bad, will do