Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About Fl0r!an

  • Rank
    InsanelyMac Protégé
  1. Tracing back the AMD GPU wakeup issue to its origin

    Nice to see this issue finally being fully understood and solved! I've assumed that pre-OS initialization of the GPU was the culprit for quite a long time, but I never was able to prove/fix it (as documented in the other thread). Great work Mieze!
  2. This patch doesn't do more than preventing the dGPU from getting init'ed during boot phase (in a quite brutal way), so that solution is sadly not better than all other known ways (iGPU=Primary, 2nd "helper" GPU, unplugging the cable before booting, ...). Loading that BIOS with Clover won't work, as the GPU will already be init'ed by then.
  3. R9 Nano

    I don't think anyone has seen 5K with AMD graphics on a Hackintosh so far. Rominator/MacVidCards (@netkas.org) recently tested it with a RX 480 (maybe also R9 Nano), but it didn't work.
  4. R9 Nano

    Do you have any evidence for this? Just had a quick look, but I didn't find anything device specific except the assignment of the device name (e.g. "Baffin Unknown Prototype"). This looks purely cosmetic to me though, it's just a switch/case statement based on the device ID for setting up some strings.
  5. R9 Nano

    Great work! I've adapted your patch for Polaris 10 GPUs, details and benchmarks are here: Of course credits belong to you for figuring this out, changing a few more bytes wasn't difficult when you know where to look.
  6. I guess it depends on the specific UEFI implementation. On my Asus mainboard, CSM completely changes the behavior: When CSM is enabled (and set to legacy OpROM), the EFI will always initialize the graphics adapter, which is specified as "Primary" (even if no display is connected). And only this one, the other alternative won't show any pre-OS video output! Accordingly the system will only wake when iGPU is primary, no matter what is connected where. When CSM is disabled and MultiMonitor is enabled, the EFI will always init the GPU which has a monitor connected to it, no matter which one is primary. This means the dGPU won't get init'ed as long as no display is connected during boot time, thus sleep will work. So the EFI display driver seems to do something to the GPU, which the OS X drivers don't like at all. (Btw, did anyone ever try to use a Apple GOP EFI driver on a PC? The D700's in the nMP should be GOP...).
  7. I'm starting to think the iGPU is actually completely unrelated. Did a short experiment: Boot with iGPU = Primary, MultiMonitor = Disabled Display connected to dGPU on boot (didn't display anything), did wake as expected. Note: Had to do this with CSM enabled and legacy OpROM, otherwise my Radeon will start displaying at Clover boot screen and the system won't wake. On the next boot, the Primary GPU will be reset to "auto". Not sure if this is a BIOS bug?! Boot with iGPU = Primary, MultiMonitor = Enabled, CSM disabled Display connected to dGPU on boot (displays boot screen), did not wake. Display not connected to any port, system wakes. The iGPU was properly recognised in both cases in System Profiler -> Graphics. Boot with dGPU = Primary, MultiMonitor = Enabled, CSM disabled Display connected to dGPU on boot (displays boot screen), did not wake. Display not connected to any port, system wakes. The iGPU was not recognised in System Profiler, but OpenCL acceleration was functional (verified with Luxmark). Boot with dGPU = Primary, MultiMonitor = Disabled, CSM disabled Display connected to dGPU on boot (displays boot screen), did not wake. Display not connected to any port, system wakes. No iGPU at all (as expected). So my iGPU doesn't matter at all, as long as I prevent the UEFI from init'ing my dGPU (either with proper BIOS settings or pulling the cable). As soon as the EFI video is initialised on my Radeon dGPU, sleep/wake will be broken, even if I disconnect the cable during boot phase (e.g. after selecting my OS X drive in Clover). I also tried to unload the EFI video driver from the EFI shell, but that didn't fix sleep/wake either. Note: Tests were done on a Skylake system (6600K / Asus Z170M-Plus, R9 280, CSM disabled), so my Skylake iGPU will break sleep/wake, too, as soon as OS X uses it as display output. Using the Skylake iGPU just as OpenCL accelerator is fine though. Thoughts?
  8. Well, classic MacPros can wake with unflashed (=> legacy OpROM) Radeon GPUs. I also thought about the possibility that OS X might not like booting with UEFI GPU (-> so cMPs are unaffected), so I did the following experiment: Enter UEFI shell in Clover (AMD GPU primary) Disconnect and unload the UEFI AMD video driver Blindly exit UEFI shell and boot OS X Try to wake from sleep => same issue as always To prove it the other way around, one could boot OS X on a genuine Mac Pro with a stock PC GPU installed using Clover. Would be interesting to see if the MacPro still wakes properly. I'd test it myself, but my MacPro has a broken NVRAM, so I can't configure the boot drive...
  9. Okay, thanks for explanation! That HWREgister::Read-Function is actually quite short: I don't think anyone ever got that mentioned "panic on poweroff register access" (google doesn't reveal a single hit)? Which would mean this either never happens or that debug option is always disabled. So the AMD driver might get stuck within the IOLock thingy below while trying to access a register when the GPU still sleeps? Should be easy to prove that by altering the cmp-statement in line #7: Next wake attempt should produce an instant kernel panic instead of getting "just" stuck. Maybe the GPU just doesn't wake fast enough? Did anyone ever try adding a short IOSleep in one of the wakeup functions? Will have another look at this tomorrow... Have to sleep now, otherwise I'll wake up as bad as my Radeon. EDIT: One last thing, did anyone ever investigate the order in which all drivers/devices are woken up? Is this deterministic? Would be interesting to know if there's a different order on working setups (e.g. iGPU=Primary or genuine Mac) and non-working setups (Hackintosh with dGPU=Primary). EDIT2: Okay, changing the "jz" in line #8 to "jnz" didn't trigger the panic, so it's either not a "poweroff register access" or it gets stuck before.
  10. So I just put my Hackintosh (Sierra, R9 280) to sleep, forgetting that sleep/wake won't work with the Radeon installed (was using a Nvidia GPU for the last months). When I came back, the system had rebooted "because of an error" and presented a "Sleep Wake Failure" dialogue. Never saw such a thing before, maybe this happens when waking goes wrong and you wait a looong time? Don't know. Most interesting part of this stackshot is here: Thread 0x3e7 Thread name "IOGraphicsWorkLoop" 10 samples (1-10) priority 93 (base 81) cpu time 0.109 <IO tier 0> *10 call_continuation + 23 (kernel + 666359) [0xffffff80002a2af7] 1-10 *10 IOWorkLoop::threadMain() + 22 (kernel + 7063078) [0xffffff80008bc626] 1-10 *10 IOWorkLoop::runEventSources() + 433 (kernel + 7065665) [0xffffff80008bd041] 1-10 *10 IOInterruptEventSource::checkForWork() + 287 (kernel + 7071711) [0xffffff80008be7df] 1-10 *10 IOFramebuffer::systemWork(OSObject*, IOInterruptEventSource*, int) + 211 (IOGraphicsFamily + 45939) [0xffffff7f81790373] 1-10 *10 IOFramebuffer::checkPowerWork(IOFBController*, unsigned int) + 140 (IOGraphicsFamily + 62582) [0xffffff7f81794476] 1-10 *10 IOFramebuffer::checkPowerWork(unsigned int) + 503 (IOGraphicsFamily + 66267) [0xffffff7f817952db] 1-10 *10 AMDFramebuffer::setAttribute(unsigned int, unsigned long) + 3287 (AMDFramebuffer + 40167) [0xffffff7f8309dce7] 1-10 *10 AMDFramebuffer::setAttribute(unsigned int, unsigned long) + 741 (AMDFramebuffer + 37621) [0xffffff7f8309d2f5] 1-10 *10 AMDFramebuffer::doSetPowerState(unsigned int) + 147 (AMDFramebuffer + 65555) [0xffffff7f830a4013] 1-10 *10 AMDFramebuffer::setSystemPowerState(unsigned int) + 132 (AMDFramebuffer + 66468) [0xffffff7f830a43a4] 1-10 *10 AMDFramebuffer::doDoze() + 56 (AMDFramebuffer + 68904) [0xffffff7f830a4d28] 1-10 *10 AMDFramebuffer::doWake() + 995 (AMDFramebuffer + 67491) [0xffffff7f830a47a3] 1-10 *10 AMD7000Controller::wakePowerPlay(bool) + 144 (AMD7000Controller + 132848) [0xffffff7f830ed6f0] 1-10 *10 SISharedController::wakePowerPlay(bool) + 120 (AMD7000Controller + 65272) [0xffffff7f830dcef8] 1-10 *10 SIPowerPlayManager::wakeUp() + 98 (AMD7000Controller + 104882) [0xffffff7f830e69b2] 1-10 *10 SIPowerPlayManager::initialize() + 554 (AMD7000Controller + 102666) [0xffffff7f830e610a] 1-10 *10 ATIController::sendRequestToAccelerator(_eAMDAccelIOFBRequestType, void*, void*, void*) + 162 (AMDSupport + 11362) [0xffffff7f82512c62] 1-10 *10 AMDRadeonX4000_AMDGraphicsAccelerator::callPlatformFunction(OSSymbol const*, bool, void*, void*, void*, void*) + 460 (AMDRadeonX4000 + 19312) [0xffffff7f8270fb70] 1-10 *10 AMDRadeonX4000_AMDGraphicsAccelerator::powerUpHW() + 297 (AMDRadeonX4000 + 12457) [0xffffff7f8270e0a9] 1-10 *10 AMDTahitiHardware::powerUp() + 23 (AMDRadeonX4000 + 422413) [0xffffff7f8277220d] 1-10 *10 AMDSIHardware::powerUp() + 23 (AMDRadeonX4000 + 411069) [0xffffff7f8276f5bd] 1-10 *10 AMDRadeonX4000_AMDHardware::powerUp() + 461 (AMDRadeonX4000 + 475259) [0xffffff7f8277f07b] 1-10 *10 AMDRadeonX4000_AMDHWChannel::waitForIdle() + 99 (AMDRadeonX4000 + 304603) [0xffffff7f827555db] 1-10 *10 AMDSIPM4Engine::isIdle() + 22 (AMDRadeonX4000 + 427592) [0xffffff7f82773648] 1-10 *10 AMDRadeonX4000_AMDHWRegisters::read(unsigned int) + 40 (AMDRadeonX4000 + 353890) [0xffffff7f82761662] (running) 1-10 So it looks like AMDX4000 gets stuck / crashes within "AMDHWRegisters::read". Not sure if this is news for anyone, but it might be a starting point... I never had to debug a kernel extension, so I might not be the best person for this job. Someone has a good idea what to do next? Full Stackshot is attached. Btw, didn't manage to reproduce that behavior yet. Sleep Wake Failure.rtf
  11. Exactly, I was inaccurate. 0x1912001 is what the iMac uses, I'll try it later! EDIT: Hmkay, I get a KP when booting with 0x19120001, no matter if I connect anything or not. EDIT2: It'll boot up fine when injecting 0x1912001 and setting PCIE=Primary in BIOS. Well, actually it won't inject that platform-id. It seems Clover won't inject anything IntelHD-related when it isn't primary. Is this usual behavior? (Never had a Hackintosh with iGPU before, so I don't have much experience with this). Btw, did anyone of you ever investigate the differences of IOReg dumps with IGPU=Primary (which can wake) vs. dumps with PCIE=Primary (which won't wake)? Some IOInterruptSpecifiers and other stuff differ, not sure if that's important or not...? I'll have a deeper look tomorrow...
  12. Sure, a full Clover Dump (F4) is attached. Btw, do you know how the iGPU is configured in the iMac? I guess it uses a frame buffer without any outputs, right? I'd like to do the same on my Hack, so the iGPU will show the boot loader and turns off when OS X takes over. This would be an "okay-ish" solution until the problem is fully understood & solved (or until I've given up and bought a NVIDIA...). origin.zip
  13. Hey guys, I just moved on to a new Skylake build (i5-6600K, Asus Z170M-Plus) , so can't stay on Yosemite anymore. As expected, sleep is broken with my R9 280. With ig-platform-id=0x19120000 and iGPU set to primary, it'll wake as long as no screen is connected to Intel Graphics. I guess this is caused by the buggy Skylake drivers. It's not a headless iGPU though, graphics will work (just with "Skylake artifacts"). When booting with PCIE=Primary, audio and USB remains functional for a short period of time (I think this didn't happen on my old P55 build), but the screen stays black.
  14. Okay, here we go, sorry for the delay (always the same around christmas: Too much to eat, too little time ) I made the dump on my MP3,1 in El Capitan 10.11.2 with my R9 280 installed. I booted both with injection as well as without injection but the ACPI tables didn't change from what I can tell, so I've only uploaded on set. I hope it will be helpful! ACPI Tables.zip
  15. Okay, I'll do this in the next days! Will there be a difference if a PC or Mac GPU is installed? If you'd expect a difference, I'd make dumps both with PC ROM and Mac ROM on my R9 280. @latest discussion: I don't think mismatched framebuffers are causing this problem, in my MacPro3,1 sleep is *always* working (e.g. 7870 with Futomaki, 7770 with Dashimaki, R9 280 with Hamachi or RadeonFramebuffer).