Contribute
Register

Reset/restart after wakeup from sleep in Haswell system / 10.9.4 / ASUS B85M-G

Status
Not open for further replies.
Ok thanks for these infos.

I added your AcPIdebug (very nice tool) kext to clover/kexts and inserted debug device plus _WAK / _PTS start/end debug. I can see that our acpidebug device is loading in the boot.log. I did a sleep mode start, the system went to sleep, immediately woke up and then restarted. There are no entries in the boot log of acpidebug. no "_WAK" or "_PTS".

So can I conclude that _WAK isn't called at all like it should?

Btw. what for is the PEGP device? Here in the _WAK method beginning:

Code: 
       \RMDT.P2 ("_WAK enter", Arg0)
        ShiftLeft (Arg0, 0x04, DBG8)
        WAK (Arg0)
        ADBG ("_WAK")
        If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04)))
        {
            If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON))
            {
                \_SB.PCI0.PEG0.PEGP.EPON ()
            }

            If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON))
            {
                \_SB.PCI0.RP05.PEGP.EPON ()
            }
        }
Seems to be a test on what PCIe slot the graphics device is attached and then power on? Cannot find any EPON method or something...
 
funkyfrank said:
Ok thanks for these infos.

I added your AcPIdebug (very nice tool) kext to clover/kexts and inserted debug device plus _WAK / _PTS start/end debug. I can see that our acpidebug device is loading in the boot.log. I did a sleep mode start, the system went to sleep, immediately woke up and then restarted. There are no entries in the boot log of acpidebug. no "_WAK" or "_PTS".

So can I conclude that _WAK isn't called at all like it should?
Click to expand...

Not really. In the case of reboot, ACPIDebug.kext never got a chance to collect data and output it...

Btw. what for is the PEGP device? Here in the _WAK method beginning:

Code: 
       \RMDT.P2 ("_WAK enter", Arg0)
        ShiftLeft (Arg0, 0x04, DBG8)
        WAK (Arg0)
        ADBG ("_WAK")
        If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04)))
        {
            If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON))
            {
                \_SB.PCI0.PEG0.PEGP.EPON ()
            }

            If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON))
            {
                \_SB.PCI0.RP05.PEGP.EPON ()
            }
        }
Seems to be a test on what PCIe slot the graphics device is attached and then power on? Cannot find any EPON method or something...
Click to expand...

You should probably look at my patches: https://github.com/RehabMan/Laptop-DSDT-Patch
(ignore that it says laptop... there are many that are not laptop specific)

You should be aware that OS X passes garbage in Arg0 to _WAK on wake from sleep (OS X bug appeared somewhere in 10.8... 10.8.2?). There is a patch for that "Fix _WAK Arg0 v2".

As far as EPON, the code is testing whether the method exists (CondRefOf) and if it does, it is calling it.

Make sure all unnecessary devices are disconnected while testing sleep (eg. no USB WiFi, etc.)
 
Ok, I will try this soon, have to go now.

Is realized that the computer crashes if Clover doesn't do the "display fix". This will insert a GFX0 device:
Code: 
           Device (PEG0)
            {
                Name (_ADR, 0x00010000)
                Device (GFX0)
                {
                    Name (_ADR, Zero)
                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package (0x04)
                            {
                                "ATY,VendorID", 
                                Buffer (0x02)
                                {
                                    0x02, 0x10
                                }, 

                                "hda-gfx", 
                                Buffer (0x0A)
                                {
                                    "onboard-1"
                                }
                            }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }

                    Name (_SUN, 0x00000001)
                }
            }
Without it there will be a kernel panic. Is this insertion right for my ATI HD5570?

Is PEGP a synonyme for GFX0?
 
funkyfrank said:
Ok, I will try this soon, have to go now.

Is realized that the computer crashes if Clover doesn't do the "display fix". This will insert a GFX0 device:
Code: 
           Device (PEG0)
            {
                Name (_ADR, 0x00010000)
                Device (GFX0)
                {
                    Name (_ADR, Zero)
                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package (0x04)
                            {
                                "ATY,VendorID", 
                                Buffer (0x02)
                                {
                                    0x02, 0x10
                                }, 

                                "hda-gfx", 
                                Buffer (0x0A)
                                {
                                    "onboard-1"
                                }
                            }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }

                    Name (_SUN, 0x00000001)
                }
            }
Without it there will be a kernel panic. Is this insertion right for my ATI HD5570?
Click to expand...

Probably correct if that's what Clover injects... I have no experience with discrete cards and OS X as I don't have the hardware.

Is PEGP a synonyme for GFX0?
Click to expand...

In PC DSDTs... discrete card is usually called PEGP, integrated GFX0, whereas on Macs, discrete is GFX0 and integrated IGPU.
 
Can the GFX0 device reside in SSDT-6 instead DSDT? Since there is \_SB.PCI0.PEG0.

Can the path be \_SB.PCI0.PEG0 or has it to be _SB.PCI0.PEG0.GFX0 ?

And last question, if Clover injects _SB.PCI0.PEG0.GFX0 and with this, also a new PEG0, will the \_SB.PCI0.PEG0 from ssdt still be used? How could I join them? Should I place everything to DSDT?

Why the path sometimes is \_SB and sometimes _SB?
 
WOOOHOHO the sleep mode works already (without Powernap)!!!

RehabMan thanks a big lot! I think your recent suggestion to execute the patch "Fix _WAK Arg0 v2" from your MaciASL repository did the trick!

Cool stuff. Now the power switch blinks in standby. What a cool effect!

Ok maybe I could also enable Powernap? ... :)

BTW. ACPIdebug now indicates that _PTS is correctly executed until end, but _WAK only the beginning.
 
funkyfrank said:
WOOOHOHO the sleep mode works already (without Powernap)!!!

RehabMan thanks a big lot! I think your recent suggestion to execute the patch "Fix _WAK Arg0 v2" from your MaciASL repository did the trick!

Cool stuff. Now the power switch blinks in standby. What a cool effect!

Ok maybe I could also enable Powernap? ... :)
Click to expand...

Cool...

I'm surprised more desktops (even Gigabyte) don't need that patch, because it is a very bad/obvious OS X bug that would likely affect any DSDT _WAK method.

BTW. ACPIdebug now indicates that _PTS is correctly executed until end, but _WAK only the beginning.
Click to expand...

Further instrument _WAK to determine where it aborts.
 
funkyfrank said:
Can the GFX0 device reside in SSDT-6 instead DSDT? Since there is \_SB.PCI0.PEG0.

Can the path be \_SB.PCI0.PEG0 or has it to be _SB.PCI0.PEG0.GFX0 ?

And last question, if Clover injects _SB.PCI0.PEG0.GFX0 and with this, also a new PEG0, will the \_SB.PCI0.PEG0 from ssdt still be used? How could I join them? Should I place everything to DSDT?

Why the path sometimes is \_SB and sometimes _SB?
Click to expand...

I would think it would be rare for a discrete device to have ACPI representation on a desktop... because they are add-in cards, not built-in (like on laptops). Certainly a BIOS could "generate" ACPI, or the card itself could provide an SSDT, but I don't know if that is normally what is done. You could extract your native files on Linux and see.

Note: I don't have any discrete setups, so my experience is limited there...

\_SB and _SB are essentially the same thing. It depends on what the compiler generates and what was written in the first place.
 
RehabMan said:
Further instrument _WAK to determine where it aborts.
Click to expand...

The _WAK breaks here:
Code: 
        If (LAnd (LNotEqual (And (\_SB.PCI0.HDAU.ABAR, 0xFFFFC004), 0xFFFFC004), 
            LNotEqual (And (\_SB.PCI0.HDAU.ABAR, 0xFFFFC000), Zero)))
        {
            Store (\_SB.PCI0.HDAU.ABAR, \_SB.PCI0.HDAU.BARA)
        }

HDAU seems to be the hdmi audio from Intel HD4600 in SSDT-6. Maybe since it's not correctly initialized, it will break...
 
RehabMan said:
\_SB and _SB are essentially the same thing. It depends on what the compiler generates and what was written in the first place.
Click to expand...

But if \_SB and _SB are the same, why OSX doesn't find the display fix if I insert it into SSDT-6 under PEG0.PEGP and rename it to PEG0.GFX0? It seems it have to be under _SB.PCI.PEG0.GFX0 and not \_SB.PCI.PEG0.GFX0...?
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top