XPS9350-macOS
XPS9350-macOS copied to clipboard
Applications not working after modifying config.plist // hibernate crash
Hey there,
yesterday I had a bad hibernate crash after closing the lid on my XPS 9350.
What I did was modifying my config.plist so I could get iMessage and Facetime to work. So I was generating a Serial, added hex digits, adding uuid etc. and rebooted. Was browsing the web and everything seemed fine. I went away and closed the lid, the laptop did go to standby and I opened the laptop a few hours later with a blackscreen but lid keyboard. Nothing happened for about 30 seconds and it did reboot to Clover. After this I wanted to check the drive with diskutil but noticed some strange things on other apps: I couldn't run any of them. I fixed this by reinstalling macOS.
a screenshot of the apps not working
Hi @furrybanana
I am sorry to see you encounter this issue. But this is a known issue on XPS 13 and XPS 15 (Skylake).
Thus I rarely sleep my XPS 13 these days. Could you please provide what you do then see this information?? Because your detail information will help us solve this tough problem!
Thank you, syscl
hibernatemode is set to off so the system will not back memory up to persistent storage. The system must wake from the contents of memory; the system will lose context on power loss or restart.
@R1MnTnA But we don't know if hibernate = 0 help to prevent data corruption in this case.
Still need more evidence.
syscl
I close the lid like any laptop user would do because its a main feature if you have to transport your device. I have a 3-4% battery drain for a 10 hours of hibernate "overnight". Because I reinstalled I did not yet get this error now, when I encounter this again I hope to get more details. As of now I do a daily CCC-Backup so I don't lose any data.
@syscl No, I was just referring to that hibernate 0 for the fact that he rebooted and got thise pop-ups that he took screenshots of. Also remember the one that I had referenced before in a discussion that we need to investigate further if it helps was not hibernate but the 'pmset -a disksleep 0'
Also just for reference these are what I've done on my MacBook. - sudo pmset -a hibernatemode 0 sudo pmset -a disksleep 0 sudo pmset -a lidwake 0 sudo rm /var/vm/sleepimage
Thank you for the remind.
I will try later. Recently, I am refining rc.script in Clover.
syscl
Hello @R1MnTnA
I want to ask a question, why set lid wake to 0?
Thank you, syscl
I will try to add this
sudo rm /private/var/vm/sleepimage
sudo touch /private/var/vm/sleepimage
sudo chflags uchg /private/var/vm/sleepimage
syscl
@syscl for me it's only for my preference, not because it is necessary.
Please have a look at my post in issue #26. The problem is 100% hibernatemode. If you make some changes like:
- enabling/disabling hwp
- adding descriptors to smbios that trigger a new PM plist to be loaded
- OS update
Your PM settings get reset and hibernatemode reverts to 3 without you noticing.
I had also locked yhe sleepimage but after playing with HWP and frequencyvectors I found the sleepimage REMOVED and hibernwtemode to 3. After that, I got immediate corruption.
Maybe we can force hibernatemode to 0 before entering sleep, each and every time, with a script.
Since many minor changes can trigger hibernatemode 3, periodic manual checking is too dangerous.
@bozma88 Deploy script installs Sleepwatcher, which (if i'm not wrong) executes a script when sleep is triggered, and another one when laptop wakes up. maybe we can add in the "sleep script" sudo pmset -a hibernatemode 0
.
Maybe i will look into this this evening!
We have to be sure that the script sets hibernatemode before the system reads the value and decides what to do while sleeping. I'd also disable darkwake, to be sure, as I'm not sure whether the OS honours the darkwake=0 boot flag.
@bozma88 we Can check that easily. Lets put hibernatemode 25, edit sleepwatcher script and see if laptop goes to standby or if It hibernates.
@bozma88 @syscl I got it working. As reported by @bozma88, sometimes hibernatemode value is changed by the OS to hibernatemode 3, and this can cause DATA CORRUPTION (as Hibernation causes that, and we have proof).
We can easily fix this by editing the current /etc/sysclusbfix.sleep
adding pmset -a hibernatemode 0
(without sudo) as first line after comments. I tested it and it's working: hibernatemode value is changed before that the OS reads the value, so even if the value has been changed by the OS, it will go back to hibernatemode 0
automatically.
Of course it's a temporary solution. Don't forget, after editing the file, to set proper permission with:
sudo touch /etc/sysclusbfix.sleep
sudo chmod +x /etc/sysclusbfix.sleep
Maybe it would be better to create another sleep script file, in this case i've decided to include it in the usbfix file as no more configuration was needed. @syscl I think you should include this in Deploy meanwhile we try to fix hibernation, just to make sure nobody gets data corruption with sleep.
Proof (last pmset -g was executed after sleep):
My edited file: