Jump to content

Tracing back the AMD GPU wakeup issue to its origin


365 posts in this topic

Recommended Posts

  • 2 weeks later...
  • 4 months later...
On 10/23/2017 at 10:04 PM, Slice said:

@Mieze

It's fantastic work!

Confirm working with my Radeon 6450 in Sierra.

I just made this patch as SSDT

SSDT-AMD.aml.zip

 

My Asus P5Q-Pro MB doesn't have integrated GPU, I have a Radeon HD 6870. Clover inserts device GFX0 and Gibba FB at the device path as shown by ioreg.

 

Accordingly, I have modified the SSDT-AMD.aml as in the snippet below (best guess after gathering information from several related threads). After making this change I forced sleep from the Apple menu. The machine seemed to have gone to sleep but immediately woke up (which is likely a separate issue). Important thing is that the display came back up which suggested that SSDT seems to be working.

 

However, when the machine went to sleep on its own after 30mins of inactivity, it did not come back on. Fans etc were running, but no display. I hit some keys and plugged/unplugged a USB drive, but no response. Could not even ssh into the machine from another machine, so had to do a hard reboot.

 

My question is if my SSDT edit is correct, or should the device path be _SB_.PCI0.P0P2.PEGP, or something else? Any pointers no the machine being unresponsive after auto sleep are much appreciated!

 

DefinitionBlock ("", "SSDT", 2, "Apple", "Radeon", 0x00003000)
{
    External (_SB_.PCI0.P0P2.GFX0, DeviceObj)    // (from opcode)

    Scope (\_SB.PCI0.P0P2.GFX0)
    {
        OperationRegion (PCIB, PCI_Config, Zero, 0x0100)
        Field (PCIB, AnyAcc, NoLock, Preserve)
        {
            Offset (0x10), 
            BAR0,   32, 
            BAR1,   32, 
            BAR2,   64, 
            BAR4,   32, 
            BAR5,   32
        }

 

 

IOReg Gibba.png

Edited by firefox-bin
  • 1 month later...

@Mieze

Would you please provide instructions on how to dump BARS, the  GPUs control register space, and how to change them.

This is my problem:
 

https://www.insanelymac.com/forum/topic/334965-amd-firepro-w4100-high-cinebench-r15-opengl-if-first-run-under-windows/


I believe that your generic method would be helpful in resolving my problem. The intention is to compare the Gpu's registers (BARs etc) between a soft Windows reboot, and a cold High Sierra boot. Then to patch the DSDT.

I've read the thread and am surprised that no one has inquired about the tools that you have used.

Thank you.
 

It may be different tools.

RW-Everything in Windows.

RadeonDump in macOS.

Or somehow ACPI debugging.

You also may write your own kext for macOS to dump PCI and MMIO registers into IOLog in macOS.

You may modify Clover sources to dump PCI and MMIO registers into boot.log before any OS.

Thank you Slice.

I will examine RadeonDump; it's included in DarwinDumper.

I know that this is off-topic.

At the moment I am using Windows 10 as a glorified graphics microcode loader (GuC). Is there anyway to capture the microcode that is loaded by Windows for the AMD Firepro W4100; then use Clover or macOS to write the microcode to the W4100?

The loading of the microcode is the key to unlocking the full 3D performance of the W4100.

  • 2 weeks later...
  • 2 months later...

Since I replaced my my R9 270X with an RX570 a half year ago, I noticed that this strange kernel message was showing up after wakeup from sleep:

kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms
kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms

Although it doesn't seem to do much harm to the system, DisplayPort audio used to work well anyway, I'm curious like all cats ;) and decided to investigate the issue. As I'm using system definition iMac18,3 it was the most obvious step to take a look at the IOReg dump of an original Apple machine of that type and compared it with mine. Checking device HDEF, I noticed that the iMac18,3 doesn't have the "hda-gfx" property on that device anymore but instead of it a "No-hda-gfx" property so that I decided to edit my HDEF's method _DSM in order to adopt this change and it made the error message after wakeup disappear.

            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg2, Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                           
                    })
                }

                Return (Package (0x06)
                {
                    "No-hda-gfx", 
                    Buffer (0x08)
                    {
                         0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 
                    }, 

                    "layout-id", 
                    Buffer (0x04)
                    {
                         0x01, 0x00, 0x00, 0x00                         
                    }, 

                    "PinConfigurations", 
                    Buffer (Zero) {}
                })
            }

Mieze

Edited by Mieze
On 8/1/2018 at 10:10 AM, Slice said:

It may be different tools.

RW-Everything in Windows.

RadeonDump in macOS.

Or somehow ACPI debugging.

You also may write your own kext for macOS to dump PCI and MMIO registers into IOLog in macOS.

You may modify Clover sources to dump PCI and MMIO registers into boot.log before any OS.

I just saw your post and wanted to share this piece of code which I used to dump the GPU's register space in order to investigate the wakeup issue. It adds the dump as property GBUF to the GPU's IORegistry entry while the system is booting so that it my be retrieved using IORegistryExplorer later. Have fun!

                Device (PEGP)
                {
                    Name (_ADR, Zero)  // _ADR: Address
                    OperationRegion (PCIB, PCI_Config, Zero, 0x0100)
                    Field (PCIB, AnyAcc, NoLock, Preserve)
                    {
                        Offset (0x04), 
                        CMDR,   16, 
                        Offset (0x10), 
                        BAR0,   32, 
                        BAR1,   32, 
                        BAR2,   64
                    }

                    OperationRegion (GREG, SystemMemory, And (BAR2, 0xFFFFFFFFFFFFFFF0), 0x8000)
                    Field (GREG, AnyAcc, NoLock, Preserve)
                    {
                        Offset (0x681C), 
                        SBS0,   32
                    }

                    OperationRegion (GREF, SystemMemory, And (BAR2, 0xFFFFFFFFFFFFFFF0), 0x00010000)
                    Field (GREF, AnyAcc, NoLock, Preserve)
                    {
                        GSRC,   524288
                    }

                    Name (GBUF, Buffer (0x00010000) {})
                    Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                    {
                        Store (Or (CMDR, 0x02), CMDR)
                        Sleep (One)
                        CopyObject (GSRC, GBUF)
                        Store (Package (0x02)
                            {
                                "GBUF", 
                                GBUF
                            }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }
                }

Mieze

On 11/13/2018 at 12:11 PM, Mieze said:

Since I replaced my my R9 270X with an RX570 a half year ago, I noticed that this strange kernel message was showing up after wakeup from sleep:


kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms
kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms

Although it doesn't seem to do much harm to the system, DisplayPort audio used to work well anyway, I'm curious like all cats ;) and decided to investigate the issue. As I'm using system definition iMac18,3 it was the most obvious step to take a look at the IOReg dump of an original Apple machine of that type and compared it with mine. Checking device HDEF, I noticed that the iMac18,3 doesn't have the "hda-gfx" property on that device anymore but instead of it a "No-hda-gfx" property so that I decided to edit my HDEF's method _DSM in order to adopt this change and it made the error message after wakeup disappear.


            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg2, Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                           
                    })
                }

                Return (Package (0x06)
                {
                    "No-hda-gfx", 
                    Buffer (0x08)
                    {
                         0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 
                    }, 

                    "layout-id", 
                    Buffer (0x04)
                    {
                         0x01, 0x00, 0x00, 0x00                         
                    }, 

                    "PinConfigurations", 
                    Buffer (Zero) {}
                })
            }

Mieze

It can be done by clover's config.plist Device->Properties

	<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)</key>
	<dict>
		<key>No-hda-gfx</key>
		<data>
		b25ib2FyZC0xAA==
		</data>

Yes?

×
×
  • Create New...