Hi guys. I've got Snow running pretty well, but I have a rather annoying issue:
I can't get my laptop to sleep. I've tried every dsdt option i could fit in, and it simply won't go to sleep. It will get dark, but the power button will stay on, and I can't wake it back up. Applied the LID0 msi lid fix, and that allowed me to close the lid, which turned off the LCD without going to sleep. I then Applied the _wak1 fix, which did nothing. Finally, i did the Device PNLF fix, which if I now close my lid, it would do the same thing as before, and I can't wake it up. Tried sleepenabler.kext, but it caused a kernel panic in 64bit mode, had to use 32 bit, and that still didn't work. DSDT compiled without errors, but it did give 23 warnings. Will upload dsdt if needed.
also, I have voodoops2 in /Extra, but i can't boot without -f -v flags because voodooHDA and applePS2 cause a panic or disable my touchpad and keyboard. How to fix this?
System Specs:
MSI GX720
Intel Core 2 Quad Q9100 ICH9M
ALC888s Sound
Nvidia 9600M GT
Thanks in advance!
-applehacker
Full Version: Post Install Sl Help Needed.
What Mac Model did you write into smbios.plist?
I have the same southbridge chipset (ICH9M) and my laptop was behaving exactly like yours. I traced the problem to the USB ports. I had to inject ICH10 device ids for sleep to work. I bet in system profiler in the USB section, your EHCI devices show up as built-in and the UHCI devices show up as external.
In your DSDT, erase the entire segment that includes the UHCn and EHCn devices and replace it with this one:
And make sure your have the DTGP method defined somewhere.
It's possible that this will fix sleep but that your laptop will freeze on wake. If that happens, restart your computer (with the Wake=No option line in chameleon or it will freeze again) and run this command in terminal:
Hibernate mode 3 (the default) doesn't seem to work on my laptop. I had to swtich to mode 0.
Hope this helps, keep us posted.
In your DSDT, erase the entire segment that includes the UHCn and EHCn devices and replace it with this one:
CODE
Device (UHC0)
{
Name (_ADR, 0x001D0000)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x34, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC1)
{
Name (_ADR, 0x001D0001)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x35, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC2)
{
Name (_ADR, 0x001D0002)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x36, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (EHC1)
{
Name (_ADR, 0x001D0007)
}
Device (UHC3)
{
Name (_ADR, 0x001A0000)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x37, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC4)
{
Name (_ADR, 0x001A0001)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x38, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC5)
{
Name (_ADR, 0x001D0003)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x39, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (EHC2)
{
Name (_ADR, 0x001A0007)
}
{
Name (_ADR, 0x001D0000)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x34, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC1)
{
Name (_ADR, 0x001D0001)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x35, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC2)
{
Name (_ADR, 0x001D0002)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x36, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (EHC1)
{
Name (_ADR, 0x001D0007)
}
Device (UHC3)
{
Name (_ADR, 0x001A0000)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x37, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC4)
{
Name (_ADR, 0x001A0001)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x38, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC5)
{
Name (_ADR, 0x001D0003)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x39, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (EHC2)
{
Name (_ADR, 0x001A0007)
}
And make sure your have the DTGP method defined somewhere.
It's possible that this will fix sleep but that your laptop will freeze on wake. If that happens, restart your computer (with the Wake=No option line in chameleon or it will freeze again) and run this command in terminal:
CODE
sudo pmset hibernatemode 0
Hibernate mode 3 (the default) doesn't seem to work on my laptop. I had to swtich to mode 0.
Hope this helps, keep us posted.
Tried those, but did not change anything. My dsdt.dsl.txt is attached below.
Click to view attachment
- edit by RIW - attached missing dsdt..
Click to view attachment
- edit by RIW - attached missing dsdt..
Have you checked in the USB section of system profiler that all USB devices appear as built-in ? If only one device appears as external, then sleep won't work. Also check if AppleLPC is loading. Again, this is required for vanilla sleep.
Could you go to system profiler, save your profile in a .spx file and post it ? If you have IO registry explorer, could you also go into this, save the registry in a .ioreg file and post it also ?
Do you use an entirely vanilla install ? On my laptop the only additional kexts I use are for PS2 keyboard and trackpad (AppleACPIPS2Nub and ApplePS2Controller), sound (VoodooHDA) and of course fameSMC. Everything else is pure, unmodified, un-disabled vanilla kexts, including AppleIntelCPUPowerManagement and AppleLPC.
Could you go to system profiler, save your profile in a .spx file and post it ? If you have IO registry explorer, could you also go into this, save the registry in a .ioreg file and post it also ?
Do you use an entirely vanilla install ? On my laptop the only additional kexts I use are for PS2 keyboard and trackpad (AppleACPIPS2Nub and ApplePS2Controller), sound (VoodooHDA) and of course fameSMC. Everything else is pure, unmodified, un-disabled vanilla kexts, including AppleIntelCPUPowerManagement and AppleLPC.
Alright, attached my dsdt.aml, registry, and system profiler output, and smbios.plist. I do not believe i have any disablers. I am running stock kernel and drivers. I tried two different boot flags:
1. arch=i386_X64: cannot boot without -v option
2. arch=x86_64: system boots up just fine.
How can i verify that the system is running in pure X64?
Reality i'd appreciate your input as well.
1. arch=i386_X64: cannot boot without -v option
2. arch=x86_64: system boots up just fine.
How can i verify that the system is running in pure X64?
Reality i'd appreciate your input as well.
QUOTE (applehacker @ Jan 26 2010, 08:31 PM) 
How can i verify that the system is running in pure X64?
CODE
uname -a
QUOTE
Darwin NIBBLER.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386
i386 == 32bit
x86_64 == 64bit
Attached IOREG output, and dsdt.aml and smbios.plist and system profiler output.
For USB to sleep correctly you need to write AAPL,clock-id property in _DSM method.
http://www.projectosx.com/forum/index.php?showtopic=461
http://www.projectosx.com/forum/index.php?showtopic=461
Ok, I know what your problem is, and I know how to fix it.
As I suspected, one of your USB devices still appears as external is system profiler, and I'm partly to blame for that.
In the code I posted to you earlier, change:
for:
The problem is that, with my board, the real physical address of the UHC5 device is not the same as yours. Mine was 1F0003, yours is 1A0002. I assumed that all ICH9M southbridges were the same. Apparently, I assumed wrong. You learn everyday.
There are numerous other issues with your DSDT, but let's tackle one problem at a time.
As I suspected, one of your USB devices still appears as external is system profiler, and I'm partly to blame for that.
In the code I posted to you earlier, change:
CODE
Device (UHC5)
{
Name (_ADR, 0x001D0003)
...
{
Name (_ADR, 0x001D0003)
...
for:
CODE
Device (UHC5)
{
Name (_ADR, 0x001A0002)
...
{
Name (_ADR, 0x001A0002)
...
The problem is that, with my board, the real physical address of the UHC5 device is not the same as yours. Mine was 1F0003, yours is 1A0002. I assumed that all ICH9M southbridges were the same. Apparently, I assumed wrong. You learn everyday.
There are numerous other issues with your DSDT, but let's tackle one problem at a time.
Alright, now the laptop goes to sleep... but wakes up almost instantly and destroys my sound. Also, what other things should I be doing with my dsdt? I know it has 23 warnings, but what do I do with those?
At first, my laptop was also waking up immediately after sleep. Seems our motherboards are very similar. I solved the problem by cleaning up the DSDT.
I'll give you a series of DSDT modifications that you'll need to apply. If they work, I'll tell you in a subsequent post what each modification does and what it's for.
1. Change your RTC0 device from this:
to this:
2. Change your HPET device from this:
to this:
3. Change your TMR device from this:
to this:
4. Change your SBRG device from this:
to this:
5. Completely replace your SATA device with this:
6. Completely remove your SAT1 device. There is only one SATA controller on ICH9M chipsets. The entry for a second SATA controller in the DSDT is bogus.
7. And finally, for your sound device, replace this:
with this:
and make sure that you use Slice's latest version of VoodooHDA (in the russian thread). Also make sure you replace the name HDAC with AZAL.
Now for this last one, I can't guarantee you that it will make your sound work after sleep, since we don't have the same sound device (mine is an IDT), but it's worth a try.
I know this all sounds like a lot, but please try this and tell me if it works.
I'll give you a series of DSDT modifications that you'll need to apply. If they work, I'll tell you in a subsequent post what each modification does and what it's for.
1. Change your RTC0 device from this:
CODE
Device (RTC0)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
})
}
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
})
}
to this:
CODE
Device (RTC0)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
IRQNoFlags ()
{4}
})
}
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
IRQNoFlags ()
{4}
})
}
2. Change your HPET device from this:
CODE
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (CRS, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
...
{
Name (_HID, EisaId ("PNP0103"))
Name (CRS, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
...
to this:
CODE
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (CRS, ResourceTemplate ()
{
IRQNoFlags ()
{2}
IRQNoFlags ()
{8}
IRQNoFlags ()
{11}
IRQNoFlags ()
{15}
Memory32Fixed (ReadOnly,
...
{
Name (_HID, EisaId ("PNP0103"))
Name (CRS, ResourceTemplate ()
{
IRQNoFlags ()
{2}
IRQNoFlags ()
{8}
IRQNoFlags ()
{11}
IRQNoFlags ()
{15}
Memory32Fixed (ReadOnly,
...
3. Change your TMR device from this:
CODE
Device (TMR)
{
Name (_HID, EisaId ("PNP0100"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x04, // Length
)
IRQNoFlags ()
{0}
})
}
{
Name (_HID, EisaId ("PNP0100"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x04, // Length
)
IRQNoFlags ()
{0}
})
}
to this:
CODE
Device (TMR)
{
Name (_HID, EisaId ("PNP0100"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x04, // Length
)
})
}
{
Name (_HID, EisaId ("PNP0100"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x04, // Length
)
})
}
4. Change your SBRG device from this:
CODE
Device (SBRG)
{
Name (_ADR, 0x001F0000)
Device (IELK)
...
{
Name (_ADR, 0x001F0000)
Device (IELK)
...
to this:
CODE
Device (SBRG)
{
Name (_ADR, 0x001F0000)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x16, 0x29, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
Device (IELK)
...
{
Name (_ADR, 0x001F0000)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x16, 0x29, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
Device (IELK)
...
5. Completely replace your SATA device with this:
CODE
Device (SATA)
{
Name (_ADR, 0x001F0002)
Device (PRT0)
{
Name (_ADR, 0x00)
}
Device (PRT1)
{
Name (_ADR, 0x01)
}
Device (PRT4)
{
Name (_ADR, 0x04)
}
Device (PRT5)
{
Name (_ADR, 0x05)
}
}
{
Name (_ADR, 0x001F0002)
Device (PRT0)
{
Name (_ADR, 0x00)
}
Device (PRT1)
{
Name (_ADR, 0x01)
}
Device (PRT4)
{
Name (_ADR, 0x04)
}
Device (PRT5)
{
Name (_ADR, 0x05)
}
}
6. Completely remove your SAT1 device. There is only one SATA controller on ICH9M chipsets. The entry for a second SATA controller in the DSDT is bogus.
7. And finally, for your sound device, replace this:
CODE
Device (HDAC)
{
Name (_ADR, 0x001B0000)
Method (_PRW, 0, NotSerialized)
{
Return (GPRW (0x0D, 0x04))
}
}
{
Name (_ADR, 0x001B0000)
Method (_PRW, 0, NotSerialized)
{
Return (GPRW (0x0D, 0x04))
}
}
with this:
CODE
Device (AZAL)
{
Name (_ADR, 0x001B0000)
}
{
Name (_ADR, 0x001B0000)
}
and make sure that you use Slice's latest version of VoodooHDA (in the russian thread). Also make sure you replace the name HDAC with AZAL.
Now for this last one, I can't guarantee you that it will make your sound work after sleep, since we don't have the same sound device (mine is an IDT), but it's worth a try.
I know this all sounds like a lot, but please try this and tell me if it works.
I was able to use all those optimizations except the last 3. They wouldn't let me compile the dsdt. But now my computer shuts off and restarts when i tell it to. Still instant wake on sleep though. I can't fix those last three. Any more ideas?
You must have made a mistake somewhere. The only mistake was in the sound device modification; the HDAC name appeared somewhere else in the DSDT and had to be changed to AZAL also.
Anyway, I've made the modifications to the DSDT you provided, and it compiles just fine. I saw the 23 warnings and you can ignore them, they are irrelevant.
I've included the modified DSDT.dsl with this post. Try it and tell me how it works. You can also compare it to the one you modified yourself to see where the differences are and why yours doesn't compile.
Click to view attachment
Anyway, I've made the modifications to the DSDT you provided, and it compiles just fine. I saw the 23 warnings and you can ignore them, they are irrelevant.
I've included the modified DSDT.dsl with this post. Try it and tell me how it works. You can also compare it to the one you modified yourself to see where the differences are and why yours doesn't compile.
Click to view attachment
Recompiled successfully, and now im back to square one. Now when i press sleep, the laptop goes black, but all my touch lights and indicators stay on. No more waking, and i have to manually shut it off. Don't know why, but it just does. How do I proceed from here? Thanks for helpin me out.
I forgot that the DSDT you sent me had the wrong address for device UHC5. I made all the corrections but left the wrong address for UHC5.
I've now corrected it. This one should work.
Click to view attachment
I've now corrected it. This one should work.
Click to view attachment
This is a symptom of disabling AppleIntelCPUPowermangement without sleepenabler. If you are using NullCPUPowermangegment try the -allowAppleCPUPM flag. If it boots, sleeps and runs properly remove the kext.
Nope, not using any disablers. And tried the new dsdt, still suffers from instant wake. Any way to code the ALC888s into the dsdt so that OS X will recognize it, or are there no driver support for it in OS X?
The only thing left that I did in my DSDT but not in yours is to remove the IRQ in the PIC device. There was an IRQ in my DSDT for this device but IORegistryExplorer showed that in reality, the device never used one, so I removed it in my DSDT. I was hesitant about advising you to do the same because, unlike mine, your IORegistryExplorer showed that your device did in fact used the IRQ specified in your DSDT.
But I think it's worth a try. In your PIC device, remove the following lines:
If that doesn't work, then I'm running out of ideas. we have the same ICH9M chipset, and after this last modification our devices will be configured the same.
But I think it's worth a try. In your PIC device, remove the following lines:
CODE
IRQNoFlags ()
{2}
{2}
If that doesn't work, then I'm running out of ideas. we have the same ICH9M chipset, and after this last modification our devices will be configured the same.
QUOTE (laqk @ Jan 29 2010, 03:03 PM)
The only thing left that I did in my DSDT but not in yours is to remove the IRQ in the PIC device. There was an IRQ in my DSDT for this device but IORegistryExplorer showed that in reality, the device never used one, so I removed it in my DSDT. I was hesitant about advising you to do the same because, unlike mine, your IORegistryExplorer showed that your device did in fact used the IRQ specified in your DSDT.
But I think it's worth a try. In your PIC device, remove the following lines:
If that doesn't work, then I'm running out of ideas. we have the same ICH9M chipset, and after this last modification our devices will be configured the same.
But I think it's worth a try. In your PIC device, remove the following lines:
CODE
IRQNoFlags ()
{2}
{2}
If that doesn't work, then I'm running out of ideas. we have the same ICH9M chipset, and after this last modification our devices will be configured the same.
No dice. Still wakes when I press sleep or close the lid.
What bothers me is that I never figured out exactly how I solved the insta wake problem on my rig. All I know is that it stopped after I cleaned up my DSDT. Believe me, I systematically tried to remove and add specific modifications, one by one, to try to find which one solved the problem. It seems that no one single modification does the trick, it seems to be a combination of several hacks/patches.
I see a few other things in your DSDT that could be modified or cleaned up that you could try. For example, your DSDT specifies a few devices that don't exist with your hardware (your SAT1 device is an example of this), and in other parts of your DSDT, I see methods that issue notify() commands to those devices, with no code to previously check for the device's actual existence. This is bound to cause some problems. Whether this is related to the insta wake problem or not, I can't tell. I still have so much stuff to learn myself.
I hope I helped you enough to enable you to continue to figure out things on your own. But this insta wake thing is not something I'll simply let die, even thought I've solved it myself. It's not enough for me to know that the problem is solved, I need to know why and how. If (when) I figure it out, I'll be sure to let you know.
I see a few other things in your DSDT that could be modified or cleaned up that you could try. For example, your DSDT specifies a few devices that don't exist with your hardware (your SAT1 device is an example of this), and in other parts of your DSDT, I see methods that issue notify() commands to those devices, with no code to previously check for the device's actual existence. This is bound to cause some problems. Whether this is related to the insta wake problem or not, I can't tell. I still have so much stuff to learn myself.
I hope I helped you enough to enable you to continue to figure out things on your own. But this insta wake thing is not something I'll simply let die, even thought I've solved it myself. It's not enough for me to know that the problem is solved, I need to know why and how. If (when) I figure it out, I'll be sure to let you know.
yeah im new at this too, but its not as bad as attempting to write a driver for an ATI Mobility card.... What do I do to clean up those warnings?
EDIT
completely cleaned out my DSDT, now no warnings, errors, or remarks. I try to sleep, and still insta wake. According to dmesg, the reason is
wake reason = GBE EHC1
System wake
Previous Sleep Cause: 0
I do not know what GBE is, but on the EHC1, is my internal camera. What do I do to fix this? I am so close......
attached dsdt.aml below. I added those "aapl-clock" things to the EHC1 and EHC2
EDIT
completely cleaned out my DSDT, now no warnings, errors, or remarks. I try to sleep, and still insta wake. According to dmesg, the reason is
wake reason = GBE EHC1
System wake
Previous Sleep Cause: 0
I do not know what GBE is, but on the EHC1, is my internal camera. What do I do to fix this? I am so close......
attached dsdt.aml below. I added those "aapl-clock" things to the EHC1 and EHC2
GBE is a device that appears in your DSDT. When I wake up my machine using the power button, this line appears in the kernel log:
wake reason = PWRB EHC1
PWRB being the name the power button device has in my DSDT.
If you check your DSDT, you'll find the following device:
According to the ACPI specification, the _PRW method is present only in devices that can be used to wake up the system. My guess is, if you remove the _PRW method in your GBE device:
it might stop the insta wake problem. I think it's worth a try.
EDIT:
GBE is definately the device causing the insta wake problem. Comparing your DSDT with mine, I found a device called LANC at the same address. Then it came to me: GBE = GigaByteEthernet. However, like on my machine, the GBE device does not exist, like the LANC device in my DSDT which doesn't exist either.
Just to be certain, I reverted to an older version of my DSDT that had the insta wake problem. Then I completely removed the bogus LANC device, compiled, rebooted, and tried sleeping again, and it worked ! No more insta wake !
So I'm 99% sure that entirely removing the bogus GBE device in your DSDT will solve your problem also. The problem obviously came from the presence of a _PRW method in a device that doesn't physically exist on our boards.
Thanks for bringing my attention to the kernel logs.
wake reason = PWRB EHC1
PWRB being the name the power button device has in my DSDT.
If you check your DSDT, you'll find the following device:
CODE
Device (GBE)
{
Name (_ADR, 0x00190000)
Method (_PRW, 0, NotSerialized)
{
Return (GPRW (0x0D, 0x04))
}
}
{
Name (_ADR, 0x00190000)
Method (_PRW, 0, NotSerialized)
{
Return (GPRW (0x0D, 0x04))
}
}
According to the ACPI specification, the _PRW method is present only in devices that can be used to wake up the system. My guess is, if you remove the _PRW method in your GBE device:
CODE
Device (GBE)
{
Name (_ADR, 0x00190000)
}
{
Name (_ADR, 0x00190000)
}
it might stop the insta wake problem. I think it's worth a try.
EDIT:
GBE is definately the device causing the insta wake problem. Comparing your DSDT with mine, I found a device called LANC at the same address. Then it came to me: GBE = GigaByteEthernet. However, like on my machine, the GBE device does not exist, like the LANC device in my DSDT which doesn't exist either.
Just to be certain, I reverted to an older version of my DSDT that had the insta wake problem. Then I completely removed the bogus LANC device, compiled, rebooted, and tried sleeping again, and it worked ! No more insta wake !
So I'm 99% sure that entirely removing the bogus GBE device in your DSDT will solve your problem also. The problem obviously came from the presence of a _PRW method in a device that doesn't physically exist on our boards.
Thanks for bringing my attention to the kernel logs.
QUOTE (laqk @ Feb 4 2010, 10:18 AM)
GBE is a device that appears in your DSDT. When I wake up my machine using the power button, this line appears in the kernel log:
wake reason = PWRB EHC1
PWRB being the name the power button device has in my DSDT.
If you check your DSDT, you'll find the following device:
According to the ACPI specification, the _PRW method is present only in devices that can be used to wake up the system. My guess is, if you remove the _PRW method in your GBE device:
it might stop the insta wake problem. I think it's worth a try.
EDIT:
GBE is definately the device causing the insta wake problem. Comparing your DSDT with mine, I found a device called LANC at the same address. Then it came to me: GBE = GigaByteEthernet. However, like on my machine, the GBE device does not exist, like the LANC device in my DSDT which doesn't exist either.
Just to be certain, I reverted to an older version of my DSDT that had the insta wake problem. Then I completely removed the bogus LANC device, compiled, rebooted, and tried sleeping again, and it worked ! No more insta wake !
So I'm 99% sure that entirely removing the bogus GBE device in your DSDT will solve your problem also. The problem obviously came from the presence of a _PRW method in a device that doesn't physically exist on our boards.
Thanks for bringing my attention to the kernel logs.
wake reason = PWRB EHC1
PWRB being the name the power button device has in my DSDT.
If you check your DSDT, you'll find the following device:
CODE
Device (GBE)
{
Name (_ADR, 0x00190000)
Method (_PRW, 0, NotSerialized)
{
Return (GPRW (0x0D, 0x04))
}
}
{
Name (_ADR, 0x00190000)
Method (_PRW, 0, NotSerialized)
{
Return (GPRW (0x0D, 0x04))
}
}
According to the ACPI specification, the _PRW method is present only in devices that can be used to wake up the system. My guess is, if you remove the _PRW method in your GBE device:
CODE
Device (GBE)
{
Name (_ADR, 0x00190000)
}
{
Name (_ADR, 0x00190000)
}
it might stop the insta wake problem. I think it's worth a try.
EDIT:
GBE is definately the device causing the insta wake problem. Comparing your DSDT with mine, I found a device called LANC at the same address. Then it came to me: GBE = GigaByteEthernet. However, like on my machine, the GBE device does not exist, like the LANC device in my DSDT which doesn't exist either.
Just to be certain, I reverted to an older version of my DSDT that had the insta wake problem. Then I completely removed the bogus LANC device, compiled, rebooted, and tried sleeping again, and it worked ! No more insta wake !
So I'm 99% sure that entirely removing the bogus GBE device in your DSDT will solve your problem also. The problem obviously came from the presence of a _PRW method in a device that doesn't physically exist on our boards.
Thanks for bringing my attention to the kernel logs.
It didn't work
1. I removed _PRW method from GBE, compiled without trouble, rebooted, insta wake
2. Completely removed GBE from DSDT, still insta wake
DMESG still points to GBE as a wake problem........ wake on lan disabled in energy saver........ I am really confused now lol
I don't know if this makes a difference, but I also have touch sensor panel with different functions. after insta wake, the ability to use that panel is gone. Also, bluetooth is spotty. On one boot up it recognizes bluetooth, the next it doesnt. And when it doesn't, its not recognized in windows either. How to fix this as well?
QUOTE (applehacker @ Feb 4 2010, 05:25 PM)
DMESG still points to GBE as a wake problem........
How can this be possible ?! If the device physically doesn't exist, and if it's completely removed from the DSDT, then how can the system possibly know that it's called "GBE" and put this in the log ? Where does the system get the name ?
You're not the only one who's confused...
Are you absolutely sure that your system is booting using your modified DSDT ?
Could you post the new versions of your .spx and .ioreg files ? There's something I'd like to check...
I have attached my DSDT.aml, IOREG, and spx. This is really confusing.......GBE is still wake reason, even though its not in the DSDT. Reality/Slice/laqk, any more ideas?
Click to view attachment
Click to view attachment
Ok, two things:
First, the DSDT you posted shows that the GBE device has indeed been removed. However, your IOREG clearly shows that the GBE device is still present in the DSDT, because it still appears as a non-existent device in IODeviceTree. The only explanation is that somehow your system is not booting with the latest DSDT you have compiled, but with an earlier version. I urge you to check this, because there's no way we'll ever be able to solve your problems if we can't be 100% sure that your system actually uses the latest DSDT.aml file you're compiling.
Second, I extensively examined your DSDT and found a number of non-existent devices in it, most of which having a _PRW method:
So in addition to GBE, anyone of these devices could be causing the insta wake problem.
How do I know that these devices are non-existent ? Simple. If you start IORegistryExplorer and select "IODeviceTree" in the upper left corner drop down box, you'll see a list of devices, some of which physically exist and are defined in the DSDT, others that don't physically exist but appear in the DSDT, and finally a few others that physically exist but are not defined in the DSDT.
If a device defined in the DSDT corresponds to an existing device at the specified address, then this device will appear under it's DSDT-defined name in IODeviceTree, followed by the abbreviated form of its address.Ex:
will appear in IODeviceTree as:
On the other hand, if a device is defined in the DSDT, but NO physical device exists at the address specified, then this device appears like this in IODeviceTree:
will appear in IODeviceTree as:
As you can see, the address appears in its non-abbreviated form, and if you select this device, all you'll see in the right pane is "acpi-device" and "acpi-path" strings and nothing else, indicating that the device does not exist.
Finally, devices that physically exist on the motherboard but don't have a corresponding definition in the DSDT will appear like this in IODeviceTree:
Since the system doesn't know the name of the device (since it's not defined in the DSDT), then it names it according to its vendor id and device id (the part on the left on the @ sign), and it shows its address in its abbreviated form (the part at the right of the @ sign) because its a physically existing device.
Now I've modified your DSDT by cleaning up the SATA device and removing all non-existent devices and their references. The only one I didn't touch is GFX0 because 1) its references in other parts of the DSDT are more complicated to sort out, and 2) it doesn't have a _PRW method, so it shouldn't interfere with sleep/wake.
Try it and tell me if it works. And make absolutely sure that your system does indeed use the compiled DSDT when booting, and not some other DSDT.aml file somewhere else.
Click to view attachment
First, the DSDT you posted shows that the GBE device has indeed been removed. However, your IOREG clearly shows that the GBE device is still present in the DSDT, because it still appears as a non-existent device in IODeviceTree. The only explanation is that somehow your system is not booting with the latest DSDT you have compiled, but with an earlier version. I urge you to check this, because there's no way we'll ever be able to solve your problems if we can't be 100% sure that your system actually uses the latest DSDT.aml file you're compiling.
Second, I extensively examined your DSDT and found a number of non-existent devices in it, most of which having a _PRW method:
CODE
GFX0
P0P8
P0P9
WAWA with a subdevice PECA
P0P8
P0P9
WAWA with a subdevice PECA
So in addition to GBE, anyone of these devices could be causing the insta wake problem.
How do I know that these devices are non-existent ? Simple. If you start IORegistryExplorer and select "IODeviceTree" in the upper left corner drop down box, you'll see a list of devices, some of which physically exist and are defined in the DSDT, others that don't physically exist but appear in the DSDT, and finally a few others that physically exist but are not defined in the DSDT.
If a device defined in the DSDT corresponds to an existing device at the specified address, then this device will appear under it's DSDT-defined name in IODeviceTree, followed by the abbreviated form of its address.Ex:
CODE
Device (P0P5)
{
Name (_ADR, 0x001C0001)
...
{
Name (_ADR, 0x001C0001)
...
will appear in IODeviceTree as:
P0P5@1C,1
On the other hand, if a device is defined in the DSDT, but NO physical device exists at the address specified, then this device appears like this in IODeviceTree:
CODE
Device (P0P9)
{
Name (_ADR, 0x001C0005)
...
{
Name (_ADR, 0x001C0005)
...
will appear in IODeviceTree as:
P0P9@1C0005
As you can see, the address appears in its non-abbreviated form, and if you select this device, all you'll see in the right pane is "acpi-device" and "acpi-path" strings and nothing else, indicating that the device does not exist.
Finally, devices that physically exist on the motherboard but don't have a corresponding definition in the DSDT will appear like this in IODeviceTree:
pci8086,2930@1F,3
Since the system doesn't know the name of the device (since it's not defined in the DSDT), then it names it according to its vendor id and device id (the part on the left on the @ sign), and it shows its address in its abbreviated form (the part at the right of the @ sign) because its a physically existing device.
Now I've modified your DSDT by cleaning up the SATA device and removing all non-existent devices and their references. The only one I didn't touch is GFX0 because 1) its references in other parts of the DSDT are more complicated to sort out, and 2) it doesn't have a _PRW method, so it shouldn't interfere with sleep/wake.
Try it and tell me if it works. And make absolutely sure that your system does indeed use the compiled DSDT when booting, and not some other DSDT.aml file somewhere else.
Click to view attachment
System still insta wakes. How can I verify that the dsdt is being loaded? Wake reason is still GBE.
EDIT
FIXED!!!!!!!!!!!!! SLEEP WOHOO!!!!!!!
There was another hidden DSDT.aml in /Extra/
Is there a way to enable ALC888s as natively enabled in OS X so that it shows up in system profiler and uses stock kexts?
EDIT
FIXED!!!!!!!!!!!!! SLEEP WOHOO!!!!!!!
There was another hidden DSDT.aml in /Extra/
Is there a way to enable ALC888s as natively enabled in OS X so that it shows up in system profiler and uses stock kexts?
reading elsewhere on the board may help.
AppleHDA tutorial.. also, System profiler is entirely cosmetic, and whether it shows up in there or not does not mean it's actually working, or not.
AppleHDA tutorial.. also, System profiler is entirely cosmetic, and whether it shows up in there or not does not mean it's actually working, or not.
QUOTE (applehacker @ Feb 5 2010, 12:34 PM)
System still insta wakes. How can I verify that the dsdt is being loaded? Wake reason is still GBE.
EDIT
FIXED!!!!!!!!!!!!! SLEEP WOHOO!!!!!!!
There was another hidden DSDT.aml in /Extra/
Is there a way to enable ALC888s as natively enabled in OS X so that it shows up in system profiler and uses stock kexts?
EDIT
FIXED!!!!!!!!!!!!! SLEEP WOHOO!!!!!!!
There was another hidden DSDT.aml in /Extra/
Is there a way to enable ALC888s as natively enabled in OS X so that it shows up in system profiler and uses stock kexts?
Sound shows up in system profiler, but it still doesn't list any output devices, and I can't really understand how to patch this applehda stuff. And voodoohda doesn't do well for me. If anybody has the correct patched files for ALC888 Address 0, please post here!
EDIT
Got Audio to work via DSDT and LegacyHDA, but have a few problems:
1. No auto switching between headphones and speakers
2. Stuff are labeled incorrectly (headphones are speakers, speakers are headphones, etc)
How do I go about that stuff? Are there any audio kexts that may be interfering?
EDIT
Got Audio to work via DSDT and LegacyHDA, but have a few problems:
1. No auto switching between headphones and speakers
2. Stuff are labeled incorrectly (headphones are speakers, speakers are headphones, etc)
How do I go about that stuff? Are there any audio kexts that may be interfering?
New problem. After this dsdt mod, my external esata hard drive cannot be recognized by OS X.
Edit
sorry for the double post, thought it auto merged
anyway, solved the issue. nvm. Any ideas on auto swtich audio though and the mislabeld stuff?
Edit
sorry for the double post, thought it auto merged
anyway, solved the issue. nvm. Any ideas on auto swtich audio though and the mislabeld stuff?
"anyway, solved the issue"
how did you solve the issue. I've also got a gx720, but never been able to make the sleep work. Sound working with slice's voodoohda:
http://www.projectosx.com/forum/index.php?...ic=355&st=0
Could you post a copy of your dsdt?
how did you solve the issue. I've also got a gx720, but never been able to make the sleep work. Sound working with slice's voodoohda:
http://www.projectosx.com/forum/index.php?...ic=355&st=0
Could you post a copy of your dsdt?
Also here is someone else working on alc888s kext but its in italian (use google translate) :
http://www.insanelymac.com/forum/index.php...t=#entry1507287
Theres also a pretty useful pin configurator app that can use linux dumps and windows pinconfig verbs
http://www.insanelymac.com/forum/index.php...t=#entry1507287
Theres also a pretty useful pin configurator app that can use linux dumps and windows pinconfig verbs
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.