I'll be enabling FileVault (never enabled it in my MBA, and I wasn't robbed in all the 8 years I've been using it as my tool when traveling, but now I realize that's been too risky on my part... I'll really enable it on the MBP when it arrives, I hope not to run into too much KPs because of FileVault...)
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
2018 MacBook Pros crashing with "Bridge OS" error
- Thread starter kryptticAZ
- Start date
- Sort by reaction score
You never do know. A friend of mine never had his robbed in all the years he had been traveling either, but someone broke into his home last year and stole it. You can't be too careful.
My latest auto-reboot happened on day 30 at 10pm, Apple had agreed around day 10 to extend my return period to 30 days.
No victims, only volunteers.
Apple has been replacing afflicted units. Dont tough it out. Get a swap.
[doublepost=1537484987][/doublepost]
They keep taking them back when people have this issue. There are plenty of units that work perfectly including my wife's top of the line 2.9 monster over on her desk. The one I owned briefly was also fine. The people in store will let you return it at day 15 and if they dont just call in and get on with a senior advisor theyre all aware of the issue and know how to handle it.
Swapping is still inconvenient to the customer. So victim is the right word. Apple must have made the product which is not broken. Warranty fixes the design error for specific unit (not so much, considering another unit might be affected as well). But the design error is still there. Having warranty does not negate the presence of the error.
Apple have been replacing units with broken video, with broken display (staingate), with broken keyboard etc... with the same, broken from the start components. Grateful is not the word customers should use in such a case.
[doublepost=1537488129][/doublepost]
Unfortunately this experience varies very much.
Its not a warranty issue. Its a "my unit does this thing that is highly documented and resolvable through swapping the unit out." I wouldn't stop until they swapped it. Retail is a harder game over 14 days, they have the ability to do up to 30 usually and over 30 very seldom but not unheard of. AppleCare Tier 2 and above can take care of it much easier and will have more at their fingertips knowledge. I wouldn't waste too much time with retail if they're a no, but a portables specialist at AppleCare should be able to assist. Just say you've gone through all the steps they ask you to do. Did you reinstalled the OS? Yes I did. Did you run it for a few days without 3rd party software? Yes I did, it still crashed. Everything they ask you just say you did it and it still happened. They'll swap it.
I hate to use the word “victim,” but it sure is frustrating, especially if it as a CTO machine. You wait a couple of weeks for it to arrive, set it up, have issues, start the return process. Order a new one, wait for it to arrive, set it up, use it, have issues, start the return process, wait for another to arrive. The process begins to suck the joy out of owning it. I called it quits after #3. Enough was enough.
FYI the version of macOS that installs in internet recovery does not have supplemental update 2 included. I didn't realize this until today when I had a weird "update failed" restart that I had never had before. Installed it after restoring from Time Machine so we'll see how that all goes. I have an appointment to try to exchange on Tuesday.
At least in my case, the "report" button never even appears. The machine powers off instantly (not even showing the kernel panic screen), and upon restart, acts as if nothing was amiss. I only found the crash logs by digging into the corresponding directories.
Tell them its business critical. They can perhaps jog you to the front of the line.
You get jogged to the front of the line and they expedite shipping, but none of that matters until it clears customs and reaches the USA.
Is there a way of reporting these logs to Apple? They should have a team thatćs working on this issue...
So far this issue is the only thing preventing me to pull the trigger and buy a MBP.
I've recently had a reboot of my machine as well and only found out about it because it was asking me to enter my password instead of letting me use Touch ID to log in (I had no apps open before). Unfortunately, I only thought about it a bit later because I was in a hurry when it happened. Can someone point me to the exact location of the log file I need to check in order to find out what the reason for the reboot was? Where exactly would I find out that my machine is affected from the BridgeOS issue as well? It's a brand-new 2018 Macbook Pro, maxed out except for the hard drive (2TB). I had a look around in the console but would appreciate a hint on which file I need to check exactly there.
I really don't know what's happening with this issue. Some people say some units are not affected. If that was true, some T2 chips would be defective and other T2 chips would be fine, and then, all units that were assembled in the last weeks would be fine, but we have reports from recent units having the issue. So, the reason isn't hardware, and the fact that some people suffer the issue and others not, shouldn't be because of hardware, but because of different software being used, different settings being enabled (FileVault, energy saving, sleep configuration, etc, etc, and combinations of these settings that can be set different across different users), and also because of the fact that some people use the computer in some ways, and others in another (some people are making the MBP sleep many times everyday, while others never make it sleep, or in very little occasions).
That's my feeling, because, otherwise, all new units should have fine T2 chips as of now. My guess is that all units have good hardware (I mean from this BridgeOS issue point of view only), and the problem is at MacOS, BridgeOS, and firmware. Some users hit it because of settings combinations, installed software, and their ways of using the MBP, and other users don't hit it.
That's my feeling, because, otherwise, all new units should have fine T2 chips as of now. My guess is that all units have good hardware (I mean from this BridgeOS issue point of view only), and the problem is at MacOS, BridgeOS, and firmware. Some users hit it because of settings combinations, installed software, and their ways of using the MBP, and other users don't hit it.
https://support.apple.com/en-us/HT204904 installing with command opt r will install the most recent available version which I did the other day and got 10.13.6, no supplemental update 2.
Agreed. It's hard to tell what is the main problem and seems very complicated to determine the issue due to settings what people set. I was suspicious hardware (even guys at Genius Bar told me this is hardware issue) but, now I feel like it would be some conflicts in Bridge OS with USB connection or sleep mode since it seems like quite solving problems with another update or Mojave OS.
(or still it's hardware problem but Apple programmed not using some part of T2 chip that makes the trouble with new T2 firmware)
Still could be either hardware or software..
At least on mine, they showed up under /Library/Logs/DiagnosticReports/ProxiedDevice-Bridge. You can get to that from the terminal or Console app. Within there, there are files starting with panic-full-*
Just had my first one of these waking up in the morning and having to log in.
Looks like a FW issue to me.
[doublepost=1537582823][/doublepost]Just had my first one of these this morning. Looks like a firmware issue to me.
Looks like a FW issue to me.
[doublepost=1537582823][/doublepost]Just had my first one of these this morning. Looks like a firmware issue to me.
If it’s hardware, then either it is a bug in the silicon (and then it affects all units until they do a new revision of the chip), or it’s a defective batch (but as I said above, I think this last possibility can be discarded, because they would have detected the defective batch, and new units from September wouldn’t be suffering this issue).
My experience at fixing bugs tells me that this issue affects all units the same, and there are no units suffering it and others unaffected, but users (or use/settings combinations scenarios) triggering the issue, and others not triggering it.
Of course, this cannot rule out a bug in the T2 silicon, but it can rule out fabrication problems, as they would be fixed in recent units, and they are not.