No graphics / USB / Audio after wake

[passmaster16]

Hi guys.  I have a Sony Vaio E Series SVE1712BCXB laptop with a AMD Radeon 7650M video card.  The 7650M is basically a rebranded AMD 6000 series GPU. OpenGL viewer shows the chip as a Radeon Thames Pro Prototype (attached). I'm experiencing similar issues with waking from sleep under 10.11 that I was not experiencing under 10.9.  I'm using the same modified Pondweed frame buffer, loading the Vbios, injecting EDID, and injecting ATI in Clover config.plist on 10.11 that I was using in 10.9 -- no changes whatsoever.  I am using MacBookPro9,2 SMBIOS since I have an Intel Core i5 3210M (Ivy Bridge) CPU.  I get proper video on initial boot of 10.11 and the GPU appears to be recognized the same way it was on 10.9.  However when I put the machine to sleep and attempt to wake up, I get a black screen both on the built-in laptop display and also no output on HDMI.  When this happens I cannot VNC to the machine but can SSH to it, so the network and OS is responsive.

 

I believe I'm seeing similar events in the system.log as others.  I've attached the full log from the time I put the system to sleep, to wakeup attempt, and finally after the system times out and reboots itself.

 

Machine put to sleep

Nov 21 13:39:14 Joshuas-MBP WindowServer[145]: no sleep images for WillPowerOffWithImages

Attempt to wake up

 

Nov 21 13:39:56 Joshuas-MBP kernel[0]: Opened file /var/log/SleepWakeStacks.bin, size 172032, extents 1, maxio 2000000 ssd 1Nov 21 13:39:56 Joshuas-MBP kernel[0]: polled file major 1, minor 0, blocksize 4096, pollers 5Nov 21 13:41:17 Joshuas-MBP kernel[0]: Wake reason: power-button (User)
Nov 21 13:41:17 Joshuas-MBP kernel[0]: No interval found for . Using 8000000
Nov 21 13:41:17 Joshuas-MBP CommCenter[322]: Telling CSI to exit low power.
Nov 21 13:41:17 Joshuas-MBP kernel[0]: Previous sleep cause: 5

 

ATI timeout

Nov 21 13:42:02 Joshuas-MBP kernel[0]: ATIFramebufferNI::setPowerState(0xeb3f53b2a9df5289, 0 -> 2) timed out after 45613 ms

After a while it just gives up and reboots the machine

Nov 21 13:46:18 Joshuas-MBP kernel[0]: Restarting to collect Sleep wake debug logs

I'm a bit of a novice but let me know if there is anything else I can do to help.  

Archive 3.zip

[Vlada.]

I’m starting to suspect that actually IGPU doesn’t have much with this problem. 

 

I check both situation, with enabled IGPU in the BIOS and disabled variation, also with implemented DSDT patch and without them, and the last one where IGPU is completely disabled from the system tree, but the result is always the same. I also switch AppleGraphicsControl.kext & AppleGraphicsPowerManagement.kext with the one from the OS X 10.10.5, just because I suspect in importance of those in this matter. And yes, the GPU is working that way, but the wake result is the same. 

 

Which brings me to the conclusion that the core of the problem is actually in the AMDRadeonX4000 & AMDRadeonX3000 kexts. We all know that the Apple has made some changes, but I think that the crucial one is the elimination of the sensor-properties lines under the both mentioned kexts.

 

Wake is working only when both IGPU and GPU are enabled, but of course where IGPU is set in the BIOS as first device, and that is probably because in that variation system can execute wake command properly, which is not the case in the vice versa situation. This indicated that elimination of the sensor-properties lines is probably the core of the problem.  

 

The solution is perhaps hidden in the questions why are those lines removed and how is that part managed now under the El Capitan on the Mac computers? 

[Mieze]

 

I’m starting to suspect that actually IGPU doesn’t have much with this problem. 

 

I check both situation, with enabled IGPU in the BIOS and disabled variation, also with implemented DSDT patch and without them, and the last one where IGPU is completely disabled from the system tree, but the result is always the same. I also switch AppleGraphicsControl.kext & AppleGraphicsPowerManagement.kext with the one from the OS X 10.10.5, just because I suspect in importance of those in this matter. And yes, the GPU is working that way, but the wake result is the same. 

 

Which brings me to the conclusion that the core of the problem is actually in the AMDRadeonX4000 & AMDRadeonX3000 kexts. We all know that the Apple has made some changes, but I think that the crucial one is the elimination of the sensor-properties lines under the both mentioned kexts.

 

Wake is working only when both IGPU and GPU are enabled, but of course where IGPU is set in the BIOS as first device, and that is probably because in that variation system can execute wake command properly, which is not the case in the vice versa situation. This indicated that elimination of the sensor-properties lines is probably the core of the problem.  

 

The solution is perhaps hidden in the questions why are those lines removed and how is that part managed now under the El Capitan on the Mac computers? 

 

Yes and no, because the removal of the sensor properties is only a result of the fact that Apple has changed the way graphics power management works. In Yosemite and before every GPU used to handle PM on its own but now Apple has implemented a master-slave architecture where one driver acts as the master, also controlling the secondary GPU. With regard to iMacs this seems to be the onboard graphics driver, for the 2013 Mac Pro it's  AppleMGPUPowerControl.kext which controls PM for both AMD GPUs.

 

Mieze

[passmaster16]

 

I’m starting to suspect that actually IGPU doesn’t have much with this problem. 

 

It's interesting that you say this because I don't see any presence of an IGPU in my IOReg.  I remember when I first started playing with getting 10.9 installed on this VAIO and people kept saying that there was no way to activate the IGPU on these systems.  Sony locked these machines down fairly well and there's practically no settings in the BIOS.  I recall somebody else trying to put a hacked BIOS on the machine in hopes of enabling the IGPU without any success.  So when I started this project, I focused on getting the Radeon 7650m recognized which I was able to do after a few weeks.  

I have another approach to find out what exactly the dependency is. The MacPro6,1 is equipped with a Radeon D300, which is basically a Radeon R9 270X according to its device ID. Unlike the iMac, it doesn't have Intel graphics but instead you can find device GCON and its driver AppleMGPUPowerControl.kext, which is in turn a plugin of AppleGraphicsControl.kext. Compared in size and complexity with the Intel graphics drivers, this driver is tightly structured and it seems to take the Intel driver's part when it comes to wakeup on these machines. If we can figure out how it helps the AMD driver to wake up, then we know what the Intel driver has to fro do on other machines with IGPU.

 

Mieze 

 

Just ran kextstat from my system and do not see AppleMGPUPowerControl.kext loaded

 

What I found interesting on my system is that AppleIntelFramebufferCapri is loaded.  Is this normal on a system with only a discrete GPU?

com.apple.driver.AppleIntelFramebufferCapri (10.1.0) F51689B9-35FE-3D63-900F-D422203239D4 <76 75 74 12 11 7 6 5 4 3 1>

I would only expect to see the AMD Framebuffer loaded as it shown below.

   78    2 0xffffff7f8255d000 0x133000   0x133000   com.apple.kext.AMDSupport (1.3.8) 0AFE07E5-04A2-337B-B8C0-1DDD4762C8C6 <75 74 12 11 7 5 4 3 1>
   79    0 0xffffff7f82bf4000 0x5f6000   0x5f6000   com.apple.kext.AMD6000Controller (1.3.8) D7C7BFBC-AA0F-3C96-BEC3-376C732002E5 <78 74 12 11 5 4 3 1>
  102    0 0xffffff7f82690000 0x45c000   0x45c000   com.apple.AMDRadeonX3000 (1.3.8) CB3CE8B0-A439-3290-A661-401AAB9E4FBE <76 74 12 7 5 4 3 1>
  109    0 0xffffff7f82bbf000 0x22000    0x22000    com.apple.kext.AMDFramebuffer (1.3.8) B95281B7-E056-3C9A-AD0A-43165EC111DF <78 74 12 11 7 5 4 3 1>

[Mieze]

Just ran kextstat from my system and do not see AppleMGPUPowerControl.kext loaded

That's absolutely correct, but why do you expect it to be present?

What I found interesting on my system is that AppleIntelFramebufferCapri is loaded.  Is this normal on a system with only a discrete GPU?

Yes, of course because it resides inside the CPU.

 

Mieze

[passmaster16]

That's absolutely correct, but why do you expect it to be present?

 

I didn't necessarily expect it to be there.  Was just thinking that if my machine only has an AMD discrete GPU, this kext should be loaded.  The fact that it isn't loaded validates your theory that this kext is necessary for wake to work properly for non-IGPU systems.

[Mieze]

I didn't necessarily expect it to be there.  Was just thinking that if my machine only has an AMD discrete GPU, this kext should be loaded.  The fact that it isn't loaded validates your theory that this kext is necessary for wake to work properly for non-IGPU systems.

This kext is a driver for a hardware device named GCON which is only present in MacPro6,1.

 

Mieze 

[Vlada.]

Yes and no, because the removal of the sensor properties is only a result of the fact that Apple has changed the way graphics power management works. In Yosemite and before every GPU used to handle PM on its own but now Apple has implemented a master-slave architecture where one driver acts as the master, also controlling the secondary GPU. With regard to iMacs this seems to be the onboard graphics driver, for the 2013 Mac Pro it's  AppleMGPUPowerControl.kext which controls PM for both AMD GPUs.

 

Mieze

 

Hm, that’s interesting. Could be that the problem is in the order?

 

Wake is working when IGPU is set as first (master) and AMD GPU as second (slave), and doesn’t work in the vice versa situation. Which parameter defines who is master and who slave? Do you know that?

 

And why that master-slave architecture doesn’t affect NVIDIA cards, but only AMD cards and if I'm correct, only those which depends from AMDRadeonX3000 & 4000 kexts?

[Mieze]

 

Hm, that’s interesting. Could be that the problem is in the order?

 

Wake is working when IGPU is set as first (master) and AMD GPU as second (slave), and doesn’t work in the vice versa situation. Which parameter defines who is master and who slave? Do you know that?

 

And why that master-slave architecture doesn’t affect NVIDIA cards, but only AMD cards and if I'm correct, only those which depends from AMDRadeonX3000 & 4000 kexts?

 

 

I don't know exactly which parameter defines the master-slave status of the GPUs but it might be the system definition which assigns the master role on recent iMacs to the IGPU and to device GCON on the 2013 Mac Pro. My research also indicates that NVIDIA GPUs seem to be excluded from this scheme but I must admit that I'm just beginning to understand the new graphics power management architecture.

 

With regard to Apple's motivation for this design decision I can only assume that it has to do with the power consumption of recent AMD GPUs and the form factor of the Mac Pro and iMacs. Taking into account how small these machines are and how much heat the AMD GPU dissipates under load it becomes clear they are on-the-edge-designs which need a more sophisticated power management architecture than traditional machines.

 

Mieze

[passmaster16]

So do we know how the old Mac Pros with physical AMD PCI-e cards handle power management on 10.11?  I actually have an oMP running 10.10 with an AMD Radeon 6870.  Problem is it's an old 1,1 machine so I have to use a modified boot.efi to get around the 32-bit firmware problem which is a bit of a pain otherwise I'd just put 10.11 on it just to see what it does.

[passmaster16]

I know that others have already mentioned this but you can see from the attached screen cap that there is no IGPU recognized on this Vaio laptop and it still has the wake issue.

[Slice]

And why that master-slave architecture doesn’t affect NVIDIA cards, but only AMD cards and if I'm correct, only those which depends from AMDRadeonX3000 & 4000 kexts?

Nvidia has GPUPM Management as well as native AMD cards on real MAC.

Our AMD has no it.

 

What is the role of AppleMCCSControl kext? It is loaded and it has dependency on SMC in ElCapitan unlike Yosemite.

[Mieze]

 

What is the role of AppleMCCSControl kext? It is loaded and it has dependency on SMC in ElCapitan unlike Yosemite.

I think it is for backlight control because it binds to device PNLF:

        Device (PNLF)
        {
            Name (_ADR, 0x00)  // _ADR: Address
            Name (_HID, EisaId ("APP0002"))  // _HID: Hardware ID
            Name (_CID, "backlight")  // _CID: Compatible ID
            Name (_UID, 0x0A)  // _UID: Unique ID
            Name (_STA, 0x0B)  // _STA: Status
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                Store (Package (0x04)
                    {
                        "refnum", 
                        0x00, 
                        "type", 
                        0x49324300
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }
        }

Adding these lines of code to your DSDT the backlight control can be faked, at least in a way to make the kext load, but of course it won't be functional.

 

Mieze

[MattsCreative]

you all still having this issue i hope you fix it soon i still have no issues on 10.11.2 good luck

[Mieze]

 

What is the role of this other device?

Device (SLPB)
        {
            Name (_HID, EisaId ("PNP0C0E"))
            Name (_STA, 0x0B)
        }

It's the Sleep Button. Please see section 4.8.2.2.2.2 of the ACPI 5.0 specification for a detailed description. You can download a copy using this link: http://www.acpi.info/DOWNLOADS/ACPIspec50.pdf

 

Mieze

[buoo]

Too late, I had no time to delete stupid question, thank you Meize

[FranticJohny]

Like others, my system wakes with CSM=on (UEFI boot). With CSM=off I have black screen. iGPU is set as primary. So why is CSM affecting the waking process? Maybe the sequence upon wake is different with CSM=off? So AMD is the first one, but the drivers aspect iGPU to be the first one?

[Slice]

Like others, my system wakes with CSM=on (UEFI boot). With CSM=off I have black screen. iGPU is set as primary. So why is CSM affecting the waking process? Maybe the sequence upon wake is different with CSM=off? So AMD is the first one, but the drivers aspect iGPU to be the first one?

Yes, it may depend because in my case I have no Intel GOP driver. Clover can't output to Intel VGA if booted in UEFI mode.

When wake did occur there may be BIOS sequence on graphics init. I am not sure.

I have no success with CSM=on and with legacy Clover.

[Mieze]

Just in case someone is still looking for a method to disable certain hardware components of the chipset completely, here is the solution I found.

 

You can use register FD Function Disable found at memory address 0x3418 of the 6/7/8/9 chipsets to disable a device so that it won't be recognized by OS X anymore as the bits disable the device's PCI config space. I used these lines of code to disable EHCI 1 & 2. First you might need to define the corresponding bits of the register in Field RCRB, in my case I added EH1D and EH2D. Caution! Double check what you are doing. Disabling the wrong device might render you system unable to boot OS X.

        OperationRegion (RCRB, SystemMemory, SRCB, 0x4000)
        Field (RCRB, DWordAcc, Lock, Preserve)
        {
                    Offset (0x1000), 
                    Offset (0x2330), 
            AFEA,   32, 
            AFED,   32, 
            AFES,   16, 
            AFER,   16, 
                    Offset (0x3000), 
                    Offset (0x3400), 
                ,   2, 
            CMUE,   1, 
                    Offset (0x3404), 
            HPAS,   2, 
                ,   5, 
            HPAE,   1, 
                    Offset (0x3418), 
                ,   1, 
            ADSD,   1, 
            SATD,   1, 
            SMBD,   1, 
            HDAD,   1, 
                ,   8, 
            EH2D,   1, 
                ,   1, 
            EH1D,   1, 
            RP1D,   1, 
            RP2D,   1, 
            RP3D,   1, 
            RP4D,   1, 
            RP5D,   1, 
            RP6D,   1, 
            RP7D,   1, 
            RP8D,   1, 
                    Offset (0x359C), 
            UP0D,   1, 
            UP1D,   1, 
            UP2D,   1, 
            UP3D,   1, 
            UP4D,   1, 
            UP5D,   1, 
            UP6D,   1, 
            UP7D,   1, 
            UP8D,   1, 
            UP9D,   1, 
            UPAD,   1, 
            UPBD,   1, 
            UPCD,   1, 
            UPDD,   1, 
                ,   1, 
                    Offset (0x359E)
        }

Next, find method _INI under Scope (_SB.PCI) and add the code to disable the devices:

    Scope (_SB.PCI0)
    {
        Method (_INI, 0, NotSerialized)
        {
            Store (0x07D0, OSYS)
            If (CondRefOf (\_OSI, Local0))
            {
                If (_OSI ("Linux"))
                {
                    Store (0x03E8, OSYS)
                }

                If (_OSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Darwin"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }

                If (_OSI ("Windows 2001.1"))
                {
                    Store (0x07D3, OSYS)
                }

                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }

                If (_OSI ("Windows 2009"))
                {
                    Store (0x07D9, OSYS)
                }

                If (_OSI ("Windows 2012"))
                {
                    Store (0x07DC, OSYS)
                }
            }

            Store (One, EH1D)    //<--- This disables EHCI#1.
            Store (One, EH2D)    //<--- This disables EHCI#2.
        }

Mieze

[Slice]

I think I can implement "DisableFunction" into Clover after understanding addresses.

[Vlada.]

Yes, it may depend because in my case I have no Intel GOP driver. Clover can't output to Intel VGA if booted in UEFI mode.

When wake did occur there may be BIOS sequence on graphics init. I am not sure.

I have no success with CSM=on and with legacy Clover.

 

OK, since you mention this I’d like to clarify a few things… I’m not sure for that Intel GOP driver that you mentioned, but I know that my R9 270X have a GOP partition inside the firmware. Also, I am using a Clover legacy boot variation, although I have UEFI BIOS, but because of certain Clover boot option graphics issues, I don't like to use it. 

 

So in short, the wake is working in my case under the Clover legacy boot variation, but only when the IGPU is set in BIOS as a first device. And again, I'm using SMBIOS for MP6,1.

[Monq]

I don't understand. I must set my IGPU as primary and then change the physical switch of my ATI card to legacy instead of UEFI?

[Slice]

I don't understand. I must set my IGPU as primary and then change the physical switch of my ATI card to legacy instead of UEFI?

You can try this or else but it is not guaranted you'll get a success.

[Monq]

You can try this or else but it is not guaranted you'll get a success.

If I choose my IGPU as primary the screen never turns on, I guess the GPU is powered off or whatever.

 

If I change the hardware switch of my GPU to legacy, no success either.

[telequillo]

Can someone confirm me that with "sudo pmset -a hibernatemode 25" it works?

I actually use more hibernation than sleep, as long as I can see all my work as I left it the day before it is ok!

I tried 2 times hibernating with this pmset setting and It wouldn't start afterwards (i had to force a "discard hibernation" (or something like this) from Clover). I might be missing something cause all I read in the thread is about sleeping not hibernating!