See my post here:
https://forums.macrumors.com/thread...bridge-os-error.2128976/page-51#post-26384166
What we're seeing in these crash logs is a kernel panic where PID #0 (kernel_task) is the panicked "task". But a lot of different things run under the kernel_task process--all your drivers, etc. So when we dig into it a bit more and look for which _thread_ panicked, it is consistently coming up as AppleSMC.
I'm not 100% sure about how to read these logs that start with mentions of BridgeOS, but they really all look like
macOS kernel panics. The link these have to Bridge OS is still unclear to me. Is Bridge OS crashing and taking down AppleSMC driver with it? Is AppleSMC a/the connection point between macOS (running on the main CPU) and Bridge OS (running on the T2), now that T1/T2 chips are doing what the SMC used to do? Is Bridge OS just sending a bad message to macOS that the AppleSMC driver can't handle? Or is Bridge OS just doing some higher level crash reporting? etc etc.
It doesn't feel like Bridge OS is just simply "crashing", particularly since I would think that any sane engineers would have had enough isolation between Bridge OS and macOS so that even if BridgeOS on the T2 crashed hard, it would still fail gracefully and not take down macOS with it... Seems much more likely that there's some sort of "miscommunication"... One test I want to run in the next week is whether we'd see Windows crash in the same sleep scenarios--Windows would have a completely different driver stack (albeit one that
could share some idiosyncrasies with macOS since apple presumably wrote both drivers)... it'd be a great data point.
I just scanned StudioSanctum's most recent crash log again, and he had a much more specific message in his panicString:
Code:
Stackshot Reason: Wake
transition timed out after 180 seconds while calling power state
change callbacks. Suspected bundle: com.uaudio.driver.UAD2System
...That's interesting, as it is actually calling out that uaudio driver (even though it was AppleSMC that panicked), whereas in most of the other crashlogs I've taken a look at, the panicString has had a bit more ... generic description, such as "Sleep\/Wake hang detected" or "x86 global reset detected"
Update: reading this panicString again, it reads as if various drivers such as the uaudio driver are registered with the OS to be told when the power state changes (the "power state change callbacks"). Maybe AppleSMC is managing those callbacks. In the case here, it reads as if the system was trying to tell drivers that the power state changed, but something caused it to hang which has prevented the entire power state transition, and perhaps AppleSMC gets grumpy when that happens? Anyway, it all seems very software-ish to me. <crossing fingers>
