Menu Bar Options Unresponsive When Restoring from Metrics

[moosethegoose2213]

When restoring the Power Gadget window from the menu bar icon, the left side menu options become unresponsive until clicking out and back to the window. This happens while running MacOS Monterey with v1.7 (V2) of the Power Gadget.

[trulyspinach]

Hi,
I have also noticed this behavior. If you switch another application to foreground then switch back it will be responsive. For now I strongly believe this is a bug in macOS.

[moosethegoose2213]

Probably, wouldn't be surprising. If I have time, I'll see if the same behavior exists in Mojave tomorrow

[iGPU]

Many of us truly enjoy using your kexts and app. The app is very useful. Thanks!

While you may not intend to support the TRX40 mobo, many of us are successfully using your app on this platform.

However, with the latest v1.7 there are some system crashes and lockups. I've written about it here.

The menu un-responsiveness, commented above, seems to be related to the "statusbarenabled" setting inside the wtf.spinach.AMD-Power-Gadget.plist file. If this setting is disabled ("NO"), then the AMD Power Gadget menu is accessible. (Of course, editing the plist file with the app not running and re-start the app once the plist file is saved.)

As for the crashes (lock-ups), they seem to be related to the "startAtLogin" setting in the plist file. If "YES" then a crash occurs on the TRX40 system once re-booted with the auto login enabled (btw, this crash did not occur with the previous releases of the AMD Power Gadget app). The lock-up occurs within about 60 sec after logging into the macOS (using Monterey ß4 just now).

If auto login is disabled, the kexts behave just fine and the AMD Power Gadget app can be used without any lock-ups if the app is started manually. The AMD Power Gadget app is then manually exited before re-booting the computer. If these manual steps are followed, all is fine.

In looking at the Crash logs when auto-login is enabled, I see the following excerpt (a Crash log file is also attached); hopefully this is helpful.

[AMD Power Gadget_2021-08-04-183817_rjs-Mac-Pro.crash.zip](https://github.com/trulyspinach/SMCAMDProcessor/files/6951361/AMD.Power.Gadget_2021-08-04-183817_rjs-Mac-Pro.crash.zip)

---

After writing the above, the system began locking up even if only the AMDRyzenCPUPowerManagement.kext was enabled (and no AMD Power Gadget app was running). This is after a morning of the computer running fine with both kexts enabled but no app running. It was only after enabling auto log-in did all the troubles start once more. I've presently disabled both kext files.

[trulyspinach]

Hi @iGPU thanks for letting me know this discussion. I have been using 1.7 daily in Big Sur and so far haven't encountered any problem myself.

• Can you post a panic log of your 60 second lock down so I can see how it was causing the panic?
• Does this happen only in macOS 12?

The AMD Power Gadget application runs in userspace and I have done some measures to make sure its internal problem won't affect kernels execution. So the crash in the app should not crash the system.

Setting statusbarenabled to false will stop AMD Power Gadget from creating menu item(See here). I do not have an account for macos86 so I won't be replying there. The issue @moosethegoose2213 mentioned should be related to this API call. That's why I said I believe it is a bug in macOS. However, none of this shall crash the system. A crash after 60 seconds sounds like the issue related to macOS's builtin Intel PM, are you sure you have DummyPowerManagement enabled in OC?

[iGPU]

Thanks for reply. The DummyPowerManagement quirk is not typically needed for the TRX40 mobo (except, up until now, for Gigabyte TRX40 mobos). After reading your reply, this is the first thing I changed, enabling DummyPowerManagement.

The system now seems stable when using your latest kexts in Monterey ß4 (I've not yet tested in Big Sur, but now foresee no problems). So, it would appear that all TRX40 mobos should keep DummyPowerManagement enabled. Thanks!

However, I do still see the disappearance of the AMD Power Gadget (AMDPG) app's sub-menus (the menu bar is present but is unresponsive with no pop-up sub-menus), if statusbarenabled is enabled and AMDPG is re-started. To explain further, if statusbarenabled is disabled and then the AMDPG app is run, the sub-menuw work just fine. While in this mode, as you've pointed out, there is no menu bar metrics info.

Then, if the menu item "Show metrics in menu bar" is selected (as shown in image below), the metrics data is visible in the menu bar, and the sub-menus in AMDPG continue to work as expected. But, if the AMDPG app is now quit and re-started, and the metrics info in menu bar is clicked, while the main AMDPG window appears, the AMDPG app's sub-menus are not longer selectable nor visible.

This cycle can be repeated and if the AMDPG plist file is not closed, the sub-menus do work properly.

---

BTW, I did look at the Kernel panic log and at the end of this file found the following:

 Kernel Extensions in backtrace:\n com.apple.driver.AppleIntelCPUPowerManagement (222.0)[C976299C-7A0C-3F2C-8A3A-524D89DEF7C6]@0xffffff8018219000->0xffffff8018235fff\n\nProcess name corresponding to current thread (0xffffff882a5816e0).

This led me to try the DummyPowerManagement quirk which indeed seemed to fix the computer crash and stop the kernel panics.