Contribute
Register

Laptop won't sleep/shutdown after a few hours of uptime

Status
Not open for further replies.
Seems pretty clean. Try without Trim for a while... Some SSDs have issues with Trim on OS X. My desktop Mushkin Chronos Deluxe 256GB)... I use without Trim as it slows boot down considerably. Check that you have current firmware for the SSD too.

Trim off, fingers crossed! :)
Edit: checked firmware with smartctl, it is already at the latest version.
 
Trim off, fingers crossed! :)
Edit: checked firmware with smartctl, it is already at the latest version.

The saga continues.. FixRegions and trim off didn't help.
I've now traced all level event methods (_Lxx) as well as all EC methods (_Qxx). None of the _Lxx is ever called, and I've fixed a couple _Qxx that didn't execute fully. Didn't fix in the lockup on sleep issue.

I'm thinking the next step is dumping the EC/GNVS region to see if any field is changed after the 2 hours and change where the lockups occur.

RM: before I start diff'ing entire regions, can you confirm there is no smart way to attach a listener to an OperationRegion that would trigger a call to a dump method when a field is changed? I've looked into the acpi specs for something like that but couldn't find anything. If I could overload Mutex that would probably get me close enough, but I don't think there's any way to do this either.
 
...
RM: before I start diff'ing entire regions, can you confirm there is no smart way to attach a listener to an OperationRegion that would trigger a call to a dump method when a field is changed?

No. These are just MMIO/SystemMemory/IO regions. They can be changed by anything, not just ACPI code.

I've looked into the acpi specs for something like that but couldn't find anything. If I could overload Mutex that would probably get me close enough, but I don't think there's any way to do this either.

You can use ACPIDebug to instrument almost any chunk of code you want to... But it only covers actions that take place in ACPI. Doesn't help you if it is misbehaved drivers/kernel/etc.
 
No. These are just MMIO/SystemMemory/IO regions. They can be changed by anything, not just ACPI code.
Right, and that's my next hypothesis. Somehow something occurs somewhere outside of the ACPI code (since I've traced all the ACPI code) that creates the conditions for the lockup. I'm hoping it's something I can dump from the DSDT, such as some value in the OperationRegion that changes around the timeframe when the issue occurs. I was just trying to find a way to only look at what changes, rather than dumping the entire region and diff'ing them, as there are hundreds of field. I don't think it's possible though.

You can use ACPIDebug to instrument almost any chunk of code you want to... But it only covers actions that take place in ACPI. Doesn't help you if it is misbehaved drivers/kernel/etc.
Yeah the reasons why I believe it is an ACPI issue are as follows (just writing it down so you can correct me if you don't think my reasoning holds up):
  • The issue affects sleep, shutdown and restart.
  • There is a clear threshold where it works perfectly fine before/locks up after. From my notes, the threshold is between 2h and 2h26 of uptime without sleep. It is 100% reproducible, and lockups never occur before the threshold.
  • If I shutdown after the threshold is crossed, the machine locks up after 'CPU halted' and the screen is shut down. If I sleep after the threshold is crossed, the machine locks up too.
  • If I restart after the threshold is crossed, the OS shuts down normally, then hangs for ~10s with the screen off, then shuts down. Based on my SSD smart value of 'Unexpected power loss count' (130, SSD is 2 months old!), these are not successful shutdowns when I ask for a restart, but rather the machine hangs then shuts itself down.
  • None of the issues above ever occur if I sleep/restart/shutdown before ~2h of uninterrupted uptime. I can also use the machine for days on end without issues as long as I sleep every 2 hours. But as soon as I let it up for more than ~2h, it locks up on the next sleep/shutdown as described above.
  • It also occurs on mavericks.
  • There is circumstantial evidence that it also occurs on linux (one open ticket on ubuntu launchpad).
 
...
[*]There is circumstantial evidence that it also occurs on linux (one open ticket on ubuntu launchpad).

That ^^^ is the only sign that is indicative of a BIOS or ACPI problem. If the same thing was happening on Windows, that would be further evidence.

Have you tried simulating different versions of Windows in DSDT (eg. correlate "Darwin" with "Windows 2006", "Windows 2009", "Windows 2012")?
 
That ^^^ is the only sign that is indicative of a BIOS or ACPI problem. If the same thing was happening on Windows, that would be further evidence.

Have you tried simulating different versions of Windows in DSDT (eg. correlate "Darwin" with "Windows 2006", "Windows 2009", "Windows 2012")?

Yes, I modified your system_OSYS dsdt patch to match Darwin with Windows 2012 since I could see in several places in the DSDT that code was executed conditionally to OSYS >= Windows 2012 value. No fix though. All other OSYS values are treated the same (no code is conditional to those OSYS values), so I haven't tried them.
 
Same issue here, if i try to sleep after few hour of usage the screen goes black but the laptop is still pingable and goes not to sleep.
Sleep works fine after little usage.
Tell me if i can hel you with some test
 
Hey vbo,

I'm just posting here to let you know that your fix worked for me, but I have an entirely different laptop (the Acer Aspire E1-572-6870 to be exact). If, at some point, you find a solution that works without simply disabling the kext, it would be greatly appreciated! I'm not experiencing any issues with it disabled but a cleaner fix is always nice :p
 
After a few days of testing, I discovered some major issues with this fix. It breaks HTML5 videos in Safari: you can hear the audio but you don't see anything. Other browsers still work fine though, which I did for a while. Then I noticed the patch also breaks QuickTime's ability to play videos. VLC still works, but it takes a long time to load the video. Bootup also seems faster without the fix but I didn't time it. Looks like we need a real patch after all :p. I have a BIOS update available I'll try later to see if it fixes it.
 
Status
Not open for further replies.
Back
Top