Jump to content

No graphics / USB / Audio after wake

anor4k

By anor4k,
in OSx86 10.11 (El Capitan)

 Share
586 posts in this topic

Recommended Posts

Mieze
Mieze
Posted
Posted

I keep an idea that ElCapitan more careful testing the card and doesn't create a procedure for PowerManagement.

Just a question. Is there anybody knows where is "ATIFramebufferNI::setPowerState" located? I have not find a kext with such strings. (searching with disassembler).

The error message is generated by the kernel itself. The class ATIFramebufferNI can be found in the AMDx000Controller.kext but this doesn't necessarily mean that the problem is located there because power state transitions are performed bottom up, e.g. a parent can only complete a power state change when all its children already completed the state change successfully.

 

I'm using system definition iMac15,1, which closely corresponds to my hardware and compared the original Retina iMac's IORegistry with mine and found one big difference: graphics device policy isn't running properly. I'm getting these error messages in /var/log/displaypolicyd.log.

u>32762851 /usr/libexec/displaypolicyd: Version: V1.0 starting [0]
u>32763041 /usr/libexec/displaypolicyd: Started at Wed Nov  4 23:13:11 2015
u>69084518 ERROR: AGDC suppport not present in system
u>69084584 ERROR: Policy engine instance init failed

As AppleGraphicsDevicePolicy.kext is a plugin of AppleGraphicsControl.kext, I assume that the root of the problem can be found there. It looks like graphics power management is always directed by the primary display device and depends on AppleGraphicsControl including the plugins to work properly. For the IGPU this seems to be the case because there is an AppleGraphicsDeviceControlClient attached to it, but in the AMD card's subtree there is no such entry.

 

post-983225-0-85781400-1446724293_thumb.png

 

In the original Retina iMac's IORegistry, I found the following entries which show that there should be an AppleGraphicsDeviceControlClient attached to the card.

    | | | |   | +-o AtiDeviceControl  <class AtiDeviceControl, id 0x100000389, registered, matched, active, busy 0 (0 ms), retain 8>
    | | | |   | | | {
    | | | |   | | |   "IOUserClientClass" = "AppleGraphicsDeviceControlClient"
    | | | |   | | | }
    | | | |   | | | 
    | | | |   | | +-o AppleGraphicsDeviceControlClient  <class AppleGraphicsDeviceControlClient, id 0x1000003d9, !registered, !matched, active, busy 0, retain 5>
    | | | |   | |     {
    | | | |   | |       "IOUserClientCreator" = "pid 58, displaypolicyd"
    | | | |   | |     }

Mieze

  • Like 3
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

I am using definitions of iMac12,2 having HD6670 (Turks) in my case and HD6970M (Turks) in native mac.

So I used FakeID=0x6740 and got graphics almost fully working. AGPM attached as the profile iMac12,2 assumed this Radeon.

 

But no DeviceControl

"AppleGraphicsDeviceControlClient"=0

Internal identification? Sensors absent? SMC absent?

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted (edited)

I am using definitions of iMac12,2 having HD6670 (Turks) in my case and HD6970M (Turks) in native mac.

So I used FakeID=0x6740 and got graphics almost fully working. AGPM attached as the profile iMac12,2 assumed this Radeon.

 

But no DeviceControl

"AppleGraphicsDeviceControlClient"=0

Internal identification? Sensors absent? SMC absent?

 

The information I posted applies to the Radeon 7000 cards in recent Mac models, Radeon 6000 support in older machines seems to be different. I have an original iMac12,1 and can confirm that graphics power management is implemented in a different way on these machines. The absence of Graphics Device Control is quite normal. Please take a look at AppleGraphicsDevicePolicy.kext and it's Info.plist. It's a plugin of AppleGraphicsControl.kext. There you will find configurations only for newer Mac models.

 

I also tried to fake the ALS in the DSDT and OS X seems to recognize it but unfortunately without any influence on power management. But wait, the SMC might also play a role as I found these kernel error messages in system.log. 

Nov  4 23:13:11 localhost kernel[0]: AppleLMUController::smcGetKeyInfo Error: received error 0x84 when getting key info for 'RMde'
Nov  4 23:13:11 localhost kernel[0]: AppleLMUController::start Error: SMC mode check failed

Any idea?

 

Mieze

Edited by Mieze
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Native iMac12,2 has this SMC key

  RMde  [char]  (bytes 41)

so you may insert into FakeSMC.info.plist lines like

					<key>RMde</key>
					<array>
						<string>char</string>
						<data>
						Aw==
						</data>
					</array>

with some data like 0x41

Also set debug=true to see what keys system asked.

 

But if ElCapitan asked through MEMIO/SMRAM then we can't see and set SMC keys.

  • Like 1
Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

@Slice: Ok, editing the Info.plist resolved one error but the other one still remains.

Nov  5 16:44:45 localhost kernel[0]: AppleLMUController::checkSMCMode Error: SMC is in '' mode, not 'A' mode
Nov  5 16:44:45 localhost kernel[0]: AppleLMUController::start Error: SMC mode check failed

...and still no progress with regard to graphics device policy. Maybe I should change the system definition to MacPro6,1 as this machine doesn't have an ALS?

 

Mieze

  • Like 1
Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Ok, the Fake-ALS is working now! 

 

post-983225-0-31709300-1446761308_thumb.png

 

In order to make it work I had to add the following lines of code to the DSDT:

            Scope (_SB.PCI0.LPCB)
            {
                Device (ALS0)
                {
                    Name (_HID, "ACPI0008")
                    Name (_CID, "smc-als")
                    Name (BUFF, Buffer (0x02) {})
                    CreateByteField (BUFF, Zero, OB0)
                    CreateByteField (BUFF, One, OB1)
                    CreateWordField (BUFF, Zero, ALSI)
                    Method (_STA, 0, NotSerialized)
                    {
                        Return (0x0F)
                    }

                    Method (_ALI, 0, NotSerialized)
                    {
                        Store (0x0A, OB0)
                        Store (Zero, OB1)
                        Store (ALSI, Local0)
                        Return (Local0)
                    }

                    Name (_ALR, Package (0x05)
                    {
                        Package (0x02)
                        {
                            0x0A, 
                            Zero
                        }, 

                        Package (0x02)
                        {
                            0x14, 
                            0x0A
                        }, 

                        Package (0x02)
                        {
                            0x32, 
                            0x50
                        }, 

                        Package (0x02)
                        {
                            0x5A, 
                            0x012C
                        }, 

                        Package (0x02)
                        {
                            0x64, 
                            0x03E8
                        }
                    })
                }
            }

and 5 keys to FakeSMC's Info.plist: 'RMde', 'ALV0', 'ALRV', 'ALI0' and 'MSLD'. I took the values from the iMac15,1's SMC key dump. This is the code: 

					<key>RMde</key>
					<array>
						<string>char</string>
						<data>QQ==</data>
					</array>
					<key>ALV0</key>
					<array>
						<string>{alv</string>
						<data>ARAGdQEgALYO4A==</data>
					</array>
					<key>ALRV</key>
					<array>
						<string>ui16</string>
						<data>AAE=</data>
					</array>
					<key>ALI0</key>
					<array>
						<string>{ali</string>
						<data>BwECAA==</data>
					</array>
					<key>MSLD</key>
					<array>
						<string>ui8 </string>
						<data>AA==</data>
					</array>

Unfortunately graphics device policy still isn't working.  :(

 

Mieze

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

:thumbsup_anim:

 

 

 

Unfortunately graphics device policy still isn't working.   :(

:(


I have a news.

I updated system to 15C31f.

Switched SMBIOS profile to MacPro5,1. Some other changes in config. All works as before.

Sleep. Wake and few seconds after it reboots. I never had reboots before.

Looks like setPowerState() now works as restart.

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

The panic is due to Intel graphics

      Kernel Extensions in backtrace:
         com.apple.iokit.IOGraphicsFamily(2.4.1)[48AC8EA9-BD3C-3FDC-908D-09850215AA32]@0xffffff7fa3889000->0xffffff7fa38c3fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[CFBB74E9-7C2F-396B-866A-6E2F60B27B51]@0xffffff7fa2d2d000
         com.apple.driver.AppleIntelSNBGraphicsFB(10.0)[9F282D87-6169-3087-BBC7-0106B4FE1457]@0xffffff7fa3fde000->0xffffff7fa400bfff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[CBAE26D8-0ACB-3C1F-8347-FDCA67EC40B3]@0xffffff7fa31e9000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[CFBB74E9-7C2F-396B-866A-6E2F60B27B51]@0xffffff7fa2d2d000
            dependency: com.apple.iokit.IOGraphicsFamily(2.4.1)[48AC8EA9-BD3C-3FDC-908D-09850215AA32]@0xffffff7fa3889000
Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

system.log

Nov  6 07:42:29 iMac kernel[0] <Notice>: AppleLPC::notifyPlatformASPM - registering with plugin with ASPM Support false

 

That's Active State Power Management (ASPM), a PCIe technique to reduce power consumption while keeping a device operational, which may cause trouble with certain PCIe devices when enabled. I've got this message in my kernel logs since 10.11 too.

 

The panic is due to Intel graphics

      Kernel Extensions in backtrace:
         com.apple.iokit.IOGraphicsFamily(2.4.1)[48AC8EA9-BD3C-3FDC-908D-09850215AA32]@0xffffff7fa3889000->0xffffff7fa38c3fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[CFBB74E9-7C2F-396B-866A-6E2F60B27B51]@0xffffff7fa2d2d000
         com.apple.driver.AppleIntelSNBGraphicsFB(10.0)[9F282D87-6169-3087-BBC7-0106B4FE1457]@0xffffff7fa3fde000->0xffffff7fa400bfff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[CBAE26D8-0ACB-3C1F-8347-FDCA67EC40B3]@0xffffff7fa31e9000
            dependency: com.apple.iokit.IOPCIFamily(2.9)[CFBB74E9-7C2F-396B-866A-6E2F60B27B51]@0xffffff7fa2d2d000
            dependency: com.apple.iokit.IOGraphicsFamily(2.4.1)[48AC8EA9-BD3C-3FDC-908D-09850215AA32]@0xffffff7fa3889000

Looks like things are getting worse, not better.  :(

 

Mieze

Link to comment
Share on other sites
Vlada.
Vlada.
Posted
Posted

I notice that Apple removes sensor-properties line from AMDRadeonX4000.kext under El Capitan. Those lines was being related to what exactly? Does anyone have an idea why Apple eliminated those lines?

 
Just a thought… Considering that USB is also a part of this problem, I assume that there will be no simple solution for this issue. It seems like additional kext is needed for that or something?
 
post-458468-0-58058100-1446168361_thumb.png

 

Link to comment
Share on other sites
URBANsUNITED
URBANsUNITED
Posted
Posted

 

I notice that Apple removes sensor-properties line from AMDRadeonX4000.kext under El Capitan. Those lines was being related to what exactly? Does anyone have an idea why Apple eliminated those lines?

 
Just a thought… Considering that USB is also a part of this problem, I assume that there will be no simple solution for this issue. It seems like additional kext is needed for that or something?
 
 

 

 

That's not the only difference...

 

http://www.tonymacx86.com/graphics/167370-amds-radeon-370-380-390-x-7.html#post1074216

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Just a thought… Considering that USB is also a part of this problem, I assume that there will be no simple solution for this issue. It seems like additional kext is needed for that or something?

No, it's not a part of this problem, it's a separate one because there are several problems with regard to power management:

  1. Apple has reworked USB support completely which causes trouble on some machines.
  2. Old style graphics power management (pre 2012 Macs) for AMD GPUs has been changed but at least a few hackintosh users reported success with their systems.
  3. New style graphics power management (all Macs since 2012) for AMD GPUs seems to depend on AppleGraphicsControl.kext and its plugins and we still haven't figured out how to make it work.

Mieze

Link to comment
Share on other sites
Monq
Monq
Posted
Posted

Hello again and sorry if this is unrelated.

 

I noticed that, starting with El Capitan, the graphical performance of the system degrades gradually over time. After using the computer for around six hours, window scrolling and resizing starts stuttering. Then, music and video playback stutter too.

 

I tried to log out and back in and to kill the WindowServer, and nothing helped, only a reboot.

 

I did not see anything especially suspicious in the Activity Monitor.

 

Is this related to the GPU? In any case, can you tell me how could I debug it?

Link to comment
Share on other sites
Vlada.
Vlada.
Posted
Posted

No, it's not a part of this problem, it's a separate one because there are several problems with regard to power management:

  1. Apple has reworked USB support completely which causes trouble on some machines.
  2. Old style graphics power management (pre 2012 Macs) for AMD GPUs has been changed but at least a few hackintosh users reported success with their systems.
  3. New style graphics power management (all Macs since 2012) for AMD GPUs seems to depend on AppleGraphicsControl.kext and its plugins and we still haven't figured out how to make it work.

Mieze

 

Hmm... than how you explain the fact that I don't have USB problems when I remove AMDRadeonX4000.kext?! That way my computer is waking up properly and I have USB2 ports operational, but of course I don't have graphics acceleration. 

 

Basically I only have expected problems with USB3 ports, because my motherboard is using etron chipset, which was never been fully supported by Apple, but it seems that USB2 is working properly, except in this wake up situation where GPU acceleration is enabled. 

 

I don’t know, maybe I’m wrong, but in this case it seems to me like that USB and GPU is actually one big problem, or at least related one!

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

.. Apple has switchable graphics, maybe the GMUX device is missing?

Obviously will not work, but maybe help drivers on iMac/MacBook XXX smbioses...

Device (GMUX)
            {
                Name (_HID, EisaId ("APP000B"))
                Name (_CID, "gmux")
                Name (_STA, 0x0B)
                Name (_CRS, ResourceTemplate ()
                {
                    IO (Decode16,
                        0x0700,             // Range Minimum
                        0x07FF,             // Range Maximum
                        0x01,               // Alignment
                        0xFF,               // Length
                        )
                })
                Name (_PRW, Package (0x02)
                {
                    0x16, 
                    0x03
                })
            }
Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Hmm... than how you explain the fact that I don't have USB problems when I remove AMDRadeonX4000.kext?! That way my computer is waking up properly and I have USB2 ports operational, but of course I don't have graphics acceleration. 

 

Basically I only have expected problems with USB3 ports, because my motherboard is using etron chipset, which was never been fully supported by Apple, but it seems that USB2 is working properly, except in this wake up situation where GPU acceleration is enabled. 

 

I don’t know, maybe I’m wrong, but in this case it seems to me like that USB and GPU is actually one big problem, or at least related one!

 

I already explained why. Please see http://www.insanelymac.com/forum/topic/308025-no-graphics-usb-audio-after-wake/?p=2185579 for a detailed description. In a word, it's because order matters. When the AMD driver hangs, the thread which is used by the kernel to call a driver's setPowerState() function is dead and this prevents power state transitions of any other driver too.

 

Mieze

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

I made an attempt to improve device identification with rehabman's FakePCIID.kext  with personalities like

		<key>FakeRadeon</key>
		<dict>
			<key>CFBundleIdentifier</key>
			<string>org.rehabman.driver.FakePCIID</string>
			<key>FakeProperties</key>
			<dict>
				<key>RM,device-id</key>
				<data>QGcAAA==</data>
				<key>RM,subsystem-id</key>
				<data>QGcAAA==</data>
				<key>RM,subsystem-vendor-id</key>
				<data>axAAAA==</data>
			</dict>
			<key>IOClass</key>
			<string>FakePCIID</string>
			<key>IOMatchCategory</key>
			<string>FakePCIID</string>
			<key>IOPCIClassMatch</key>
			<string>0x03000000&0xff000000</string>
			<key>IOPCIPrimaryMatch</key>
			<string>0x67401002 0x67581002 </string>
			<key>IOProbeScore</key>
			<integer>9001</integer>
			<key>IOProviderClass</key>
			<string>IOPCIDevice</string>
		</dict>

The attempt failed. When switch graphics on the computer just rebooted. Something wrong here.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

 

.. Apple has switchable graphics, maybe the GMUX device is missing?

Obviously will not work, but maybe help drivers on iMac/MacBook XXX smbioses...

Device (GMUX)
            {
                Name (_HID, EisaId ("APP000B"))
                Name (_CID, "gmux")
                Name (_STA, 0x0B)
                Name (_CRS, ResourceTemplate ()
                {
                    IO (Decode16,
                        0x0700,             // Range Minimum
                        0x07FF,             // Range Maximum
                        0x01,               // Alignment
                        0xFF,               // Length
                        )
                })
                Name (_PRW, Package (0x02)
                {
                    0x16, 
                    0x03
                })
            }

Thank you for the idea but the device present only on MacBook not on Imac.

I see in my DSDT there is a method

            Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output Switching
            {
                Store (And (Arg0, 0x07), DSEN) /* \DSEN */
                If (LEqual (And (Arg0, 0x03), Zero))
                {
                    If (CondRefOf (HDOS))
                    {
                        HDOS ()
                    }
                }
            }

But HDOS() is a fake method. It is not implemented. We should do this?

  • Like 1
Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

Thank you for the idea but the device present only on MacBook not on Imac.

Really? I was thinking that at least machine like this one:http://www.apple.com/shop/product/G0MS5LL/A/refurbished-27-inch-imac-34ghz-quad-core-Intel-Core-i7has switchable gpus because of the one embedded in the cpu die. But if not... too bad by Apple..

 

But HDOS() is a fake method. It is not implemented. We should do this?

Me too I have something like that in the DSDT, but the rest of the code is inside an ssdt table.

The idea was a thought on what happen when a PC with switchable graphics goes to sleep and wake... I think it switch to the Intel one, but not idea..surely there is a precise dynamic.

The reason for the problem may depend on something in real Mac exist, but not on Hack (Ok problem comes with 10.11, but yes..is a new OS).. I'm making only suggestions.

 

Look what a dev has done for linux (to run linux on real Mac with switchable graphics):http://lxr.free-electrons.com/source/drivers/platform/x86/apple-gmux.c 

 

Guys if attached via HDMI can wake (maybe also un-plug/re-plug the monitor)?

Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

No desktop PC has switchable graphics (that I know of). Apple has both GPUs enabled in the iMac, but the IGPU is "hidden" (by using a platform ID with no connectors, which makes it disappear from System Information/Graphics). The iMac doesn't have a GMUX device, and doesn't have switchable graphics (though it does actually use the IGPU, mainly for QuickSync H.264 encoding with AirPlay/FaceTime).

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Although I haven't found a solution for the wakeup issue yet, at least I made some progress with AppleGraphicsDeviceControll. In order to make it work you have to patch AMD7000Controller.kext's Info.plist and change 'CFG_USE_AGDC' from false to true.

<key>aty_config</key>
<dict>
    <key>CFG_USE_AGDC</key>
    <true/>

Unfortunately this doesn't solve the wakeup problem, but at lest it prevents the framebuffer from reenumerating all attached displays when the screen goes online again.

 

I also observed that the primary display always gets the "AAPL,boot-display" property, on real Macs with IPGU and/or discrete GPU. This is also true for an hackintosh with onboard graphics but on an hackintosh with an AMD GPU as the primary display this property is missing, no matter what you selected in BIOS setup. You might think that this is just a cosmetic issue but I think it's not. Searching through the source code of IOGraphics.kext that Apple published, I found these lines of code in IOBootFramebuffer.cpp:

IOService * IOBootFramebuffer::probe(   IOService *     provider,
                                      SInt32 *  score )
{
    PE_Video            bootDisplay;
    IOService *         ret = 0;
    IOReturn            err;

    do
    {
        if (!provider->getProperty("AAPL,boot-display"))
            continue;

        err = getPlatform()->getConsoleInfo( &bootDisplay );
        if (err || (bootDisplay.v_baseAddr == 0))
            continue;

        if (false == super::probe(provider, score))
            continue;

        *score          = 0;
        ret = this;                     // Success
    }
    while (false);

    return (ret);
}

and

bool IOBootFramebuffer::isConsoleDevice( void )
{
    return ((0 != getProvider()->getProperty("AAPL,boot-display")));
}

It looks like that OS X fails to recognize an AMD GPU in an hackintosh as the primary display adapter. Maybe this is an explanation to the fact that wakeup works when onboard graphics is used as the primary GPU?

 

@Slice: Do you know how OS X detects the primary display adapter?

 

Mieze

  • Like 2
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...