Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

I've been having kernel panic for the last couple of weeks. Happens overnight when the computer goes to sleep or wakes up. It says CPU4 caused it while calling power state change call backs. Any insight?


panic(cpu 4 caller 0xffffff8000c90958): Wake transition timed out after 180 seconds while calling power state change callbacks.
Failure code:: 0x00000001 00000027

Backtrace (CPU 4), Frame : Return Address
0xffffff873f0a3930 : 0xffffff800051a65d mach_kernel : _handle_debugger_trap + 0x49d
0xffffff873f0a3980 : 0xffffff8000654a75 mach_kernel : _kdp_i386_trap + 0x155
0xffffff873f0a39c0 : 0xffffff80006465fe mach_kernel : _kernel_trap + 0x4ee
0xffffff873f0a3a10 : 0xffffff80004c0a40 mach_kernel : _return_from_trap + 0xe0
0xffffff873f0a3a30 : 0xffffff8000519d27 mach_kernel : _DebuggerTrapWithState + 0x17
0xffffff873f0a3b30 : 0xffffff800051a117 mach_kernel : _panic_trap_to_debugger + 0x227
0xffffff873f0a3b80 : 0xffffff8000cc1b28 mach_kernel : _panic_with_thread_context
0xffffff873f0a3bf0 : 0xffffff8000c90958 mach_kernel : __ZN14IOPMrootDomain13takeStackshotEb + 0xa28
0xffffff873f0a3ea0 : 0xffffff8000c1348a mach_kernel : __ZN9IOService22watchdog_timer_expiredEPvS0_ + 0x2a
0xffffff873f0a3ec0 : 0xffffff800055c605 mach_kernel : _thread_call_delayed_timer + 0xec5
0xffffff873f0a3f40 : 0xffffff800055c131 mach_kernel : _thread_call_delayed_timer + 0x9f1
0xffffff873f0a3fa0 : 0xffffff80004c013e mach_kernel : _call_continuation + 0x2e

BSD process name corresponding to current thread: kernel_task
Boot args: keepsyms=1 debug=0x100 alcid=1

Mac OS version:
19G73

Kernel version:
Darwin Kernel Version 19.6.0: Sun Jul 5 00:43:10 PDT 2020; root:xnu-6153.141.1~9/RELEASE_X86_64
Kernel UUID: 783946EA-6F11-3647-BF90-787AEA14B954
Kernel slide: 0x0000000000200000
Kernel text base: 0xffffff8000400000
__HIB text base: 0xffffff8000300000
System model name: iMac19,1 (Mac-AA95B1DDAB278B95)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 35290556277710
 
In the next HackinDROM update I'll implant Thunderbolt BUS ID changing full working functionality to Alpine Ridge, too.
Also, an option will be presented to decide to keep RP05 (for those who don't have on-board TB controller // @CaseySJ confirmation?) or change it for RP21 or other.
 
Last edited:
You and @CaseySJ are absolute madlads for updating and fixing problems so quickly. Can confirm that the current version of HackinDROM is able to generate an SSDT that does not show duplicate ports and uses the chosen bus id. I should also mention that I manually edited the SSDT to change RP05->RP21 in addition to the modified bus id so that the controllers don't conflict. This allowed for the correct bus id to be shown. If you're able to @Inqnuam, perhaps this might be a nice function to add for people who have more than one Thunderbolt controller?

I also used ThunderboltUtil to update the current DROM myself and can confirm that the results seem to be the same.

Thanks again to the both of you and @joevt for ThunderboltUtil
On RP05 (internal) the Link Speed is showing 20 Gbps instead of 40 Gbps. Please check if the SSDT for that controller contains this:
Code:
                            "linkDetails",
                            Buffer (0x08)
                            {
                                 0x08, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00   // ........
                            },
 
Last edited:
Hello¡¡ @CaseySJ, today I want to test the new driver for Bluetooth natively https://github.com/OpenIntelWireless/IntelBluetoothFirmware/releases/tag/1.1.1 (release 1.1.1)...but in about this Mac the Bluetooth driver is empty... I put the new driver in EFI and same problem its not enable...
Any solution?
THX¡¡
Please see the micro-guide below that is also available thru the Quick Reference spoiler in Post #1:
Let us know if you still have trouble installing the new AppleIntelBluetooth kext. This is an exciting driver that many of us are eagerly awaiting (hopefully it will support Handoff).
 
Last edited:
In the next HackinDROM update I'll implant Thunderbolt BUS ID changing full working functionality to Alpine Ridge, too.
Also, an option will be presented to decide to keep RP05 (for those who don't have on-board TB controller // @CaseySJ confirmation?) or change it for RP21 or other.
For every add-in-controller only, we should:
  1. Provide the ability to change Bus ID.
  2. Provide the ability to change the root port. However, changing root port is not always so easy.
    • On Z390 and Z490 (and maybe Z370) the process is easy because PCIe slots are mapped to PEG1, RP21, RP23, etc.
      • Even on these boards, global search-and-replace will only work if the target PCIe slot contains a default device named:
        • PEGP under PEG1
        • PXSX under RPxx
    • On X99 and X299, the mapping is very different from board to board. They use SL1A, BR01, and other gobbledygook (yup, that's in the dictionary).
So one way to handle option 2 is to ask if the user has a Z370, Z390, or Z490 board. We could also ask if there's a PEGP/PXSX default device, but maybe that's too much to ask?? ;)

Ideally, we would read the default DSDT and check it automatically for the presence of PCI0, PEGx, RPxx, PEGP, and PXSX. If we don't find these three items, then we would ask the user to manually modify their SSDT.
 
Last edited:
I've been having kernel panic for the last couple of weeks. Happens overnight when the computer goes to sleep or wakes up. It says CPU4 caused it while calling power state change call backs. Any insight?


panic(cpu 4 caller 0xffffff8000c90958): Wake transition timed out after 180 seconds while calling power state change callbacks.
Failure code:: 0x00000001 00000027

Backtrace (CPU 4), Frame : Return Address
0xffffff873f0a3930 : 0xffffff800051a65d mach_kernel : _handle_debugger_trap + 0x49d
0xffffff873f0a3980 : 0xffffff8000654a75 mach_kernel : _kdp_i386_trap + 0x155
0xffffff873f0a39c0 : 0xffffff80006465fe mach_kernel : _kernel_trap + 0x4ee
0xffffff873f0a3a10 : 0xffffff80004c0a40 mach_kernel : _return_from_trap + 0xe0
0xffffff873f0a3a30 : 0xffffff8000519d27 mach_kernel : _DebuggerTrapWithState + 0x17
0xffffff873f0a3b30 : 0xffffff800051a117 mach_kernel : _panic_trap_to_debugger + 0x227
0xffffff873f0a3b80 : 0xffffff8000cc1b28 mach_kernel : _panic_with_thread_context
0xffffff873f0a3bf0 : 0xffffff8000c90958 mach_kernel : __ZN14IOPMrootDomain13takeStackshotEb + 0xa28
0xffffff873f0a3ea0 : 0xffffff8000c1348a mach_kernel : __ZN9IOService22watchdog_timer_expiredEPvS0_ + 0x2a
0xffffff873f0a3ec0 : 0xffffff800055c605 mach_kernel : _thread_call_delayed_timer + 0xec5
0xffffff873f0a3f40 : 0xffffff800055c131 mach_kernel : _thread_call_delayed_timer + 0x9f1
0xffffff873f0a3fa0 : 0xffffff80004c013e mach_kernel : _call_continuation + 0x2e

BSD process name corresponding to current thread: kernel_task
Boot args: keepsyms=1 debug=0x100 alcid=1

Mac OS version:
19G73

Kernel version:
Darwin Kernel Version 19.6.0: Sun Jul 5 00:43:10 PDT 2020; root:xnu-6153.141.1~9/RELEASE_X86_64
Kernel UUID: 783946EA-6F11-3647-BF90-787AEA14B954
Kernel slide: 0x0000000000200000
Kernel text base: 0xffffff8000400000
__HIB text base: 0xffffff8000300000
System model name: iMac19,1 (Mac-AA95B1DDAB278B95)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 35290556277710
Could this be related to:
  • Luna Display
  • Platform ID 0x3E9B0007 (instead of headless 0x3E980003)
 
For every add-in-controller only, we should:
  1. Provide the ability to change Bus ID.
  2. Provide the ability to change the root port. However, changing root port is not always so easy.
    • On Z390 and Z490 (and maybe Z370) motherboards the process is easy because PCIe slots are mapped to PEG1, RP21, RP23, etc.
      • Even on these boards, global search-and-replace will only work if the target PCIe slot contains a default device named:
        • PEGP under PEG1
        • PXSX under RPxx
    • On X99 and X299, the mapping is very different from board to board. They use SL1A, BR01, and other gobbledygook (yup, that's in the dictionary).
So one way to handle option 2 is to ask if the user has a Z370, Z390, or Z490 board. We could also ask if there's a PEGP/PXSX default device, but maybe that's too much to ask?? ;)

Ideally, we would read the default DSDT and check it automatically for the presence of PCI0, PEGx, RPxx, PEGP, and PXSX. If we don't find these three items, then we would ask the user to manually modify their SSDT.

Speaking as a x299 user, I feel like this will get too complicated very fast and it would be best to manually modify. You have to deal with pc00,pc01,pc02,pc03,br1a, br2a, etc and not to mention boards with plx chips (like the x299 sage) have additional pci-bridges.

It would be cool if it could somehow scan an ioreg dump or something and magically do it haha
 
On RP05 (internal) the Link Speed is showing 20 Gbps instead of 40 Gbps. Please check if the SSDT for that controller contains this:
Code:
                            "linkDetails",
                            Buffer (0x08)
                            {
                                 0x08, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00   // ........
                            },
I guess I should have mentioned that the screenshot is for the AIC when it's improperly configured on RP05 via a direct copy from the current version of HackinDROM. The internal controller using SSDT-Z390-DESIGNARE-TB3HP-V4.aml contains the proper code just as you configured it :)

Thanks for the sharp eye and concern!
 
Back
Top