This mess happened to me tonight. I was setting up a new RAID and after I had it configured with the G-Tech software, I went to disk utility to initialize the disk. As soon as Disk Utility loaded, BOOM. Crash from kernel panic. I was glad I had just read this article. I have a 2015 iMac running 10.13.6 and I had the new RAID daisy chained with TB2 to my existing 2 TB hard drives. After the reboot from the kernel panic, I unplugged the new RAID and plugged it directly into the iMac. I was able to initialize the drive with no problems. I think this issue is a flaw in the latest build of MacOS and that the new computers are seeing this because when people get new gear they have lots of stuff to set up including redoing their daisy chained drives or adding new ones.
Except your 2015 iMac doesn't have a T2 chip, so no, it didn't happen to you!
Sorry, this is one of my biggest tech support pet peeves. People that post a response to a problem and describe a totally different issue.
This mess happened to me tonight. I was setting up a new RAID and after I had it configured with the G-Tech software, I went to disk utility to initialize the disk. As soon as Disk Utility loaded, BOOM. Crash from kernel panic. I was glad I had just read this article. I have a 2015 iMac running 10.13.6 and I had the new RAID daisy chained with TB2 to my existing 2 TB hard drives. After the reboot from the kernel panic, I unplugged the new RAID and plugged it directly into the iMac. I was able to initialize the drive with no problems. I think this issue is a flaw in the latest build of MacOS and that the new computers are seeing this because when people get new gear they have lots of stuff to set up including redoing their daisy chained drives or adding new ones.
Except your 2015 iMac doesn't have a T2 chip, so no, it didn't happen to you!
Sorry, this is one of my biggest tech support pet peeves. People that post a response to a problem and describe a totally different issue.
Well Pet Peeve Steve, no one (certainly not Apple at this point) has conclusively determined that this issue is in fact caused by the T2, which I’m fully aware my 2015 iMac doesn’t have. In fact the very first paragraph of the article states: “initial investigations into the problems suggesting something connected to Apple's T2 security chip is to blame —but actual service numbers don't point to a hardware problem.“
I was pointing out that similar effects (from the article—1. the Mac crashes, entering a kernel panic and requiring it to be restarted, or in some cases rebooting itself automatically, and 2. other forum posts suggested crashes could be reduced by not daisy-chaining devices) can be produced on hardware that doesn’t have the T2 so that this issue may not have anything to do with that chip just as the author alludes to. You would have gotten the point if you would have read my comment (possibly the article as well) and thought about what was written before blithely hitting the quote button.
FYI: My data point. 8 core iMac Pro. Vega 56 (vs 64 in most of the cases I saw). 2TB SSD. 1 external monitor. 1 external drive TB drive. 1GB Ethernet connection.
Not a single Kernel Panic in 6+ months. Machine has been like a rock.
I'm amused by the support staff suggestions. It reminds me of those medication ads that cure something, then the guy comes on at the end and lists all the side effects.
Didn't Scotty say, "the more they overthink the plumbing, the easier it is to stop up the drain"?
I've been thinking the T2 provides the security Apple needs to protect macOS... and iOS in particular... from malicious actors, wayward governments, and accidents. Most of the rest of us don't need that level of security.
If theories like creationism and flat earth are any indication, many people just seem to prefer random, unfounded speculation over well-researched facts.
The difficult thing for support staff is that people come to them expecting that they have all of the answers to their problems. When really, only the people who are directly working on the hardware and software can determine the cause (and solution) for these types of problems. Apple should really tell support staff that if they don't know the solution, and can't find it in their knowledge base, they should tell people that information instead of providing speculation-based answers.
We live in a world of theories largely and often struggle to explain the facts.
I take exception to this nihilistic view (and also how you use the word "fact" and "data" and the concept of observation as interchangeable.
If you take Auxio's original sentence, he equates people buying into creationism and flat Earth theories as people not willing to accept well research facts. If we take "fact" as being:
"An objective consensus on a fundamental reality that has been agreed upon by a substantial number of people."
I think we can assuming the Earth being round and Evolution are both "An objective consensus on a fundamental reality that has been agreed upon by a substantial number of people."
In an observational world, our theories do an amazing job of explaining our observations (what you seem to be calling "facts"). For example: If I drop a brick from 4 meters high, Newton's basic theory of motion (a = dv/dt = d^2/dt^2) predicts it will take about 0.8 seconds to hit the ground and this fits observation extremely well. Theory even predicts interference patterns in double slit experiments with lights as well as quantum entanglement as demonstrated in (and in variations) of the quantum eraser experiments. Theory and observation match very well. Our theories, based on our observation of things around us, were good enough to get to the moon and send Voyager to other planets in a grand tour of the solar system.
Darwin made an amazing amount of predictions based on evolution such as predicting that precursors to the trilobite would be found in pre-Silurian rocks and he was right. He also predicted a method would be found allowing traits to be passed down from parents to offspring and he was right (as confirmed by Watson and Crick in 1953).
While it is true we don't have a single "Theory of Everything" explaining 100.000000% of everything we observe, saying we live in a world where "theories largely and often struggle to explain [observations]" is short sighted and poorly represents what we really know. There is lots left to explain and understand but we have an amazing set of theories today capable of explaining a vast array of data we observe every day.
Didn't Scotty say, "the more they overthink the plumbing, the easier it is to stop up the drain"?
You mean "Scotty", the fictional character that doesn't exist in real life, and everything he said was written by a bunch of screenwriters in some back room being paid to make stuff up? That Scotty? I loved James Doohan's character, but like in "Galaxy Quest", what he was on TV does not translate into real life.
This script line translates very well. It's a colorful rephrasing of an all too appropriate real-world engineering complaint: "complexity is the enemy of reliability".
i now seem to have the answer to my question about what happens when the T chip's embedded OS crashes. This.
If theories like creationism and flat earth are any indication, many people just seem to prefer random, unfounded speculation over well-researched facts.
The difficult thing for support staff is that people come to them expecting that they have all of the answers to their problems. When really, only the people who are directly working on the hardware and software can determine the cause (and solution) for these types of problems. Apple should really tell support staff that if they don't know the solution, and can't find it in their knowledge base, they should tell people that information instead of providing speculation-based answers.
We live in a world of theories largely and often struggle to explain the facts.
I take exception to this nihilistic view (and also how you use the word "fact" and "data" and the concept of observation as interchangeable.
If you take Auxio's original sentence, he equates people buying into creationism and flat Earth theories as people not willing to accept well research facts. If we take "fact" as being:
"An objective consensus on a fundamental reality that has been agreed upon by a substantial number of people."
I think we can assuming the Earth being round and Evolution are both "An objective consensus on a fundamental reality that has been agreed upon by a substantial number of people."
Thank you. I grew tired that whole division of philosophy which questions the very nature of observation and objectivity vs subjectivity. It's certainly useful to question everything and rigorously test theories, but at a certain point it turns into a big linguistic wank.
I'm very much a realist and when a theory is well researched, well tested, and leads to real world answers/solutions, then it becomes fact. Go ahead and get into subtleties of linguistics and semantics if you like, it won't change the real world results which were gained. Now obviously there are limitations to the application of theories (like some laws of physics breaking down when you get down to a quantum level), but those are just limitations on the scope. Not a disproving of facts.
Like the Apple under Steve was any better? Please!
Also, last I knew, Tim didn't make the T2 chip. Its also great that the only time you want to chime in on this website/forum is when an issue is reported at Apple so you can bitch about Tim. If you dislike him so much, then save yourself agony and go buy something else. Tim isn't going anywhere anytime soon.
When a tiny fraction of users have problems with kernel panics and most of them seem to relate to external hardware, I suspect a device driver problem more than anything else. Could be that correct behaviour of some device drivers trigger a problem in Bridge OS, could be that the driver itself is at fault. Could even be an Apple-supplied device driver.
The most heinous thing I’ve ever seen a software developer do is to put in exception handling logic that silently handles the exception and continues on without crashing at the point where the exception occurred.
To me, the most heinous this that a software could to is to NOT have any exception handling. Then you have little understanding of what went wrong and where. This especially applies to Java where sometimes the sheer depth of the procedure calls is staggering. I've had beginner software devs look at me in total surprise when I've described some of the EH designs I've used over the years. As for rolling back the current operation.... Oh! That's too hard.
There is no one panacea for excellent EH design but there a is are millions of really bad ones.
I disagree - for several reasons. But first and foremost, code that has no exception handling (language level like C++/C# and/or runtime level like SEH) that generates an exception is much more likely to be handled (as an unhandled exception) by the operating system and crash/hang the computer when the software is in the testing cycle, prior to release. Most operating systems can be configured to generate a dump or mini-dump when an unhandled exception occurs. Bad exception handling that keeps the machine from crashing like it should may very well survive the testing phase unnoticed and end up in a customer's hands. The cost of fixing software defects in the field is exponentially higher than the cost of fixing software defects in the lab. All software under development will fail at some point. You want it to fail as early in the development cycle as possible.
This mess happened to me tonight. I was setting up a new RAID and after I had it configured with the G-Tech software, I went to disk utility to initialize the disk. As soon as Disk Utility loaded, BOOM. Crash from kernel panic. I was glad I had just read this article. I have a 2015 iMac running 10.13.6 and I had the new RAID daisy chained with TB2 to my existing 2 TB hard drives. After the reboot from the kernel panic, I unplugged the new RAID and plugged it directly into the iMac. I was able to initialize the drive with no problems. I think this issue is a flaw in the latest build of MacOS and that the new computers are seeing this because when people get new gear they have lots of stuff to set up including redoing their daisy chained drives or adding new ones.
Except your 2015 iMac doesn't have a T2 chip, so no, it didn't happen to you!
Sorry, this is one of my biggest tech support pet peeves. People that post a response to a problem and describe a totally different issue.
Well Pet Peeve Steve, no one (certainly not Apple at this point) has conclusively determined that this issue is in fact caused by the T2, which I’m fully aware my 2015 iMac doesn’t have. In fact the very first paragraph of the article states: “initial investigations into the problems suggesting something connected to Apple's T2 security chip is to blame —but actual service numbers don't point to a hardware problem.“
I was pointing out that similar effects (from the article—1. the Mac crashes, entering a kernel panic and requiring it to be restarted, or in some cases rebooting itself automatically, and 2. other forum posts suggested crashes could be reduced by not daisy-chaining devices) can be produced on hardware that doesn’t have the T2 so that this issue may not have anything to do with that chip just as the author alludes to. You would have gotten the point if you would have read my comment (possibly the article as well) and thought about what was written before blithely hitting the quote button.
Correct, apparently not a hardware problem, a software problem is suspected. But it is the T2 chip, since it’s the bridgeOS that has the kernel panic, not MacOS. If you don’t have a T2 chip, you can’t have kernel panics of bridgeOS.
As as the author mentions, bridgeOS is the common element, and no machine besides the iMac Pro or 2018 MBP is alluded to or mentioned.
Apple support staff suggests iMac Pro users wipe and reinstall MacOS, disable FileVault, and disable Power Nap. For those not willing to perform those, other forum posts suggested crashes could be reduced by not daisy-chaining devices, not using a Thunderbolt 3-to-Thunderbolt 2 adapter, disable Secure Boot, turn off power management options, remove third-party kernel extensions, avoid leaving it to idle overnight, and to not unlock it with an Apple Watch
Or in other words avoid using functions of the T2 chip as much as possible?
If Apple’s support staff is actually advising customers to do a range of homegrown or ad hoc remedies they are doing themselves a disservice because it doesn’t move Apple any closer to solving the issue. It may help customers limp along for a while but the best thing Apple can do to fix this problem is to setup the machine to generate a crash dump and then analyze the dump to figure out exactly what’s going on.
The most heinous thing I’ve ever seen a software developer do is to put in exception handling logic that silently handles the exception and continues on without crashing at the point where the exception occurred. Two minutes, hours, days, or weeks later the whole thing blows up in a seemingly innocuous part of the code and the original cause of the crash is long gone. Crashing is a good thing when it helps capture the root cause of the problem. Any form of crash prevention that leaves the system running in a non deterministic and crippled state is pure evil, unless it’s part of a life, limb, or money damage control scenario.
Apple support staff didn’t recommend that long list of voodoo cures; those are random forum posters who suggest those things. Apple suggested re-installing MacOS, then disabling FileVault and PowerNap.
This mess happened to me tonight. I was setting up a new RAID and after I had it configured with the G-Tech software, I went to disk utility to initialize the disk. As soon as Disk Utility loaded, BOOM. Crash from kernel panic. I was glad I had just read this article. I have a 2015 iMac running 10.13.6 and I had the new RAID daisy chained with TB2 to my existing 2 TB hard drives. After the reboot from the kernel panic, I unplugged the new RAID and plugged it directly into the iMac. I was able to initialize the drive with no problems. I think this issue is a flaw in the latest build of MacOS and that the new computers are seeing this because when people get new gear they have lots of stuff to set up including redoing their daisy chained drives or adding new ones.
Except your 2015 iMac doesn't have a T2 chip, so no, it didn't happen to you!
Sorry, this is one of my biggest tech support pet peeves. People that post a response to a problem and describe a totally different issue.
Well Pet Peeve Steve, no one (certainly not Apple at this point) has conclusively determined that this issue is in fact caused by the T2, which I’m fully aware my 2015 iMac doesn’t have. In fact the very first paragraph of the article states: “initial investigations into the problems suggesting something connected to Apple's T2 security chip is to blame —but actual service numbers don't point to a hardware problem.“
I was pointing out that similar effects (from the article—1. the Mac crashes, entering a kernel panic and requiring it to be restarted, or in some cases rebooting itself automatically, and 2. other forum posts suggested crashes could be reduced by not daisy-chaining devices) can be produced on hardware that doesn’t have the T2 so that this issue may not have anything to do with that chip just as the author alludes to. You would have gotten the point if you would have read my comment (possibly the article as well) and thought about what was written before blithely hitting the quote button.
Correct, apparently not a hardware problem, a software problem is suspected. But it is the T2 chip, since it’s the bridgeOS that has the kernel panic, not MacOS. If you don’t have a T2 chip, you can’t have kernel panics of bridgeOS.
As as the author mentions, bridgeOS is the common element, and no machine besides the iMac Pro or 2018 MBP is alluded to or mentioned.
The article mentions that "A common trait found in the error messages is the mention of Bridge OS." Not that this mention is found in all error messages. Otherwise the author would write "The common trait found in the error messages is the mention of Bridge OS."
It may very well be that my crash is completely unrelated to the crashes some people are experiencing with their T2 equipped hardware, which as you point, is the only hardware specifically mentioned in the article. There are some elements in common with the crash I had however, and as I have never had a cash from kernel panic before in the whole time I have owned a mac (going back to the white unibody MacBook, I thought I would add my data point. I didn't screen shot my specific kernel panic error message for closer comparison with some of the reports in various blogs and sub-reddits. I'm certainly not a software engineer, so any comparison I could have made would have been subjective at best.
In the end, Apple got my crash report and if my data point is irrelevant they will note it and forget it. That is what I would expect any tech support or software engineer to do.
My 2018 15” i9 started experiencing this issue over the weekend. I had already done a fresh install. I am still within the 14 day period. Should I return and reorder a different unit? Almost every time I go back to the machine after it’s idle for a few hours, it has rebooted due to the BridgeOS issue.
My 2018 Mac Mini crashes with Kernel Panic reported from BridgeOS shortly after using Remote Desktop. I can reproduce the issue quite consistently. I’ve reformatted and clean installed Mojave to no avail. Am monitoring the ongoing discussion around T2 issues to decide whether to phone it in as hardware issue before warranty expires.
My 2018 Mac Mini crashes with Kernel Panic reported from BridgeOS shortly after using Remote Desktop. I can reproduce the issue quite consistently. I’ve reformatted and clean installed Mojave to no avail. Am monitoring the ongoing discussion around T2 issues to decide whether to phone it in as hardware issue before warranty expires.
I'd get it documented, if I were you. Mine does not crash under those circumstances. Between four machines, I've had one T2-related crash in total.
I have not experienced any T2 Security Chip Bridge OS crashes. I've had my 2018 MBP 15" for 6 weeks now. Not a single problem with it of any type whatsoever. While this may be an issue for some, it certainly can't be all that widespread. Apple would've said something by now.
Comments
Sorry, this is one of my biggest tech support pet peeves. People that post a response to a problem and describe a totally different issue.
I was pointing out that similar effects (from the article—1. the Mac crashes, entering a kernel panic and requiring it to be restarted, or in some cases rebooting itself automatically, and 2. other forum posts suggested crashes could be reduced by not daisy-chaining devices) can be produced on hardware that doesn’t have the T2 so that this issue may not have anything to do with that chip just as the author alludes to. You would have gotten the point if you would have read my comment (possibly the article as well) and thought about what was written before blithely hitting the quote button.
i now seem to have the answer to my question about what happens when the T chip's embedded OS crashes. This.
I'm very much a realist and when a theory is well researched, well tested, and leads to real world answers/solutions, then it becomes fact. Go ahead and get into subtleties of linguistics and semantics if you like, it won't change the real world results which were gained. Now obviously there are limitations to the application of theories (like some laws of physics breaking down when you get down to a quantum level), but those are just limitations on the scope. Not a disproving of facts.
The kernel is panicking because T2 is Judgment Day!
Also, last I knew, Tim didn't make the T2 chip. Its also great that the only time you want to chime in on this website/forum is when an issue is reported at Apple so you can bitch about Tim. If you dislike him so much, then save yourself agony and go buy something else. Tim isn't going anywhere anytime soon.
As as the author mentions, bridgeOS is the common element, and no machine besides the iMac Pro or 2018 MBP is alluded to or mentioned.
It may very well be that my crash is completely unrelated to the crashes some people are experiencing with their T2 equipped hardware, which as you point, is the only hardware specifically mentioned in the article. There are some elements in common with the crash I had however, and as I have never had a cash from kernel panic before in the whole time I have owned a mac (going back to the white unibody MacBook, I thought I would add my data point. I didn't screen shot my specific kernel panic error message for closer comparison with some of the reports in various blogs and sub-reddits. I'm certainly not a software engineer, so any comparison I could have made would have been subjective at best.
In the end, Apple got my crash report and if my data point is irrelevant they will note it and forget it. That is what I would expect any tech support or software engineer to do.