Contribute
Register

Random screen freezes and screen always freezes on Shutdown/Restart

Status
Not open for further replies.
I recently updated OC from .6.7 -> .7.5 and wanted to try the Monterey upgrade from Big Sur.

The upgrade went smooth with no issues, everything was working as it was in Big Sur, except for 1 issue. I'd get random screen freezes after some time and also when I go to either shutdown or restart my screen will instantly freeze, not allowing any mouse or keyboard input.

Tried searching the forum for anyone experiencing a similar issue, but haven't found any in the Monterey forum.

I previously was on Catalina and successfully upgraded to Big Sur without any issues. With the screen freeze issue in Monterey, I've reverted back to Big Sur and all is good again.

I'd like to get an idea of what my problem is and try to do the upgrade to Monterey again.
Your config.plist does not conform to OpenCore 0.7.5 requirements:

The following entry in UEFI -> Output should not exist:
XML:
                <key>UIScale</key>
                <integer>-1</integer>
This was most likely leftover code from an older OpenCore version. I have removed this from the attached config.plist for you. It's best to be always aware of the differences between versions, when upgrading.

In future, please use the version-specific ocvalidate tool that comes with each OpenCore release to check that your config.plist conforms to specification.

Note#1: I strongly suggest not using FakePCIID and the respective injector kexts to enable your i225 network and HDMI audio. That solution should not be needed (with Z490 systems running Big Sur/Monterey), despite their apparent prevalence in other members configurations. In your case, the i225 network interface should be fully operational with the appropriate device-id under PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0) (DeviceProperties), and the dk.e1000=0 boot argument (boot-args). Simultaneously patching with FakePCIID will cause this to fail.

Note#2: You seem to have some possible duplication and/or unnecessary SSDT files. It's possible that replacing all/most of those referenced under ACPI, with versions specifically generated for your system, may help eliminate crashes. Using SSDTTime (available from GitHub) is one way to achieve that, and instructions for usage are available within the Dortania OpenCore guides.

I hope this information was helpful. Cheers.
 
Last edited by a moderator:
Thank you all for your feedback and suggestions. I too have experienced the random freezes which result in a reboot of my build. I found there to be a few different reasons why.

Making sure I started with the recommended sudo pmset -g values and I did not have the invalid settings related to UIScale, I found that @macntosh's recommendations from Note#1 was solid and helped. I removed FakePCIID and respective i225 network + HDMI audio kexts. I kept the boot-arg dk.e1000=0 as it was. This enabled me to have less frequent freezes resulting in restarts.

Note#1: I strongly suggest not using FakePCIID and the respective injector kexts to enable your i225 network and HDMI audio. That solution should not be needed (with Z490 systems running Big Sur/Monterey), despite their apparent prevalence in other members configurations. In your case, the i225 network interface should be fully operational with the appropriate device-id under PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0) (DeviceProperties), and the dk.e1000=0 boot argument (boot-args). Simultaneously patching with FakePCIID will cause this to fail.

The next observation I had was that when I did continue to have random freezes it just so happened to be when I was listening to my music. I thought for sure that it was related to my audio configuration, but turns out to not have been the case as far as I could tell. The issue was that I was using Spotify to listen to my music. It didn't matter if I connected through the 3.5mm jack (w/ AppleALC.kext enabled) or when I was using digital audio S/PDIF connection (w/ AppleALCU.kext enabled). Thankfully I subscribe to both Apple Music and Spotify and found that switching to Apple Music strictly has left my build stable going on 4 days.

Just want to say thanks to all for the shares and recommendations.
 
... The next observation I had was that when I did continue to have random freezes it just so happened to be when I was listening to my music. I thought for sure that it was related to my audio configuration, but turns out to not have been the case as far as I could tell. The issue was that I was using Spotify to listen to my music. It didn't matter if I connected through the 3.5mm jack (w/ AppleALC.kext enabled) or when I was using digital audio S/PDIF connection (w/ AppleALCU.kext enabled). Thankfully I subscribe to both Apple Music and Spotify and found that switching to Apple Music strictly has left my build stable going on 4 days...
While I don't use either Apple Music or Spotify, as I understand it, Apple Music is geared toward streaming high quality music formats, whereas in the case of Spotify, not so much. Their infrastructures would no doubt reflect their respective capabilities, and that very distinction, in itself, could be reason enough to support your observations.

Just my two cents (keep the change). Cheers.
 
While I don't use either Apple Music or Spotify, as I understand it, Apple Music is geared toward streaming high quality music formats, whereas in the case of Spotify, not so much. Their infrastructures would no doubt reflect their respective capabilities, and that very distinction, in itself, could be reason enough to support your observations.

Just my two cents (keep the change). Cheers.
I appreciate the explanation and totally agree with your two cents :), however I should've provided more fact supporting my statements as I made myself sound like a basic n00b taking a guess.

I found Spotify to be directly related to the less frequent freezes and restarts as when I restarted and got logged in there would always be the same diagnostic crash report generated which pointed me to it. Unfortunately since I have gained stability and like a n00b I didn't actually save the entire diagnostic report generated. I will use some brain power, start using Spotify again, and provide some evidence to my observation.

But yes, with the latest iOS and macOS releases the option for Apple Music playback of Lossless audio [Hi-Res Lossless (ALAC up to 24-bit/192 kHz)] is dr00lworthty and makes me get all warm in fuzzy inside. Spotify not so much.
 
Your config.plist was not valid according to OpenCore 0.7.5 requirements. I corrected that for you in the attached copy. You should add your personal system information back to that copy, and use it instead (or, make the following edits manually). While it's unlikely that these edits will cure your crashing woes, at least it now conforms to specification.

I have added the following:

Booter -> Quirks:
XML:
            <key>ResizeAppleGpuBars</key>
            <integer>-1</integer>
UEFI -> Quirks:
XML:
            <key>ResizeGpuBars</key>
            <integer>-1</integer>

More information about these edits can be found here. When upgrading OpenCore it's always best to be aware of the differences between versions, and adjust your config.plist accordingly, whenever necessary.
Thanks, but I was still on OC 0.7.4, that's why the they were missing. Updating to 0.7.5 (and adding the quirks) didn't solve the issue. Back to caffeinate -d.
 
Woohoo! I was just able to reproduce the crash. This is definitely the second of the two distinct types of freeze restarts I've experienced with Monterey. Whether the real issue is Spotify or something related to graphics / hardware acceleration / audio configuration we shall find out.

Here's what I did, the resulting behavior, and all diagnostic info.

ASSUMPTION:
Hardware acceleration is enabled by default in Spotify preferences.

Screen Shot 2021-11-21 at 12.36.09 AM.png


REPRO STEPS:
1
. Launch Spotify
2. Click Spotify in system menu bar
3. Click checked option Hardware Acceleration (this results in a user prompt with option to choose whether to restart the Spotify application with updated setting)
4. Click Restart application option
5. Spotify application launches again
6. Click Spotify in system menu bar
7. Observe Hardware Acceleration no longer has a check next to it (i.e. Hardware Acceleration disabled)
8. Click Hardware Acceleration from menu as to enable Hardware Acceleration (this results in a user prompt with option to choose whether to restart Spotify application with updated setting)
9. Click Restart application option
10. Spotify relaunches again
11. Attempt to click Spotify in system menu bar

EXPECTED BEHAVIOR:
Spotify menu should appear and user can continue to use Spotify application with re-enabled Hardware Acceleration

ACTUAL BEHAVIOR:
macOS freezes momentarily and system restarts.
Upon starting up of system post-crash Diagnostic Report tool launches.
Kernel-YYYY-MM-DD-TIMESTAMP.panic is generated for optional submission to Apple

Code:
{"timestamp":"2021-11-21 00:30:15.00 -0800","bug_type":"210","os_version":"macOS 12.1 (21C5039b)","incident_id":"48417F77-FB68-4D60-841E-036E4BB6C236"}
{"macOSProcessedStackshotData":"bm8gb24gZGlzayBwYW5pYyBzdGFja3Nob3QgZm91bmQgaW4gY29yZWZpbGU=","macOSPanicString":"panic(cpu 12 caller 0xffffff8012b1d514): assertion failed: hash_entry->soflow_db->soflow_db_feat_ctxt_cnt > 0, file: \/System\/Volumes\/Data\/SWE\/macOS\/BuildRoots\/c40be6c978\/Library\/Caches\/com.apple.xbs\/Sources\/xnu\/xnu-8019.60.69\/bsd\/net\/content_filter.c, line: 5819
Panicked task 0xffffff86feea1670: 48 threads: pid 17355: Spotify
Backtrace (CPU 12), panicked thread: 0xffffff9566d97aa0, Frame : Return Address
0xffffffd11e213a10 : 0xffffff8012288e8d mach_kernel : _handle_debugger_trap + 0x41d
0xffffffd11e213a60 : 0xffffff80123e8da5 mach_kernel : _kdp_i386_trap + 0x145
0xffffffd11e213aa0 : 0xffffff80123d8573 mach_kernel : _kernel_trap + 0x533
0xffffffd11e213af0 : 0xffffff8012228a60 mach_kernel : _return_from_trap + 0xe0
0xffffffd11e213b10 : 0xffffff801228925d mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffd11e213c30 : 0xffffff8012288a16 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffffd11e213c90 : 0xffffff8012b16cd9 mach_kernel : _panic + 0x54
0xffffffd11e213d00 : 0xffffff8012b1d514 mach_kernel : _panic_machine_check64 + 0x72d
0xffffffd11e213d10 : 0xffffff80126c5622 mach_kernel : _cfil_sock_data_pending + 0x1832
0xffffffd11e213d30 : 0xffffff80126c5485 mach_kernel : _cfil_sock_data_pending + 0x1695
0xffffffd11e213d60 : 0xffffff801290b8df mach_kernel : _soflow_detach + 0x73f
0xffffffd11e213d90 : 0xffffff801290b31b mach_kernel : _soflow_detach + 0x17b
0xffffffd11e213dd0 : 0xffffff80128cb657 mach_kernel : _soclose_locked + 0x837
0xffffffd11e213e20 : 0xffffff80128cbacb mach_kernel : _soclose + 0xab
0xffffffd11e213e40 : 0xffffff80128347c3 mach_kernel : _kern_close_file_for_direct_io + 0x463
0xffffffd11e213eb0 : 0xffffff80128352db mach_kernel : _fdt_exec + 0x70b
0xffffffd11e213f40 : 0xffffff801299f5f4 mach_kernel : _unix_syscall64 + 0x204
0xffffffd11e213fa0 : 0xffffff8012229226 mach_kernel : _hndl_unix_scall64 + 0x16

Process name corresponding to current thread (0xffffff9566d97aa0): Spotify
Boot args: shikigva=80 dk.e1000=0 keepsyms=1 agdpmod=pikera debug=0x100 itlwm_cc=US -wegnoigpu chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
21C5039b

Kernel version:
Darwin Kernel Version 21.2.0: Thu Nov 11 00:10:13 PST 2021; root:xnu-8019.60.69~7\/RELEASE_X86_64
Kernel UUID: F6233E1D-1FDF-3B24-9FFB-F434FCDC4A91
KernelCache slide: 0x0000000012000000
KernelCache base:  0xffffff8012200000
Kernel slide:      0x0000000012010000
Kernel text base:  0xffffff8012210000
__HIB  text base: 0xffffff8012100000
System model name: iMac20,2 (Mac-AF89B6D9451A490B)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 44650711168649
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x0000289c0dc7388c
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x0000002ca80576c6 0x0000000000000000
Zone info:
Foreign   : 0xffffff8019b76000 - 0xffffff8019b83000
Native    : 0xffffff8098679000 - 0xffffffa098679000
Readonly  : 0xffffff8565345000 - 0xffffff86fecd9000
Metadata  : 0xffffffd85c4a9000 - 0xffffffd87cc95000
Bitmaps   : 0xffffffd87cc95000 - 0xffffffd894c95000


"}

Screen Shot 2021-11-21 at 12.30.39 AM.png


Screen Shot 2021-11-21 at 12.30.51 AM.png


COMMENTS:
Please keep in mind that the panic diagnostic shows I am running Monterey 12.1 BETA 3 as I am a registered Apple Developer. I don't recall if Tonymacx86.com user agreement still prohibits any discussion of future releases, and I don't want to break any rules as the only reason I am bringing this point up is that this is the exact panic diagnostic I would get when I was running public release Monterey 12.0.1. Nothing has changed in that regard as the behavior started since upgrading to public release Monterey.
 
Last edited:
... Updating to 0.7.5 (and adding the quirks) didn't solve the issue. ...
No, they were not intended to. I made the assumption that you had already upgraded to 0.7.5, and that being the case, the correction would have been warranted. However, the premise applies when upgrading to any version of OpenCore, including 0.7.4: Always be aware of version-specific changes, especially in the format of config.plist. Add whatever the version changes may dictate, no matter whether you think it applies, as new settings can usually be left at the default, without issue.

It's just good practice. Cheers.
 
Last edited by a moderator:
ASSUMPTION:
Hardware acceleration is enabled by default in Spotify preferences.
Is hardware acceleration enabled for your GPU?

If not, that might go some way toward explaining what you're seeing hearing; or, perhaps something funky with HDMI audio config. A while back, I had an acceleration related issue with [my] RX 580 (error -12473), which turned out being instantiation failure of the VDA Decoder.

Forcing the decoder resolved the issue, in my case:
Bash:
defaults write com.apple.AppleGVA gvaForceAMDAVCDecode -boolean yes
It's also possible that what you described was an artifact of using FakePCIID.

Boot args: shikigva=80 dk.e1000=0 keepsyms=1 agdpmod=pikera debug=0x100 itlwm_cc=US -wegnoigpu chunklist-security-epoch=0 -chunklist-no-rev2-dev
Note#1: It's my understanding that agdpmod=pikera will not work as expected (if at all) with the AMD RX 580. I don't know whether or not that extends to AMD GPUs in your other builds.

Note#2: While useful for OpenCore debugging purposes, keepsyms=1 can also contribute to a range of crashes, if memory serves.
 
Last edited by a moderator:
Your config.plist does not conform to OpenCore 0.7.5 requirements:

The following entry in UEFI -> Output should not exist:
XML:
                <key>UIScale</key>
                <integer>-1</integer>
This was most likely leftover code from an older OpenCore version. I have removed this from the attached config.plist for you. It's best to be always aware of the differences between versions, when upgrading.

In future, please use the version-specific ocvalidate tool that comes with each OpenCore release to check that your config.plist conforms to specification.

Note#1: I strongly suggest not using FakePCIID and the respective injector kexts to enable your i225 network and HDMI audio. That solution should not be needed (with Z490 systems running Big Sur/Monterey), despite their apparent prevalence in other members configurations. In your case, the i225 network interface should be fully operational with the appropriate device-id under PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0) (DeviceProperties), and the dk.e1000=0 boot argument (boot-args). Simultaneously patching with FakePCIID will cause this to fail.

Note#2: You seem to have some possible duplication and/or unnecessary SSDT files. It's possible that replacing all/most of those referenced under ACPI, with versions specifically generated for your system, may help eliminate crashes. Using SSDTTime (available from GitHub) is one way to achieve that, and instructions for usage are available within the Dortania OpenCore guides.

I hope this information was helpful. Cheers.
@macntosh - You, my friend, really know what you're talking about. Everything you mentioned, I did piece together from other member's configuration.

I applied the changes you advised above.

1. Removed UEFI/Output/UIScale
2. Removed FakePCIID, FakePCIID_Intel_HDMI_Audio, and FakePCIID_Intel_I225-V kexts and added dk.e1000=0 to boot-args
3. Removed old and duplicate SSDT files, SSDT-EC and SSDT-PLUG

Reinstalled Monterey and everything is working as expected. Restarts and Shutdowns are normal and haven't received any random shutdowns thus far.

Thank you, @macntosh!!!
 
.. as I am a registered Apple Developer...
I am also a registered Apple Developer. That distinction affords me the privilege of receiving advance product and security notifications, personalized marketing materials, and all the usual newsletters.

What other value it has, is unclear.
 
Status
Not open for further replies.
Back
Top