Contribute
Register

Mavericks (10.9) on Lenovo Y580

Status
Not open for further replies.
P-States working now:

View attachment 100545

View attachment 100544


RehabMan said:
You probably need DSDT patches. Likely candidates from here: https://github.com/RehabMan/Laptop-DSDT-Patch
"Fix _WAK Arg0 v2"
"HPET Fix"
"SMBUS Fix"
"IRQ Fix"
"RTC Fix"
"OS Check Fix"
"Fix Mutex with non-zero SyncLevel"
Click to expand...

I added the patches but still no wake up from sleep.

Next I patched DSDT with debug.txt from your OS-X-ACPI-Debug, also patched with instrument_WAK_PTS.txt and installed the ACPIDebug.kext ('make' and 'make install').

Attached you'll find my ioreg and my system.log.
 

Attachments

  • system.log.zip
    17.8 KB · Views: 52
  • ioreg.zip
    1 MB · Views: 59
vord said:
Another try...
Click to expand...

Try also, "Fix PNOT/PPNT" patch.

You have the patches required to instrument _PTS/_WAK. So test sleep/wake. Then check system.log for the results (filter for acpidebug).

Also, do your sleep issues persist without the patches to disable nvidia (I think that's what I'm seeing with the call to DOFF from _INI)?

It could be that you're missing important SSDTs. You should review all OEM SSDTs and include important ones.

Also, I don't know what Ev0Reboot does, and I've never had to use it. Do you know what it does/what it is for? Suggest you don't use kexts if you don't know what they do.
 
RehabMan said:
Try also, "Fix PNOT/PPNT" patch.
Click to expand...

I did it.

RehabMan said:
You have the patches required to instrument _PTS/_WAK. So test sleep/wake. Then check system.log for the results (filter for acpidebug).
Click to expand...

I did exactly how you wrote in readme (first, second, thrid ...) but I get this message in system.log only:

Code: 
 ACPIDebug: Version 0.1.0 starting

Unfortunately nothing like "_WAK enter". Why are these methods never executed?

I also made the test with ioio. This is the output in terminal:

Code: 
 ./ioio -s org_rehabman_ACPIDebug dbg0 5
argv[0] = { ./ioio }
argv[1] = { -s }
argv[2] = { org_rehabman_ACPIDebug }
argv[3] = { dbg0 }
argv[4] = { 5 }
ioio: setting property 'org_rehabman_ACPIDebug:dbg0' as number to 5 (0x5)

And output in system.log:

Code: 
ACPIDebug evaluateObject("DBG0") failed (e00002bc)

RehabMan said:
Also, do your sleep issues persist without the patches to disable nvidia (I think that's what I'm seeing with the call to DOFF from _INI)?
Click to expand...

Sorry, don't know what you mean. Which patches to disable nvidia?

RehabMan said:
It could be that you're missing important SSDTs. You should review all OEM SSDTs and include important ones.
Click to expand...

How could I know if the SSDT is important? There're no _WAK or _PTS in OEM SSDTs.

RehabMan said:
Also, I don't know what Ev0Reboot does, and I've never had to use it. Do you know what it does/what it is for? Suggest you don't use kexts if you don't know what they do.
Click to expand...

I don't know how it could get there. Maybe by copy/paste from Jessers' kext-folder. I deleted the kext and everything is working as before.
 
vord said:
I did it.



I did exactly how you wrote in readme (first, second, thrid ...) but I get this message in system.log only:

Code: 
 ACPIDebug: Version 0.1.0 starting

Unfortunately nothing like "_WAK enter". Why are these methods never executed?
Click to expand...

You won't get any output unless you sleep your laptop...

I also made the test with ioio. This is the output in terminal:

Code: 
 ./ioio -s org_rehabman_ACPIDebug dbg0 5
argv[0] = { ./ioio }
argv[1] = { -s }
argv[2] = { org_rehabman_ACPIDebug }
argv[3] = { dbg0 }
argv[4] = { 5 }
ioio: setting property 'org_rehabman_ACPIDebug:dbg0' as number to 5 (0x5)

And output in system.log:

Code: 
ACPIDebug evaluateObject("DBG0") failed (e00002bc)
Click to expand...

Unless you defined a DBG0 object in RMDT, this won't work and is not useful in your scenario anyway.


Sorry, don't know what you mean. Which patches to disable nvidia?
Click to expand...

I see a call to DOFF from _INI. Is that code native? Post native DSDT/SSDT from Linux...

How could I know if the SSDT is important? There're no _WAK or _PTS in OEM SSDTs.
Click to expand...

Post the files and I'll tell you which ones you may need...

I don't know how it could get there. Maybe by copy/paste from Jessers' kext-folder. I deleted the kext and everything is working as before.
Click to expand...

Make sure you rebuild cache after deleting a kext, otherwise it is still loaded from cache.
 
RehabMan said:
You won't get any output unless you sleep your laptop...
Click to expand...

That's what I've done: clean system.log - sleep laptop - reactivate - examine new system.log

RehabMan said:
I see a call to DOFF from _INI. Is that code native? Post native DSDT/SSDT from Linux...
Click to expand...

Find attached my fresh extracted DSDT and SSDT.

RehabMan said:
Make sure you rebuild cache after deleting a kext, otherwise it is still loaded from cache.
Click to expand...

I use Kext Wizard and I always repair permissions / rebuild cache - install kext - and again repair permissions / rebuild cache. Should I try UseKernelCache=No?
 

Attachments

  • dsdt-ssdt.zip
    19.6 KB · Views: 71
vord said:
That's what I've done: clean system.log - sleep laptop - reactivate - examine new system.log
Click to expand...

Are you sure it went to sleep? Sleep does not begin until ~20 sec after sleep request. If you're crashing on wake, you may not see anything in the log as ACPIDebug has no chance to write the log...

Find attached my fresh extracted DSDT and SSDT.
Click to expand...

Including SSDT3 is probably unnecessary, but it wouldn't hurt to try it.
SSDT1 & SSDT2 are CPU related and should not be included.

DOFF call is native.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top