2018 MacBook Pros crashing with "Bridge OS" error

[KDLM]

Well, mine hasn’t had any in 5 days. Maybe it’s an application you use to cause it, or something you do? Hmm.
[doublepost=1544497710][/doublepost]

Well, explain why two people have no issues and you do. Wondering if it’s something you are doing that’s causing it.

As far as explaining why two people have no issues and I do, that logic does not apply. Already, with the pre-Vega 20 MBPs, there were plenty of people who were having issues and more who weren't. All I can tell you is that the issue definitely was not resolved for all Vega 20 MBPs. My first one was doing the same things I've seen mentioned in many posts and some videos on YT.

As far as what I was doing with my first MBP being the problem, I wasn't doing much of anything with it, yet. I had to get it up to speed to replace an iMac with it. But I never got to that point because it was having so many crashes with it that I could not rely on it. Could the problem be some app? I suppose, but many here say there is some type of hardware issue. Regardless, even if it is an app, all the issues with my first MBP Vega 20 prove that the problem has not been resolved.

Two of you have MBP Vega 20s that are working fine. I think my new one is, too. However, that does not put us in a different boat than all of the other 2018 MBP owners. Some experience issues, some do not.

 

[Plutonius]

Well, explain why two people have no issues and you do. Wondering if it’s something you are doing that’s causing it.

It could be random probability that some people get good machines while others don't.

 

[Dracarris]

Okay, so I guess I have the exact same (family of?) issue(s). I thought I'd share my experience too, maybe it will help anyone. I have a shiny, almost new Macbook Pro 13", 512GB and 16GB. The machine was bought on early October and at first it ran quite smooth and reliably for weeks. Now,

ls -l /Library/Logs/DiagnosticReports/ProxiedDevice-Bridge/panic*

shows:

panic-full-2018-11-17-232046.476.ips
panic-full-2018-11-25-180249.545.ips
panic-full-2018-11-30-094621.363.ips
panic-full-2018-12-03-162040.093.ips

I am pretty sure there has been at least one crash before 11-17, don't know where I could reports related to this.
Now problem is I am way out of my return period and I am thinking about ways to get Apple to replace my Macbook with a new one as I definitely want to give it a try to get a fully working one. As others have reported here there is a non-negligible chance..

I am by the way still on High Sierra, reading the lack of success of people updating to most recent Mojave I am however a bit reluctant to think that upgrading would do any good.

Cheers

 

[betadecay]

Okay, so I guess I have the exact same (family of?) issue(s). I thought I'd share my experience too, maybe it will help anyone. I have a shiny, almost new Macbook Pro 13", 512GB and 16GB. The machine was bought on early October and at first it ran quite smooth and reliably for weeks. Now,

ls -l /Library/Logs/DiagnosticReports/ProxiedDevice-Bridge/panic*

shows:

panic-full-2018-11-17-232046.476.ips
panic-full-2018-11-25-180249.545.ips
panic-full-2018-11-30-094621.363.ips
panic-full-2018-12-03-162040.093.ips

I am pretty sure there has been at least one crash before 11-17, don't know where I could reports related to this.
Now problem is I am way out of my return period and I am thinking about ways to get Apple to replace my Macbook with a new one as I definitely want to give it a try to get a fully working one. As others have reported here there is a non-negligible chance..

I am by the way still on High Sierra, reading the lack of success of people updating to most recent Mojave I am however a bit reluctant to think that upgrading would do any good.

Cheers

What does the KP report at "macOSPanicString": .... ?

 

[Dracarris]

What does the KP report at "macOSPanicString": .... ?

First KP says:

"panicString" : "panic(cpu 1 caller 0xfffffff0282e29f4): macOS watchdog detected\nDebugger message: panic\nMemory ID: 0xff\nOS version: 16P375\nKernel version: Darwin Kernel Version 18.0.0: Thu Sep 6 18:24:30 PDT 2018; root:xnu-4903.201.2~72\/RELEASE_ARM64_T8010\nKernelCache UUID: 834FD638CEB95664A35EB86DC49DF634\nKernel UUID: 4A1BD27F-3E02-3C61-8254-E173B853B18F\niBoot version: iBoot-4513.200.293\nsecure boot?: YES\nx86 EFI Boot State: 0xd\nx86 System State: 0x0\nx86 Power State: 0x0\nx86 Shutdown Cause: 0x5\nx86 Previous Power Transitions: 0x10001000100\nPCIeUp link state: 0x14\nPaniclog version: 11\nKernel slide: 0x0000000021c00000\nKernel text base: 0xfffffff028c04000\nEpoch Time: sec usec\n Boot : 0x5bb89c74 0x000cd714\n Sleep : 0x5bf08b72 0x0001a312\n Wake : 0x5bf08cf9 0x0006e9ee\n Calendar: 0x5bf0a230 0x0003ec4c\n\nPanicked task 0xffffffe00016e760: 5368 pages, 208 threads: pid 0: kernel_task\nPanicked thread: 0xffffffe000494f90, backtrace: 0xffffffe01615b530, tid: 400\n\t\t lr: 0xfffffff028e012ec fp: 0xffffffe01615b670\n\t\t lr: 0xfffffff028cdd610 fp: 0xffffffe01615b680\n\t\t lr: 0xfffffff028d11ce8 fp: 0xffffffe01615b9f0\n\t\t lr: 0xfffffff028d12060 fp: 0xffffffe01615ba30\n\t\t lr: 0xfffffff028d13c98 fp: 0xffffffe01615ba50\n\t\t lr: 0xfffffff0282e29f4 fp: 0xffffffe01615bac0\n\t\t lr: 0xfffffff0282e4e7c fp: 0xffffffe01615bb60\n\t\t lr: 0xfffffff0282e21c0 fp: 0xffffffe01615bbe0\n\t\t lr: 0xfffffff02829bab0 fp: 0xffffffe01615bc10\n\t\t lr: 0xfffffff02919c0fc fp: 0xffffffe01615bc50\n\t\t lr: 0xfffffff02919b964 fp: 0xffffffe01615bc90\n\t\t lr: 0xfffffff028ce8614 fp: 0x0000000000000000\n\n",

Most recent says:

"panicString" : "panic(cpu 1 caller 0xfffffff01d6e29f4): macOS watchdog detected\nDebugger message: panic\nMemory ID: 0xff\nOS version: 16P375\nKernel version: Darwin Kernel Version 18.0.0: Thu Sep 6 18:24:30 PDT 2018; root:xnu-4903.201.2~72\/RELEASE_ARM64_T8010\nKernelCache UUID: 834FD638CEB95664A35EB86DC49DF634\nKernel UUID: 4A1BD27F-3E02-3C61-8254-E173B853B18F\niBoot version: iBoot-4513.200.293\nsecure boot?: YES\nx86 EFI Boot State: 0xd\nx86 System State: 0x0\nx86 Power State: 0x0\nx86 Shutdown Cause: 0x5\nx86 Previous Power Transitions: 0x10001000100\nPCIeUp link state: 0x14\nPaniclog version: 11\nKernel slide: 0x0000000017000000\nKernel text base: 0xfffffff01e004000\nEpoch Time: sec usec\n Boot : 0x5c0106e7 0x000beada\n Sleep : 0x5c04f032 0x00002ff6\n Wake : 0x5c04f2a7 0x000d750a\n Calendar: 0x5c0557b8 0x000706a9\n\nPanicked task 0xffffffe00012a1c0: 3426 pages, 208 threads: pid 0: kernel_task\nPanicked thread: 0xffffffe0004fe450, backtrace: 0xffffffe0162cb530, tid: 392\n\t\t lr: 0xfffffff01e2012ec fp: 0xffffffe0162cb670\n\t\t lr: 0xfffffff01e0dd610 fp: 0xffffffe0162cb680\n\t\t lr: 0xfffffff01e111ce8 fp: 0xffffffe0162cb9f0\n\t\t lr: 0xfffffff01e112060 fp: 0xffffffe0162cba30\n\t\t lr: 0xfffffff01e113c98 fp: 0xffffffe0162cba50\n\t\t lr: 0xfffffff01d6e29f4 fp: 0xffffffe0162cbac0\n\t\t lr: 0xfffffff01d6e4e7c fp: 0xffffffe0162cbb60\n\t\t lr: 0xfffffff01d6e21c0 fp: 0xffffffe0162cbbe0\n\t\t lr: 0xfffffff01d69bab0 fp: 0xffffffe0162cbc10\n\t\t lr: 0xfffffff01e59c0fc fp: 0xffffffe0162cbc50\n\t\t lr: 0xfffffff01e59b964 fp: 0xffffffe0162cbc90\n\t\t lr: 0xfffffff01e0e8614 fp: 0x0000000000000000\n\n",

I hope this is what you were asking for?

At the beginning there is the usual

"caused_by":"macos","macos_system_state":"running","bug_type":"210","os_version":"Bridge OS 3.0 (16P375)"

 

[KDLM]

Okay, so I guess I have the exact same (family of?) issue(s). I thought I'd share my experience too, maybe it will help anyone. I have a shiny, almost new Macbook Pro 13", 512GB and 16GB. The machine was bought on early October and at first it ran quite smooth and reliably for weeks. Now,

ls -l /Library/Logs/DiagnosticReports/ProxiedDevice-Bridge/panic*

shows:

panic-full-2018-11-17-232046.476.ips
panic-full-2018-11-25-180249.545.ips
panic-full-2018-11-30-094621.363.ips
panic-full-2018-12-03-162040.093.ips

I am pretty sure there has been at least one crash before 11-17, don't know where I could reports related to this.
Now problem is I am way out of my return period and I am thinking about ways to get Apple to replace my Macbook with a new one as I definitely want to give it a try to get a fully working one. As others have reported here there is a non-negligible chance..

I am by the way still on High Sierra, reading the lack of success of people updating to most recent Mojave I am however a bit reluctant to think that upgrading would do any good.

Cheers

@Dracarris - It's very depressing to hear that the problems can crop up after weeks of your MacBook working fine. I am fully sympathetic with your desire to exchange your MacBook for a fully-working one, however, given your experience, now I wonder if there is any point. If the problems can crop up weeks later, how will any of us ever know if we have a MB that is truly unaffected? I have Apple Care, so I guess I'll just stick with the MBP even if my replacement one has issues. Then, down the road, I'll make a pest of myself with repeated service demands and see if they'll do anything for me (again, if I start having problems, and once there is a true solution, presuming that solution isn't just an update I can install).

 

[betadecay]

Thanks! In my case I observe three different kinds of Panic string, where the most frequent is "thunderbolt power on failed". Maybe its possible to narrow down the problem in this way...

Some member stated that most KP's reported by BridgeOS as the T2 chip manages different things.
However, in most cases users report that the machine reboots instead of awakening and a KP pops up starting with:

{"caused_by":"macos","macos_system_state":"running","bug_type":"210","os_version":"Bridge OS 3.1 (16P1065)","timestamp":"2018-11-06 05:43:11.83 +0000","incident_id":"D66C632B-1EBC-471B-8696-6AC8377472DA"}

But what is about the rest of the report? In example some reports show:

1. "macOSPanicString" : "panic(cpu 0 caller 0xffffff7f976f3307): \"DSB0(MacBookPro15,2): thunderbolt power on failed 0xffffffff\n\"@\/BuildRoot\/Library\/Caches\/com.apple.xbs\/Sources\/IOPCIFamily\/IOPCIFamily-330.200.11\/IOPCIBridge.cpp:1314\nBacktrace (CPU 0),
   
   
2. "macOSPanicString" : "panic(cpu 0 caller 0xffffff800fcc306f): UUID: 47D2BC26-0426-428C-A375-59C980C76CFE\nStackshot Reason: Sleep transition timed out after 180 seconds while entering darkwake on way to sleep. Suspected bundle: com.apple.driver.usb.AppleUSBXHCI. Thread 0x639c8.\
   
   
3. "macOSPanicString" : "panic(cpu 0 caller 0xffffff8006678792): \"Restart timed out in phase 'Quiescing PM'. Total 30000 ms:\nvfs_unmountall: 1214 ms\nif_down_all: 127 ms\nPowerOff\/Restart message to priority client: 362 ms @ 0x<ptr>, com.apple.driver.IOBluetoothHIDDriver(6.0.9f2)[C65C951F-5EA3-3567-888E-9426F9C6C9CE]@0x<ptr>->0x<ptr>\nPowerOff\/Restart message to priority client: 220 ms @ 0x<ptr>, com.apple.driver.IOBluetoothHIDDriver(6.0.9f2)[C65C951F-5EA3-3567-888E-9426F9C6C9CE]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 188 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 200 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 207 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 209 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 218 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 291 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 506 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\nPowerOff\/Restart handler completed: 233 ms @ 0x<ptr>, com.apple.iokit.IOUSBHostFamily(1.2)[922E7520-229B-3C68-B232-A8727A20D44D]@0x<ptr>->0x<ptr>\n\"@\/BuildRoot\/Library\/Caches\/com.apple.xbs\/Sources\/xnu\/xnu-4903.221.2\/iokit\/Kernel\/IOPMrootDomain.cpp:4804\n

But all start with
{"caused_by":"macos","macos_system_state":"running","bug_type":"210","os_version":"Bridge OS 3.1 (16P1065)",...

In my case the most frequent KP is 1.)

What's about you guys?
Use the search option in "Console" to search for >macOSPanicString<.

Cheers

 

[Dracarris]

@Dracarris - It's very depressing to hear that the problems can crop up after weeks of your MacBook working fine. I am fully sympathetic with your desire to exchange your MacBook for a fully-working one, however, given your experience, now I wonder if there is any point. If the problems can crop up weeks later, how will any of us ever know if we have a MB that is truly unaffected? I have Apple Care, so I guess I'll just stick with the MBP even if my replacement one has issues. Then, down the road, I'll make a pest of myself with repeated service demands and see if they'll do anything for me (again, if I start having problems, and once there is a true solution, presuming that solution isn't just an update I can install).

Yes, exactly. Is there a place where ALL KPs/unexpected reboots are documented? I still think that there has been a crash around 2-3 weeks after I got the machine and now with this T2 disaster I want to find out more about the reason for it.
[doublepost=1544520933][/doublepost]

Thanks! In my case I observe three different kinds of Panic string, where the most frequent is "thunderbolt power on failed". Maybe its possible to narrow down the problem in this way...

Okay I looked in the wrong place, if I search for macOSPanicString in the Console, I only get ""macOSPanicString" : "BAD MAGIC! (flag set in iBoot panic header), no macOS panic log available"," for all four KP reports.

 

[solouki]

First KP says:

Dracarris,

I see that your first crash report says that thread id 400 caused the crash. Do you mind searching for this tid lower down in your crash report to find the name of this thread? And your second crash report gave a thread id of 392, please search for this tid and find its name. Thanks.

For four of my KPs, I found that the crashing threads were all linked to AppleSMC. I don't know if it was really the SMC that was crashing, or just that all kernel panics end up being funneled through the SMC and thus this is the thread reporting the crashes.

Thanks,
Solouki

 

[Dracarris]

Dracarris,

I see that your first crash report says that thread id 400 caused the crash. Do you mind searching for this tid lower down in your crash report to find the name of this thread? And your second crash report gave a thread id of 392, please search for this tid and find its name. Thanks.

For four of my KPs, I found that the crashing threads were all linked to AppleSMC. I don't know if it was really the SMC that was crashing, or just that all kernel panics end up being funneled through the SMC and thus this is the thread reporting the crashes.

Thanks,
Solouki

Sad to report, but here we go:

"400":{"userTime":45.557232290999998,"systemTime":0,"system_usec":0,"id":400,"basePriority":81,"user_usec":45557232,"kernelFrames":[[0,68838038760],[0,68838039648],[0,68838046872],[0,68827359732],[0,68827369084],[0,68827357632],[0,68827069104],[0,68842799356],[0,68842797412],[0,68837869076]],"schedPriority":81,"name":"AppleSMC","state":["TH_RUN"]}

"392":{"userTime":4.7975632499999996,"systemTime":0,"system_usec":0,"id":392,"basePriority":81,"user_usec":4797563,"kernelFrames":[[0,68838038760],[0,68838039648],[0,68838046872],[0,68827359732],[0,68827369084],[0,68827357632],[0,68827069104],[0,68842799356],[0,68842797412],[0,68837869076]],"schedPriority":81,"name":"AppleSMC","state":["TH_RUN"]}

 

[solouki]

Hypothesis: Corrupted SSD...

I find it intriguing that machines will work fine for weeks and then start to have KPs on what appears to be an increasing frequency, as per Dracarris's posts above. Personally, I found similar behaviors on my 2018 MBPs.

And I also have documented cryptographic proof (and you can't have any stronger evidence than cryptographic) that the macOS/BridgeOS/T2 corrupted a file on its own internal SSD on one of my 2018 MBPs. If the macOS/BridgeOS/T2 is capable of rarely and randomly corrupting files, then perhaps random file corruption eventually corrupts kernel modules and operating system utilities. Perhaps these kernel modules are typically already in RAM memory, so it is not until they are read back into RAM that they then can cause a KP. This occurs most often when the machine wakes from hibernation when the RAM is read from the sleep image (/var/vm/sleepimage) stored on the SSD, or perhaps even reread from the original, and now corrupted, kext files or other system files. Might this explain the rare and seemingly random nature of these KPs, and the fact that not all of us that experience KPs report a common cause or common circumstances when the KPs occur? [Some report KPs while waking from sleep, some report KPs while recording photos, some report KPs while watching YT videos, some report KPs occurring at random times.] Although many of us do report KPs when the machines wake from sleep/hibernation. If the macOS/BridgeOS/T2 rarely and randomly corrupts files on its internal SSD, then until the number of corruptions builds up to the point of affecting the operating system software, the machines work correctly without KPs (perhaps for weeks/months), but once the OSes are corrupted, then KPs occur more frequently? This might also explain why switching off T2 functions, such as FileVault, appears to halt the KPs at first but then they resume at a later time (the initial corruption of the encryption/decryption code causing KPs stops when FileVault is initially switched off, but future rare and random SSD corruptions of the OSes eventually causes future KPs and they resume?).

What do you think?

P.S. I'm thinking about erasing the internal SSD and installing a fresh copy of the macOS from the Internet, and then hashing all files on the SSD, including all system files. Rehashing at a later time and diff-ing with the original hashes might turn up system file corruptions. Two things are keeping me from pursuing this: one is the fact that there are so many caches/logs/configuration files that change continuously that it may be a Sisyphean, and Herculean, task to track down the one "needle in the haystack" (or few) that causes the KPs; and the second is that differing hashes don't tell me what the changes were, only that changes have occurred. Okay, I think I'm convinced that this would be a huge waste of time, but I may do it for my own source code files to make certain that no corruptions occur in them.
[doublepost=1544524365][/doublepost]

Sad to report, but here we go:

Ah, interesting...both of your crashes also report the AppleSMC as the crashing thread. This makes me think that either it really is the SMC that is crashing and the SMC is handled by the BridgeOS/T2, or all crashes, including macOS crashes, are funneled through the SMC and so all crash reports list the offending thread as AppleSMC. Do you know which is the case?

 

[Dracarris]

Do you know which is the case?

I am sorry, I have absolutely no idea. However I guess the SMC was somehow merged with the T2 or renamed, funnelling all crash reports through the SMC seems a bit useless to me, I mean why report it then?

Your hypothesis with the SSD sounds absolutely plausible. As this would be a horrific bug, most probably in the chip, I can imagine Apple doing everything to keep it under the covers.

As you've already said, starting with wiped drives and fresh macOS installations should in this case show the same behavior of weeks of fine operation and then KPs with increasing frequency.

 

[SDColorado]

Hypothesis: Corrupted SSD...

I find it intriguing that machines will work fine for weeks and then start to have KPs on what appears to be an increasing frequency, as per Dracarris's posts above. Personally, I found similar behaviors on my 2018 MBPs.

And I also have documented cryptographic proof (and you can't have any stronger evidence than cryptographic) that the macOS/BridgeOS/T2 corrupted a file on its own internal SSD on one of my 2018 MBPs. If the macOS/BridgeOS/T2 is capable of rarely and randomly corrupting files, then perhaps random file corruption eventually corrupts kernel modules and operating system utilities. Perhaps these kernel modules are typically already in RAM memory, so it is not until they are read back into RAM that they then can cause a KP. This occurs most often when the machine wakes from hibernation when the RAM is read from the sleep image (/var/vm/sleepimage) stored on the SSD, or perhaps even reread from the original, and now corrupted, kext files or other system files. Might this explain the rare and seemingly random nature of these KPs, and the fact that not all of us that experience KPs report a common cause or common circumstances when the KPs occur? [Some report KPs while waking from sleep, some report KPs while recording photos, some report KPs while watching YT videos, some report KPs occurring at random times.] Although many of us do report KPs when the machines wake from sleep/hibernation. If the macOS/BridgeOS/T2 rarely and randomly corrupts files on its internal SSD, then until the number of corruptions builds up to the point of affecting the operating system software, the machines work correctly without KPs (perhaps for weeks/months), but once the OSes are corrupted, then KPs occur more frequently? This might also explain why switching off T2 functions, such as FileVault, appears to halt the KPs at first but then they resume at a later time (the initial corruption of the encryption/decryption code causing KPs stops when FileVault is initially switched off, but future rare and random SSD corruptions of the OSes eventually causes future KPs and they resume?).

What do you think?

P.S. I'm thinking about erasing the internal SSD and installing a fresh copy of the macOS from the Internet, and then hashing all files on the SSD, including all system files. Rehashing at a later time and diff-ing with the original hashes might turn up system file corruptions. Two things are keeping me from pursuing this: one is the fact that there are so many caches/logs/configuration files that change continuously that it may be a Sisyphean, and Herculean, task to track down the one "needle in the haystack" (or few) that causes the KPs; and the second is that differing hashes don't tell me what the changes were, only that changes have occurred. Okay, I think I'm convinced that this would be a huge waste of time, but I may do it for my own source code files to make certain that no corruptions occur in them.
[doublepost=1544524365][/doublepost]

Ah, interesting...both of your crashes also report the AppleSMC as the crashing thread. This makes me think that either it really is the SMC that is crashing and the SMC is handled by the BridgeOS/T2, or all crashes, including macOS crashes, are funneled through the SMC and so all crash reports list the offending thread as AppleSMC. Do you know which is the case?

It is an interesting theory about the SSD, however the first KP I ever had was right after the initial setup. I did the initial setup, took a break to let my dogs out, came back to a MBP that had KP’Ed. I suppose that doesn’t rule out the possibility of T2 corrupting a file as early as initial setup, but doesn’t it seem a little unlikely?

One of the first things done after SMC & NVRAM failed to improve the situation was wipe and re-install the OS. While it did not crash right after initial setup after that, it didn’t eliminate the problem either.

It will be interesting if you are correct and that does turn out to be the issue. Troublesome that it can happen as early as initial setup or as late as several weeks (months? years?) of ownership

 

[Ries]

Hypothesis: Corrupted SSD...

I find it intriguing that machines will work fine for weeks and then start to have KPs on what appears to be an increasing frequency, as per Dracarris's posts above. Personally, I found similar behaviors on my 2018 MBPs.

And I also have documented cryptographic proof (and you can't have any stronger evidence than cryptographic) that the macOS/BridgeOS/T2 corrupted a file on its own internal SSD on one of my 2018 MBPs. If the macOS/BridgeOS/T2 is capable of rarely and randomly corrupting files, then perhaps random file corruption eventually corrupts kernel modules and operating system utilities. Perhaps these kernel modules are typically already in RAM memory, so it is not until they are read back into RAM that they then can cause a KP. This occurs most often when the machine wakes from hibernation when the RAM is read from the sleep image (/var/vm/sleepimage) stored on the SSD, or perhaps even reread from the original, and now corrupted, kext files or other system files. Might this explain the rare and seemingly random nature of these KPs, and the fact that not all of us that experience KPs report a common cause or common circumstances when the KPs occur? [Some report KPs while waking from sleep, some report KPs while recording photos, some report KPs while watching YT videos, some report KPs occurring at random times.] Although many of us do report KPs when the machines wake from sleep/hibernation. If the macOS/BridgeOS/T2 rarely and randomly corrupts files on its internal SSD, then until the number of corruptions builds up to the point of affecting the operating system software, the machines work correctly without KPs (perhaps for weeks/months), but once the OSes are corrupted, then KPs occur more frequently? This might also explain why switching off T2 functions, such as FileVault, appears to halt the KPs at first but then they resume at a later time (the initial corruption of the encryption/decryption code causing KPs stops when FileVault is initially switched off, but future rare and random SSD corruptions of the OSes eventually causes future KPs and they resume?).

What do you think?

P.S. I'm thinking about erasing the internal SSD and installing a fresh copy of the macOS from the Internet, and then hashing all files on the SSD, including all system files. Rehashing at a later time and diff-ing with the original hashes might turn up system file corruptions. Two things are keeping me from pursuing this: one is the fact that there are so many caches/logs/configuration files that change continuously that it may be a Sisyphean, and Herculean, task to track down the one "needle in the haystack" (or few) that causes the KPs; and the second is that differing hashes don't tell me what the changes were, only that changes have occurred. Okay, I think I'm convinced that this would be a huge waste of time, but I may do it for my own source code files to make certain that no corruptions occur in them.
[doublepost=1544524365][/doublepost]

Ah, interesting...both of your crashes also report the AppleSMC as the crashing thread. This makes me think that either it really is the SMC that is crashing and the SMC is handled by the BridgeOS/T2, or all crashes, including macOS crashes, are funneled through the SMC and so all crash reports list the offending thread as AppleSMC. Do you know which is the case?

A corrupt executable would most likely result in illegal instruction errors.

 

[scsyc]

A corrupt executable would most likely result in illegal instruction errors.

I would add, once corrupted, the file that caused the KP would cause it systematically. People experiencing Kernel Panics have periods of time when their machine would work well.
[doublepost=1544538774][/doublepost]I only experienced one KP (the 210 one) in one month. It happenned overnight while I left my computer powered on connected to its charger in order to let photos imported to my library sync with iCloud. I had disabled the activity suspension when screen shuts down feature. It ran amphetamine as well. It was the only time I did that. Usually, I sutdown the computer before going to sleep. No new KP since (knock on wood).

 

[Jerz]

Even from sleep mode multiple times it’s still ok?

Yep! I sleep it all the time, almost never turn my laptop off unless I'm switching OS

 

[unglued]

Yep! I sleep it all the time, almost never turn my laptop off unless I'm switching OS

Good to know, sorry for the others with issues must be frustrating.
[doublepost=1544542110][/doublepost]

Hypothesis: Corrupted SSD...

P.S. I'm thinking about erasing the internal SSD and installing a fresh copy of the macOS from the Internet

Or possibly a bad batch of SSD’s. Maybe the MBP goes to sleep and the SSD memory cells electrical charge disappears for whatever reason (bad/weak capacitors? thus intermittent issues) and lose stored data and the MBP wakes from sleep to load data from SSD to RAM but no data is present and KP, just a guess.

 

[Dracarris]

Apple apparently admitted that there are faulty SSDs on non-Touchbar 128GB and 256GB MBPs and is replacing them. I have no idea if this is related to our issue as well.

 

[unglued]

Apple apparently admitted that there are faulty SSDs on non-Touchbar 128GB and 256GB MBPs and is replacing them. I have no idea if this is related to our issue as well.

Interesting, did they specify the SSD make/models?

 

[SDColorado]

Apple apparently admitted that there are faulty SSDs on non-Touchbar 128GB and 256GB MBPs and is replacing them. I have no idea if this is related to our issue as well.

Replacing them or updating firmware for them? I don't think they are replacing them. From what I gather from the program details...

- A technician will run a utility to update your drive firmware which will take approximately one hour or less.

 

[IdentityCrisis]

As far as explaining why two people have no issues and I do, that logic does not apply. Already, with the pre-Vega 20 MBPs, there were plenty of people who were having issues and more who weren't. All I can tell you is that the issue definitely was not resolved for all Vega 20 MBPs. My first one was doing the same things I've seen mentioned in many posts and some videos on YT.

As far as what I was doing with my first MBP being the problem, I wasn't doing much of anything with it, yet. I had to get it up to speed to replace an iMac with it. But I never got to that point because it was having so many crashes with it that I could not rely on it. Could the problem be some app? I suppose, but many here say there is some type of hardware issue. Regardless, even if it is an app, all the issues with my first MBP Vega 20 prove that the problem has not been resolved.

Two of you have MBP Vega 20s that are working fine. I think my new one is, too. However, that does not put us in a different boat than all of the other 2018 MBP owners. Some experience issues, some do not.

The only person I saw was you and one other in this thread. So saying it does not apply is not correct. That is not enough evidence this is a big deal yet with the vega models.

 

[trifid]

I find it intriguing that machines will work fine for weeks and then start to have KPs on what appears to be an increasing frequency, as per Dracarris's posts above. Personally, I found similar behaviors on my 2018 MBPs.

And I also have documented cryptographic proof (and you can't have any stronger evidence than cryptographic) that the macOS/BridgeOS/T2 corrupted a file on its own internal SSD on one of my 2018 MBPs. If the macOS/BridgeOS/T2 is capable of rarely and randomly corrupting files, then perhaps random file corruption eventually corrupts kernel modules and operating system utilities. Perhaps these kernel modules are typically already in RAM memory, so it is not until they are read back into RAM that they then can cause a KP. This occurs most often when the machine wakes from hibernation when the RAM is read from the sleep image (/var/vm/sleepimage) stored on the SSD, or perhaps even reread from the original, and now corrupted, kext files or other system files. Might this explain the rare and seemingly random nature of these KPs, and the fact that not all of us that experience KPs report a common cause or common circumstances when the KPs occur? [Some report KPs while waking from sleep, some report KPs while recording photos, some report KPs while watching YT videos, some report KPs occurring at random times.] Although many of us do report KPs when the machines wake from sleep/hibernation. If the macOS/BridgeOS/T2 rarely and randomly corrupts files on its internal SSD, then until the number of corruptions builds up to the point of affecting the operating system software, the machines work correctly without KPs (perhaps for weeks/months), but once the OSes are corrupted, then KPs occur more frequently? This might also explain why switching off T2 functions, such as FileVault, appears to halt the KPs at first but then they resume at a later time (the initial corruption of the encryption/decryption code causing KPs stops when FileVault is initially switched off, but future rare and random SSD corruptions of the OSes eventually causes future KPs and they resume?).

What do you think?

P.S. I'm thinking about erasing the internal SSD and installing a fresh copy of the macOS from the Internet, and then hashing all files on the SSD, including all system files. Rehashing at a later time and diff-ing with the original hashes might turn up system file corruptions. Two things are keeping me from pursuing this: one is the fact that there are so many caches/logs/configuration files that change continuously that it may be a Sisyphean, and Herculean, task to track down the one "needle in the haystack" (or few) that causes the KPs; and the second is that differing hashes don't tell me what the changes were, only that changes have occurred. Okay, I think I'm convinced that this would be a huge waste of time, but I may do it for my own source code files to make certain that no corruptions occur in them.

Not sure if this is remotely related to your case but I had a Mojave corruption incident recently and solved it by forcing OS partition to stick with HFS+ rather than AFPS. In my case I was booting Mojave from external SSD, and for some reason the first time it booted fine, but any restarts it'd get corrupted and I'd have to run disk utility to fix it. After re-imaging as HFS+ the issue went away. Note that this was not on a T2 mac, it was a 2015 MBP.

 

[KDLM]

The only person I saw was you and one other in this thread. So saying it does not apply is not correct. That is not enough evidence this is a big deal yet with the vega models.

@IdentityCrisis - I'm not sure what you're saying. Of course, I also want to believe the Vega 20 is less subject to this problem. I really, really want that to be true. However, the fact that the issue is happening with the Vega 20 for me and at least one other person indicates that it has not been resolved completely. I was hoping that they changed something about the T2 chip or something, but then I wouldn't have had the issue. Hopefully it is becoming less of an issue for everyone with the updates to Mojave. This T2/KP issue has never been a universal issue to all MBPs. As a result, I don't know of any reason to think the Vega models are less subject to the T2 problems.

I don't know how many people with the new Vega models are experiencing the issue. I only know about it because it happened to me which made me search the web for the error logs I received. That brought me here and that's how I even know about the issue to begin with. My experience with my first Vega 20 was exactly in line with what others here are experiencing.

I never use migration assistant, but I did add all of the apps I use to my first MBP the second day. I'm hoping they were the source of the problem, but that is not logical because the problems started before I installed them. I'd love to trace this down to a peripheral or an app, because then I wouldn't have to worry about getting a lemon. Someone else here has now reported weeks of trouble-free use of another new MB model, only to then have the problems start. That is not encouraging.

 

[solouki]

A corrupt executable would most likely result in illegal instruction errors.

I suppose you are right, but might it also depend upon what part of the executable was corrupted? Random corruption of files (which is what my cryptographic evidence suggests) might lead to differing intervals between KPs depending upon just when the corrupted instructions/addresses are executed. In addition, some individuals have reported repeated and often KPs, on the order of several per day, while others report KPs only once every two weeks. And, of course, many never see a KP.

I've followed my panic reports through to the AppleSMC...it seems surprising that all panics (by at least three different individuals and even more than three different machines) would name this same thread when the crashes themselves appear to occur under different circumstances. This is why I suspect that all panics may be routed through the T2 chip and its BridgeOS and perhaps even the AppleSMC. I could not figure out how to "go deeper" into the panic reports to understand in greater detail what exactly is causing the crashes, as I don't have memory/address/cache maps nor the kernel source code and thus find it nearly impossible to follow the panic reports farther.
[doublepost=1544561774][/doublepost]

Or possibly a bad batch of SSD’s. Maybe the MBP goes to sleep and the SSD memory cells electrical charge disappears for whatever reason (bad/weak capacitors? thus intermittent issues) and lose stored data and the MBP wakes from sleep to load data from SSD to RAM but no data is present and KP, just a guess.

The problem is, I'm on my third 2018 MBP and am still having a variety of problems, from flickering internal and external displays to WiFi connection issues to KPs. If it was just a batch of bad SSDs, then they must be randomly using them in CTO builds and I'm the unluckiest person in the world.
[doublepost=1544561947][/doublepost]

I am sorry, I have absolutely no idea. However I guess the SMC was somehow merged with the T2 or renamed, funnelling all crash reports through the SMC seems a bit useless to me, I mean why report it then?

Your hypothesis with the SSD sounds absolutely plausible. As this would be a horrific bug, most probably in the chip, I can imagine Apple doing everything to keep it under the covers.

As you've already said, starting with wiped drives and fresh macOS installations should in this case show the same behavior of weeks of fine operation and then KPs with increasing frequency.

The T2 chip now handles many tasks that used to be handled on the Intel CPUs, the SMC is just one of these.

 

[guillone]

Hypothesis: Corrupted SSD...

I find it intriguing that machines will work fine for weeks and then start to have KPs on what appears to be an increasing frequency, as per Dracarris's posts above. Personally, I found similar behaviors on my 2018 MBPs.

And I also have documented cryptographic proof (and you can't have any stronger evidence than cryptographic) that the macOS/BridgeOS/T2 corrupted a file on its own internal SSD on one of my 2018 MBPs. If the macOS/BridgeOS/T2 is capable of rarely and randomly corrupting files, then perhaps random file corruption eventually corrupts kernel modules and operating system utilities. Perhaps these kernel modules are typically already in RAM memory, so it is not until they are read back into RAM that they then can cause a KP. This occurs most often when the machine wakes from hibernation when the RAM is read from the sleep image (/var/vm/sleepimage) stored on the SSD, or perhaps even reread from the original, and now corrupted, kext files or other system files. Might this explain the rare and seemingly random nature of these KPs, and the fact that not all of us that experience KPs report a common cause or common circumstances when the KPs occur? [Some report KPs while waking from sleep, some report KPs while recording photos, some report KPs while watching YT videos, some report KPs occurring at random times.] Although many of us do report KPs when the machines wake from sleep/hibernation. If the macOS/BridgeOS/T2 rarely and randomly corrupts files on its internal SSD, then until the number of corruptions builds up to the point of affecting the operating system software, the machines work correctly without KPs (perhaps for weeks/months), but once the OSes are corrupted, then KPs occur more frequently? This might also explain why switching off T2 functions, such as FileVault, appears to halt the KPs at first but then they resume at a later time (the initial corruption of the encryption/decryption code causing KPs stops when FileVault is initially switched off, but future rare and random SSD corruptions of the OSes eventually causes future KPs and they resume?).

What do you think?

P.S. I'm thinking about erasing the internal SSD and installing a fresh copy of the macOS from the Internet, and then hashing all files on the SSD, including all system files. Rehashing at a later time and diff-ing with the original hashes might turn up system file corruptions. Two things are keeping me from pursuing this: one is the fact that there are so many caches/logs/configuration files that change continuously that it may be a Sisyphean, and Herculean, task to track down the one "needle in the haystack" (or few) that causes the KPs; and the second is that differing hashes don't tell me what the changes were, only that changes have occurred. Okay, I think I'm convinced that this would be a huge waste of time, but I may do it for my own source code files to make certain that no corruptions occur in them.
[doublepost=1544524365][/doublepost]

Ah, interesting...both of your crashes also report the AppleSMC as the crashing thread. This makes me think that either it really is the SMC that is crashing and the SMC is handled by the BridgeOS/T2, or all crashes, including macOS crashes, are funneled through the SMC and so all crash reports list the offending thread as AppleSMC. Do you know which is the case?

You asked, what do you think.... I think it's heat related.... hence all the randomness.....
I think Apple's design is flawed, period. They're running all too hot.... cheers.....