2018 MacBook Pros crashing with "Bridge OS" error

[SDColorado]

I kinda jinxed myself saying I haven’t had any issues with the replacement unit, but I am not sure it’s a T2/BridgeOS error this time either since no reports where generated.

But my MBP beach balled and froze. I had to do a restart and it simply hung at the Apple Logo.

So I turned it off and did a clean restart, but when I got to the login section, the fan just ramped up and then the machine shut down.

I did it again, letting it hang for a minute at the login screen and it ramped up and shut down.

If I type in the password right away it’s okay, but leave it at the login screen and it seems to do a thermal shut down?

 

[dspdoc]

Took a trip to the Apple store and put some of the 2018 mbp’s to sleep waiting 30 min or while browsing an updates on this forum and tried to wake them up...of course they don’t crash

looked at the setting and those sons of b****es took the precautions from this site loooool
(https://imgur.com/a/3CnNdSg)

I left a couple of them open on this thread, maybe it’ll get to the engineers faster that way

LOL so they got the memo from corporate.

 

[SDColorado]

Took a trip to the Apple store and put some of the 2018 mbp’s to sleep waiting 30 min or so while browsing any updates on this forum and tried to wake them up...of course they don’t crash

looked at the setting and those sons of b****es took the precautions from this site loooool
(https://imgur.com/a/3CnNdSg)

I left a couple of them open on this thread, maybe it’ll get to the engineers faster that way

Man, that is just too funny because that is exactly the settings the tech told me to use the first time I called Apple after the initial crash. Of course, he gave me the "This is the first we have ever heard of this" line, but it seems they are taking preventative measures in the stores.

 

[mediaprodguy]

LOL so they got the memo from corporate to setup the machines at the store to prevent a mess. How embarrassing.

I am floored this issue hasnt been resolved yet. Such a mess. Come' on, Apple....... We know Apple is rich/flush etc.... but to continue to sell the current MBP in this state is ridiclous.

Another thing driving me bonkers: Tech websites RECOMMENDING the MBP with this issue outstanding.

I keep coming here daily to find a fix or remedy. I appreciate everyones continued quest to solve the problem Apple wont.

 

[onelm]

LOL so they got the memo from corporate to setup the machines at the store to prevent a mess. How embarrassing.

...that's a bit of a leap It looks like they've just set them all to never sleep, probably because they need to be "instant on" if a consumer walks up to one and wants to have a play with it... It's also standard practice for them to set this on "battery mode" because a number of years ago, when battery resilience was not as good, it was common practice at Apple Retail to rotate MBPs on/off their chargers, but this varies a bit from store to store nowadays...

 

[kryptticAZ]

Man, that is just too funny because that is exactly the settings the tech told me to use the first time I called Apple after the initial crash. Of course, he gave me the "This is the first we have ever heard of this" line, but it seems they are taking preventative measures in the stores.

Isn't it also likely that they just don't want their display models to fall asleep so potential customers can play with them?

 

[csurfr]

Took a trip to the Apple store and put some of the 2018 mbp’s to sleep waiting 30 min or so while browsing any updates on this forum and tried to wake them up...of course they don’t crash

looked at the setting and those sons of b****es took the precautions from this site loooool
(https://imgur.com/a/3CnNdSg)

I left a couple of them open on this thread, maybe it’ll get to the engineers faster that way

Those settings have been on all of the machines at the Apple Store for years. It’s part of their MDM.

They also re-image every machine at least three times a week if not more often. It doesn’t have anything to do with this thread.

 

[dspdoc]

...that's a bit of a leap It looks like they've just set them all to never sleep, probably because they need to be "instant on" if a consumer walks up to one and wants to have a play with it... It's also standard practice for them to set this on "battery mode" because a number of years ago, when battery resilience was not as good, it was common practice at Apple Retail to rotate MBPs on/off their chargers, but this varies a bit from store to store nowadays...

I know, I was just trying to keep a sense of humor about it all.

 

[SDColorado]

Isn't it also likely that they just don't want their display models to fall asleep so potential customers can play with them?

Maybe so, but you have to admit it’s a bit dodgy that they were suggesting those settings to me as a solution to the problem.

It is a bit like the old joke, Man walks into the doctors office and says “doc, it hurts when i do this," and the doc says, "well then don't do that!"

 

[dspdoc]

Guess what ladies and gents... This is with the latest Mojave beta...

[doublepost=1535429209][/doublepost]I checked and it is a different T2 firmware version and Bridge OS version as well. So the issue remains even in the latest Mojave beta.

 

[onelm]

Guess what ladies and gents... This is with the latest Mojave beta...

Sigh....

If you still have the text of that crash log, can you confirm that with this Mojave crash it's still the AppleSMC process that has panicked as we've seen in most of the High Sierra cases?

 

[dspdoc]

Sigh....

If you still have the text of that crash log, can you confirm that with this Mojave crash it's still the AppleSMC process that has panicked as we've seen in most of the High Sierra cases?

Here you go...

 

[onelm]

Here you go...

Thanks. Confirmed, the panicked thread was "AppleSMC" as we've seen in High Sierra.

Can you post the output of the following terminal command:

kextstat | grep AppleSMC

You should get something that looks like this:

   13    9 0xffffff7f80f1a000 0x1d000    0x1d000    com.apple.driver.AppleSMC (3.1.9) 0249444C-80D4-3184-9060-F70DA3BEB17D <12 11 7 6 5 4 3 1>
   46    0 0xffffff7f83b75000 0x7000     0x7000     com.apple.driver.AppleSMCRTC (1.0) AEB04943-9980-3619-B053-86631F51A6FC <13 11 7 5 4 3 1>

The above is from High Sierra 10.13.6 -- I'm just curious what version of AppleSMC is currently in the Mojave beta...

 

[dspdoc]

Thanks. Confirmed, the panicked thread was "AppleSMC" as we've seen in High Sierra.

Can you post the output of the following terminal command:

kextstat | grep AppleSMC

You should get something that looks like this:

   13    9 0xffffff7f80f1a000 0x1d000    0x1d000    com.apple.driver.AppleSMC (3.1.9) 0249444C-80D4-3184-9060-F70DA3BEB17D <12 11 7 6 5 4 3 1>
   46    0 0xffffff7f83b75000 0x7000     0x7000     com.apple.driver.AppleSMCRTC (1.0) AEB04943-9980-3619-B053-86631F51A6FC <13 11 7 5 4 3 1>

The above is from High Sierra 10.13.6 -- I'm just curious what version of AppleSMC is currently in the Mojave beta...

Here you go:

13 8 0xffffff7f80d71000 0x1e000 0x1e000 com.apple.driver.AppleSMC (3.1.9) 7D84923F-D6E9-351D-9B6D-99D3E25FCA1A <12 11 7 6 5 4 3 1>

47 0 0xffffff7f83c6b000 0x7000 0x7000 com.apple.driver.AppleSMCRTC (1.0) 13B40415-9B63-3DF3-BB12-538E8382DEFC <13 11 7 5 4 3 1>

iMac-Pro:~

 

[onelm]

Here you go:

13 8 0xffffff7f80d71000 0x1e000 0x1e000 com.apple.driver.AppleSMC (3.1.9) 7D84923F-D6E9-351D-9B6D-99D3E25FCA1A <12 11 7 6 5 4 3 1>

47 0 0xffffff7f83c6b000 0x7000 0x7000 com.apple.driver.AppleSMCRTC (1.0) 13B40415-9B63-3DF3-BB12-538E8382DEFC <13 11 7 5 4 3 1>

...so based on that, the Mojave AppleSMC driver is the same version as in High Sierra. If the bug has anything to do with what's in there, I wouldn't hold out much hope for a Mojave fix... :-/

 

[dspdoc]

...so based on that, the Mojave AppleSMC driver is the same version as in High Sierra. If the bug has anything to do with what's in there, I wouldn't hold out much hope for a Mojave fix... :-/

That is a frightening thought.

 

[shawndebnath]

After 10 days, my machine finally crashed again. I say crash because upon reboot, I didn't see a error reporting dialog nor any new logs under System Reports > ProxiedDevice-Bridge. Sad since I lost some context that I had in an IDE. Machine was sleeping for ~20 mins with just power connected.

 

[kryptticAZ]

Guess what ladies and gents... This is with the latest Mojave beta...

View attachment 778249
[doublepost=1535429209][/doublepost]I checked and it is a different T2 firmware version and Bridge OS version as well. So the issue remains even in the latest Mojave beta.

Didn't you get rid of both of your T2 machines, or am I mistaken? When did this crash occur? During sleep?

 

[rurza]

Thanks. Confirmed, the panicked thread was "AppleSMC" as we've seen in High Sierra.

Where there is info about crashed "thread" related to AppleSMC?

It's clear that people here have different issues related to T2's firmware – I had problems with wake ups, booting the OS and cursor stutters + info about kernel panic related to bridgeOS but firmware upgrade did helped (help?) in my case...

 

[dspdoc]

Didn't you get rid of both of your T2 machines, or am I mistaken? When did this crash occur? During sleep?

I decided to keep my iMac Pro. It happened the moment the machine went to sleep.

 

[onelm]

Where there is info about crashed "thread" related to AppleSMC?

It's clear that people here have different issues related to T2's firmware – I had problems with wake ups, booting the OS and cursor stutters + info about kernel panic related to bridgeOS but firmware upgrade did helped (help?) in my case...

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:

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>

 

[matthewadams]

Happily adding my work-computer (13" 2018 MBP) to the list (after my previous crashes on my private 15" MBP):

{"caused_by":"macos","macos_system_state":"running","bug_type":"210","os_version":"Bridge OS 2.4.1 (15P6703)","timestamp":"2018-08-28 11:05:09.36 +0000","incident_id":"D62B0A64-9F74-456B-A2E2-EEFFF71453C7"}
{
  "binaryImages" : [
    [
      "26cb7ffe-c7aa-68dd-8fce-c101101c7e4e",
      18446743936270598144,
      "U"
    ],
    [
      "00000000-0000-0000-0000-000000000000",
      0,
      "A"
    ],
    [
      "6c67aa31-2522-38c5-8373-088d4645ed4f",
      6442450944,
      "S"
    ]
  ],
  "build" : "Bridge OS 2.4.1 (15P6703)",
  "crashReporterKey" : "c0dec0dec0dec0dec0dec0dec0dec0dec0de0001",
  "date" : "2018-08-28 11:05:08.98 +0000",
  "incident" : "D62B0A64-9F74-456B-A2E2-EEFFF71453C7",
  "kernel" : "Darwin Kernel Version 17.7.0: Fri Jul  6 19:25:51 PDT 2018; root:xnu-4570.71.3~1\/RELEASE_ARM64_T8010",
  "macOSOtherString" : "\n** In Memory Panic Stackshot Succeeded ** Bytes Traced 1042176 **\n",
  "macOSPanicFlags" : "0x4",
  "macOSPanicString" : "panic(cpu 2 caller 0xffffff8007b28f5f): \"userspace panic: remoted connection watchdog expired, no updates from  remoted monitoring thread in 74 seconds\"@\/BuildRoot\/Library\/Caches\/com.apple.xbs\/Sources\/xnu\/xnu-4570.71.3\/bsd\/kern\/kern_shutdown.c:154\nBacktrace (CPU 2), Frame : Return Address\n0xffffff920761ba80 : 0xffffff800766c1c6 \n0xffffff920761bad0 : 0xffffff8007795344 \n0xffffff920761bb10 : 0xffffff80077875c4 \n0xffffff920761bb80 : 0xffffff800761e1e0 \n0xffffff920761bba0 : 0xffffff800766bc3c \n0xffffff920761bcd0 : 0xffffff800766b9fc \n0xffffff920761bd30 : 0xffffff8007b28f5f \n0xffffff920761bdf0 : 0xffffff8007b405cf \n0xffffff920761bf40 : 0xffffff8007c03b68 \n0xffffff920761bfa0 : 0xffffff800761e9c6 \n\nBSD process name corresponding to current thread: watchdogd\n\nMac OS version:\n17G2208\n\nKernel version:\nDarwin Kernel Version 17.7.0: Fri Jul  6 19:54:51 PDT 2018; root:xnu-4570.71.3~2\/RELEASE_X86_64\nKernel UUID: AA72F0D4-894C-372F-B168-7F3EE869AE03\nKernel slide:     0x0000000007400000\nKernel text base: 0xffffff8007600000\n__HIB  text base: 0xffffff8007500000\nSystem model name: MacBookPro15,2 (Mac-827FB448E656EC26)\n\nSystem uptime in nanoseconds: 23603434904267\nlast loaded kext at 15081368862395: ...

Has anyone ever gotten a "regular" Kernel Panic? I believe BridgeOS collects both BridgeOS and MacOS Crashes now, instead of the old school way of letting OSX dump the kernel panic.

 

[IG88]

Correct I use my MBP daily and is been stable. I've not had one crash.

You're holding it wrong.
- Steve Jobs, probably

 

[csurfr]

Guess what ladies and gents... This is with the latest Mojave beta...

View attachment 778249
[doublepost=1535429209][/doublepost]I checked and it is a different T2 firmware version and Bridge OS version as well. So the issue remains even in the latest Mojave beta.

Damn man. I know it means little to nothing, but I’m sorry you’re going through this. I know you have to be about to throw that thing out of the window right now.

It would be one thing if it crashed during sleep, but once it starts to crash while you’re actively using it...

You are experiencing what I went through with the 2016 MacBook Pro. The only difference is I went through about 4 machines before I happened to get one that didn’t have issues right out of the box. Are you able to replicate the crash essentially on command at this point?

While I wasn’t sure that the new beta fixed it (how can I / any of us be), I was hopeful. I think what one of the members above said is very interesting, in that he was asking if BridgeOS is just the task that is reporting the actual crash, and perhaps not necessarily the cause of the crash itself. That just goes to show how little we really know about how the T2 is tied into the machine as a whole.

You’re still in touch with Apple, yeah? Have they offered you anything at all? Send in for repair, data capture, etc? With my 2016 they had me install the capture utility which logged nearly everything and sent it to them as a .dmg.

Edit: meanwhile: https://www.macrumors.com/2018/08/28/2018-iphone-shipments-highest

Makes you wonder if macOS is still a high priority, doesn’t it?

 

[onelm]

Happily adding my work-computer (13" 2018 MBP) to the list (after my previous crashes on my private 15" MBP):

Has anyone ever gotten a "regular" Kernel Panic? I believe BridgeOS collects both BridgeOS and MacOS Crashes now, instead of the old school way of letting OSX dump the kernel panic.

I think we're seeing more hints that BridgeOS is in the logs because it's collecting the crash info now...

Your crash is the first I've seen in this thread that says it's in user space. Was this crash during sleep/wake or just during normal operation? Can you share the details of what process (presumably it was not kernel_task) and thread panicked? Instructions for finding that info are in the link I shared a few posts above, which will take you back to post #1264