Contribute
Register

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

Status
Not open for further replies.
That's due to Chrome 57, not macOS. You'll get the same result if you use Canary or Chrome on Windows.
 
Last edited:
Upgraded to 1.3.4.

- There have been a few BIOS-related changes. A quick file diff shows a few new power options and some EC-related changes
- DSDT has not changed, but some other ACPI files have. FACP for instance, and a few SSDT-files.
- No visible changes in performance though. Power freeze still persists on osx.
 
Right, for all those of us who have the plug-freeze issues, I (may) have stumbled on something.

I just realised that on the current boot, the laptop does not freeze if I plug/unplug the charger. Repeated it consistently, slept/woke the laptop and no freezing issues occurred. I dumped the IOReg (nofreeze), shutdown and rebooted, dumped the IOReg again (freeze), plugged in the power and it froze.

Now I'm treading outside the bounds of my capabilities, can anyone with more knowledge than me analyse the two dumps and see if anything obvious stands out?
 

Attachments

  • nofreeze.zip
    716.3 KB · Views: 94
  • freeze.zip
    663 KB · Views: 93
Just a small note, still to confirm as I pass more time with my last configuration.

BIOSES > 1.2.3 have caused me a lot of small troubles.

The most prominent is bluetooth not initialising after resume from sleep when on battery power, after keeping the device sleeping for more than 5 minutes.
I initially thought it was a 10.12.4 issue, but finally it seems that I tracked down the issue to the fact that after sleep the bluetooth device gets DUPLICATED in system profiler (before sleep=1 device, after sleep 2 identical devices under USB 3 root), and BRC firmware uploader cannot handle this singularity. A cold boot fixes this until next >5m sleep cycle on battery power.

Tried everything, re-dumping DSDT, resetting BIOS, unplugging battery, disabling many DSDT patches, correcting USB port patches. Nothing worked.

Then I read on Windows forums that 1.3.2, 1.3.4, and possibly 1.3.5 BIOSes have issues related to Windows "connected standby" mode.
My guess is that the system incorrectly powers on Bluetooth during sleep and then MacOS sees it as a duplicate after a wake cycle.

Then I downgraded BIOS to 1.2.3, reset BIOS settings, re-dumped DSDT and the issue seems to have disappeared.

I take time to verify and test this, then the guide will be updated.

If you are running a dual boot with Windows, unfortunately you should update BIOS to 1.3.5 to patch the critical Intel AMT vulnerability that is endangering half the world right now. It is also possible there will be a forced BIOS update via Windows update, so stay alert! Users running only MacOS should have no worries if using an old BIOS.

More proofs and confirmations in a few days, along with guide updates for 10.12.4.

If you want to help me, we could compare 1.3.5 and 1.2.3 BIOSes and DSDTs to find the culprit. We could also search for differences that cause power-freeze in some systems. Mine si not affected. It is mostly due to different PM hardware/revisions, but maybe we can find some hints in DSDT. Let me know if you want to help me.

Cheers
 
Happy to help out here. Interestingly enough the bluetooth issue never happened for me. I have the BrcmFirmwareData.kext and BrcmPatchRAM2.kext in CLOVER.

With regards to freezing I may have another solution. I've attached the ioreg dumps of when my 9360 doesn't freeze in the previous post.
 
Tried everything, re-dumping DSDT, resetting BIOS, unplugging battery, disabling many DSDT patches, correcting USB port patches. Nothing worked.

Yes, I've also had a lot of trouble with bluetooth in the past. Mine also crashes after 5min of battery sleep, but I couldn't find any instance of the device being duplicated, could you please post a screen so I know I'm looking in the right place?

The only solution I could come up with was to manually switch off bluetooth before sleep and then switch it back on upon wakeup. Once this solved the driver crashing problem, I automated the procedure with sleepwatcher and blueutil, so it doesn't affect the workflow at all. The setup now can survive a sleep of any length, whether on battery or plugged in. Bios 1.3.2.

There was ofc one instance where the driver did crash even with the current setup, when I was listening to iTunes through the bluetooth headphones but otherwise not using the laptop, so the screen was already off. As soon as I killed the bluetooth link via the switch on the headphones the laptop was asleep instantaneously, and upon waking from sleep the bluetooth driver had again crashed. I'm not sure if in this case it didn't fire off the sleepwatcher script, but excluding this edge case, its pretty solid.
 
Yes, I've also had a lot of trouble with bluetooth in the past. Mine also crashes after 5min of battery sleep, but I couldn't find any instance of the device being duplicated, could you please post a screen so I know I'm looking in the right place?

The only solution I could come up with was to manually switch off bluetooth before sleep and then switch it back on upon wakeup. Once this solved the driver crashing problem, I automated the procedure with sleepwatcher and blueutil, so it doesn't affect the workflow at all. The setup now can survive a sleep of any length, whether on battery or plugged in. Bios 1.3.2.

There was ofc one instance where the driver did crash even with the current setup, when I was listening to iTunes through the bluetooth headphones but otherwise not using the laptop, so the screen was already off. As soon as I killed the bluetooth link via the switch on the headphones the laptop was asleep instantaneously, and upon waking from sleep the bluetooth driver had again crashed. I'm not sure if in this case it didn't fire off the sleepwatcher script, but excluding this edge case, its pretty solid.
This is very helpful.
I will post info asap.
Then, when we have a good amount of info from different sources, we will ask help to the great Rehabman.
 
The most prominent is bluetooth not initialising after resume from sleep when on battery power, after keeping the device sleeping for more than 5 minutes.
I initially thought it was a 10.12.4 issue, but finally it seems that I tracked down the issue to the fact that after sleep the bluetooth device gets DUPLICATED in system profiler (before sleep=1 device, after sleep 2 identical devices under USB 3 root), and BRC firmware uploader cannot handle this singularity. A cold boot fixes this until next >5m sleep cycle on battery power.

Are you using Google Chrome or Android File Transfer?
If so, read related topic in the FAQ.
 
First of all - thanks for this guide to bozma88 and RehabMan you guys are awesome! I updated to the new patch 10.12.5 and no new issues now.
Freeze and bluetooth are still present.
 
Last edited:
Just updated 10.12.5. Everything seems fine. I'm tempted to say its a bit snappier but that could just be placebo effect lol
 
Status
Not open for further replies.
Back
Top