Kernel Panic on 16" i9 MBPwRD

I feel that the problem is not that consistent so it might be hard for Apple to replicate the bug. Sometimes I have tons of apps open with a lot of data in RAM but I still successfully wake up the MacBook Pro 16' after a long sleep with power nap (like yesterday). Sometimes I only have very few apps open, but waking up from sleep somehow triggers the kernel panic (like the day before yesterday...). I am yet to find the pattern behind this annoying and seemingly random kernel panic.

Mine has only happened (only been twice so far) when I had been using my MBP in clamshell mode with an external 4K screen, and then left it alone. I had power nap enabled and "prevent sleep" disabled. I have "prevent sleep" enabled now, but I haven't replicated the same circumstances yet because I have work to do :)

Thanks a lot from me too @vtrx0. After some research and comparison to other users with the lowest configuration I've come to the conclusion that the only reason for being halfway trough is the fact that I am not using external devices. Thats all. Other users with the same configured 16" have got the annoying issue. And they using externals especially monitors.

So lets hope that smoke ones head to try the problem soon. I hope the German saying "Köpfe rauchen" is comparable in English...😉

Very good point on the feedback, thank you for mentioning! I should have mentioned in my last post that just because I received acknowledgement of this bug, it’s still important to open a support case — ideally one that results in an RTA (that is, escalated to engineering).

That said, support is likely to require you to jump through some extremely time consuming (and pointless) hoops before they’ll open an RTA, and I know most people don’t have the time to waste... Regardless, sending feedback is a very good way to help light a fire, and it’s quick!

Yaeh. For many people is it just a waste of time helping fix the problem, having pointless phone calls with apple etc.

Also sending a feedback takes time writing down all the issues etc.

Maybe you could share your report to apple and we all could issue the same feedback.

10.15.4 supplemental update preformed yesterday April 9th, 2020 on my late 2015 iMac 5k. This morning when "my machine" went to sleep it would not wake up, after restart I got the same message as those here.

I got the same problem with new Mac and they just give another one for replacement but run into same problem. Calling up Apple support and they said did not hear any similar issue. Trying to report this issue to their engineering and suggest people to report this to Apple support and request them to file a case on this

I had the same issue last night - system just rebooted and primary boot partition was gone. Completely unusable.

Tried recovery, repair, firstAid. Nothing worked. Finally had to reinstall the OS after deleting / formatting the partition.

Still finding out what data I have lost.

Thanks, that’s definitely the same crash... There’s one common thing I’m noticing in *way* more of these crash reports than I would expect, which is the presence of kext’s from Universal Audio. I also have the latest UAD software installed, but I still hit this bug while the software was uninstalled *and* I had removed every non-Apple kext (verified w/ kextutil)... I suppose it’s possible that the sleep image in /private/var/vm is retaining a cached version, but Apple has obfuscated virtually every user-facing logging/debug utility over the past 2 years. I have a theory I’d like to verify:

To all users hitting this Panic: could you please post here if you do or do not have software from Universal Audio installed on your system (regardless of whether or not it’s ever been used or attached to hardware)? Also, if you’ve tried disabling power nap, could you post whether or not this stopped the crashes?

My theory isn’t specific to Universal Audio drivers; it has more to do with the driver depending on a user space process which depends on a graphics driver. So I’d also be curious if this bug is impacting any users who may have hardware that’s tightly integrated with OS software (or still have drivers for any such device).

If we can confirm this theory, it’s possible we could ask companies like Universal Audio to help identify a work-around. Any info greatly appreciated!

I just got a 2 new 16" provided by Apple and with same config - only ms office, what's app desktop. nothing else. 1 enable nap and another with disable. I keep getting reboot with the one enable nap. While the one I disable, no occurrence for the last 48 hrs. no external devices connect.

Whoops -- good catch! Looks like UAudio 322.2 is probably apple's USB Audio driver. That was a bad assumption on my part; Universal Audio uses uaudio as part of their bundle identifier, but the kext bundle names are actually com.uaudio.driver.UAD2System and com.uaudio.driver.UAFWAudio.

All: Please disregard my above request for info (I'll try to edit)

cm0s: Thank you for your insight, and helping to prove my theory wrong so quickly (and I genuinely mean that)!

Just chiming in to say I've experienced the same issues on a 2016 i9 after opening the lid / waking from sleep:

panic(cpu 0 caller 0xffffff8001616487): "AppleIntelFramebuffer::setPowerState(0xffffff86965ed000 : 0xffffff7f84b01d88, 1 -> 0) timed out after 45909 ms"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.101.6/iokit/Kernel/IOServicePM.cpp:5296
Backtrace (CPU 0), Frame : Return Address
0xffffff8738cabb40 : 0xffffff8000f215cd 
0xffffff8738cabb90 : 0xffffff800105a3c5 
0xffffff8738cabbd0 : 0xffffff800104bf7e 
0xffffff8738cabc20 : 0xffffff8000ec7a40 
0xffffff8738cabc40 : 0xffffff8000f20c97 
0xffffff8738cabd40 : 0xffffff8000f21087 
0xffffff8738cabd90 : 0xffffff80016c2c7c 
0xffffff8738cabe00 : 0xffffff8001616487 
0xffffff8738cabe50 : 0xffffff8001615d69 
0xffffff8738cabe60 : 0xffffff800162d2fe 
0xffffff8738cabea0 : 0xffffff8001614b18 
0xffffff8738cabec0 : 0xffffff8000f63545 
0xffffff8738cabf40 : 0xffffff8000f63071 
0xffffff8738cabfa0 : 0xffffff8000ec713e 

BSD process name corresponding to current thread: kernel_task
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
19E287

Kernel version:
Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64
Kernel UUID: AB0AA7EE-3D03-3C21-91AD-5719D79D7AF6
Kernel slide:     0x0000000000c00000
Kernel text base: 0xffffff8000e00000
__HIB  text base: 0xffffff8000d00000
System model name: MacBookPro16,1 (Mac-E1008331FDC96864)
System shutdown begun: NO

System uptime in nanoseconds: 106986123069622
last loaded kext at 106710472243982: >usb.IOUSBHostHIDDevice	1.2 (addr 0xffffff7f84ade000, size 45056)
last unloaded kext at 105722513202990: >!UAudio	322.2 (addr 0xffffff7f88294000, size 434176)

I have the exact same issue on my i9 16", with possibly the same smoking gun?

last unloaded kext at 105722513202990: >!UAudio	322.2 (addr 0xffffff7f88294000, size 434176)

Mine is a bog-standard system, no third-party kext's:

~                                                                                                                                                                                                                          
▶ kextstat | grep -v com.apple
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>

~                                                                                                                                                                                                                          
▶

Today's kernel panic when trying to wake up is the following. It seems that the type of kernel panic is not always the same. Most of the time I got AppleIntelFramebuffer::setPowerState, but today's case is different.

panic(cpu 0 caller 0xffffff8014291b2c): Sleep transition timed out after 180 seconds while entering darkwake on way to sleep. Suspected bundle: com.apple.iokit.IOGraphicsFamily. Thread 0x74.

Backtracing specified thread

Backtrace (CPU 0), Frame : Return Address

0xffffff83d16ab900 : 0xffffff8013c471e8

0xffffffa3f8fcb9b0 : 0xffffff8013b433f1

0xffffffa3f8fcba20 : 0xffffff8013b41c2f

0xffffffa3f8fcba70 : 0xffffff8013c442e9

0xffffffa3f8fcbab0 : 0xffffff8013c43b4b

0xffffffa3f8fcbae0 : 0xffffff7f977f7ced

0xffffffa3f8fcbb10 : 0xffffff7f97810f75

0xffffffa3f8fcbb20 : 0xffffff7f977facb9

0xffffffa3f8fcbbb0 : 0xffffff7f97800549

0xffffffa3f8fcbc50 : 0xffffff80142020cf

0xffffffa3f8fcbcc0 : 0xffffff801421a770

0xffffffa3f8fcbd60 : 0xffffff80142028b9

0xffffffa3f8fcbdb0 : 0xffffff8014217e1b

0xffffffa3f8fcbe50 : 0xffffff801421424e

0xffffffa3f8fcbea0 : 0xffffff8014211d40

0xffffffa3f8fcbef0 : 0xffffff8014211bd9

0xffffffa3f8fcbf30 : 0xffffff801422d43e

0xffffffa3f8fcbf70 : 0xffffff801422ca36

0xffffffa3f8fcbfa0 : 0xffffff8013ac713e

Kernel Extensions in backtrace:

com.apple.iokit.IOGraphicsFamily(575.1)[D47CA481-C5E5-3F03-9B04-6634DF5F3121]@0xffffff7f977ef000->0xffffff7f9783ffff

dependency: com.apple.iokit.IOPCIFamily(2.9)[1B1F3BBB-9212-3CF9-94F8-8FEF0D3ACEC4]@0xffffff7f94511000

BSD process name corresponding to current thread: kernel_task

Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:

19E287

Kernel version:

Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64

Kernel UUID: AB0AA7EE-3D03-3C21-91AD-5719D79D7AF6

Kernel slide: 0x0000000013800000

Kernel text base: 0xffffff8013a00000

__HIB text base: 0xffffff8013900000

System model name: MacBookPro16,1 (Mac-E1008331FDC96864)

System shutdown begun: NO

Nice write up — thank you for compiling so much useful information about this bug!

Given your experience, what’s the best method for people to report a bug caused by Apple without wasting countless hours with tech support (for those of us without enterprise support)?

I have a pretty in-depth knowledge of operating systems and computer science, so it’s *really* frustrating when support won’t open an RTA until you try all of the rep’s steps (even when you know they’re unrelated or wrong). But even after humoring them, engineering has asked me to collect the same meaningless data 7 times now for a critical iMessage bug that started in October 2019 that’s still preventing all iMessages from being delivered to me (despite the sender seeing that it was delivered)... In February, I was able to reproduce the bug with a Genius Bar tech’s phone and a store floater phone, but this was *just* before Covid-19. Since they can’t share RTA#s, support can’t track down the case he was working since the store closed. That said, I had supplied ample screenshots, logs, sysdiagnose, etc. before resorting to a Genius Bar tech, but haven’t made any progress... And that’s just one of 15 (!) bugs I’ve reported since October. I’ve even opened bug reports via Feedback Assistant, but have yet to receive any response from engineering.

Apologies if I’m veering OT, but any tips or advice for receiving efffective AppleCare+ support would be greatly appreciated! Thanks again for writing such an in-depth summary of this bug — you saved me from the risk of trying the 15.5 beta as a potential work-around!