Kernel Panic on 16" i9 MBPwRD

Had the same issue again today after today's update (10.15.4 (19E287)).

So USB-C fix did not do anything about it, sadly :-/

panic(cpu 4 caller 0xffffff8008816487): "AppleIntelFramebuffer::setPowerState(0xffffff81b7ab0000 : 0xffffff7f8bdf9d88, 1 -> 0) timed out after 45964 ms"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.101.6/iokit/Kernel/IOServicePM.cpp:5296
Backtrace (CPU 4), Frame : Return Address
0xffffff81f9ed3b40 : 0xffffff80081215cd 
0xffffff81f9ed3b90 : 0xffffff800825a3c5 
0xffffff81f9ed3bd0 : 0xffffff800824bf7e 
0xffffff81f9ed3c20 : 0xffffff80080c7a40 
0xffffff81f9ed3c40 : 0xffffff8008120c97 
0xffffff81f9ed3d40 : 0xffffff8008121087 
0xffffff81f9ed3d90 : 0xffffff80088c2c7c 
0xffffff81f9ed3e00 : 0xffffff8008816487 
0xffffff81f9ed3e50 : 0xffffff8008815d69 
0xffffff81f9ed3e60 : 0xffffff800882d2fe 
0xffffff81f9ed3ea0 : 0xffffff8008814b18 
0xffffff81f9ed3ec0 : 0xffffff8008163545 
0xffffff81f9ed3f40 : 0xffffff8008163071 
0xffffff81f9ed3fa0 : 0xffffff80080c713e 

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:     0x0000000007e00000
Kernel text base: 0xffffff8008000000
__HIB  text base: 0xffffff8007f00000
System model name: MacBookPro16,1 (Mac-E1008331FDC96864)
System shutdown begun: NO
System uptime in nanoseconds: 16793191502905
last loaded kext at 15588013917321: >usb.IOUSBHostHIDDevice	1.2 (addr 0xffffff7f8ca0f000, size 45056)
last unloaded kext at 4648926173899: >!AXsanScheme	3 (addr 0xffffff7f8bdcf000, size 32768)

Thanks for confirming. That’s disappointing to say the least...

It looks like this happened ~4.5 hours after the last boot. If you don’t mind me asking,

1. Do you recall how long the system was awake before this crash?
2. Was the system under heavy load (e.g. managing raw camera files, video files, gaming, etc.)?
3. Was the system plugged in or on battery?
4. Do you have power nap enabled or disabled?

FWIW, I’m getting the same crash regardless of power nap settings, but others have reported improvements/fixes...

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.

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 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.

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)!

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!

@vrtx0

Are you confirming that reverting back to 10.15.3 fixes the issue? I totally get how that is not a good solution but that information could help others that might want to revert back if they can!

[Edited by Moderator]

@ClassicII

I did not experience a kernel panic during sleep while I was back on 10.15.3. Unfortunately I only ran it for ~24 hours, though it did sleep 3-4 times. After going back to 10.15.4 (with supplemental update), I encountered the panic second time the computer went to sleep (uptime ~5 hours).

Wish I had a better datapoint for you — really appreciate all the effort you put into your site! If time permits, I’ll try the latest public beta and post any results w/ crash logs.

Thanks, this sure gives me some peace of mind :)

BTW: With power nap turned off it woke up just fine this morning. If that fixes the issue for the time being I‘d rather not go through the hassle of downgrading to be honest.

MBP has not went into panic after Sleep since the following actions for about 5 days (sleeping at least once daily):

1. Updated macOS Catalina 10.15.4 Supplemental Update https://support.apple.com/kb/DL2038?locale=en_US
2. Reset PRAM/VRAM and SMC
3. Disabled PowerNap in Energy Saver for Battery and Power Adapter

However, the MBP sadly just crashed again after awaking it from sleep mode.

panic(cpu 0 caller 0xffffff8019a91b2c): Sleep transition timed out after 180 seconds while calling power state change callbacks.

So, I finally got a (rather infuriating) reply from Apple on the Feedback Assistant case I opened on April 9th. I already collected and sent sysdiagnose data via support, and even referenced the support ticket number in my feedback case. The last response I got from support stated they had enough data to work on this bug, but I’ll go ahead and collect/send this data *again*, unless anybody has heard they already have enough data...

Does everybody have to go through this nonsensical back-and-forth with Apple when you find a bug, or is it just me? Here’s what I just received:

“We need additional information in order to continue investigating this bug. We need sysdiagnose output collected immediately following reboot to recover from panic in order to trige this.”

vrtx0 wrote:

So, I finally got a (rather infuriating) reply from Apple on the Feedback Assistant case I opened on April 9th. I already collected and sent sysdiagnose data via support, and even referenced the support ticket number in my feedback case. The last response I got from support stated they had enough data to work on this bug, but I’ll go ahead and collect/send this data *again*, unless anybody has heard they already have enough data...

Does everybody have to go through this nonsensical back-and-forth with Apple when you find a bug, or is it just me? Here’s what I just received:

“We need additional information in order to continue investigating this bug. We need sysdiagnose output collected immediately following reboot to recover from panic in order to trige this.”

If you filed a bug report then you where selected to help sort it out; It is not always the case.

You do no have to reply if you are worn out.

Thank you for your service.