Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

tmmacops

macrumors regular
Jan 15, 2019
156
250
I've experienced this with 2 2018 13"/MBP, both returned. Just got a 2018 MBA, and thought I was in the clear until this AM when it just restarted on its' own, and no KP. So it's under the 14 days, and going back. They can have it...

I'll try an MB and see what happens. Luckily it's a work machine, so its no skin off my back. But if it happens with that one, I'll buy a DELL or or a Lenovo. I really like Mac's and MacOS, but if it's not reliable why bother for that kind of $...? Not sure what's happened, but Tim Apple bette get off the stick. Having events talking about how wonderful their stuff is, and going to a video of Jonnie Ive and his ALUUU-MINIUM design nonsense ain't cutting it...
 
  • Like
Reactions: guillone

alexballvideos

macrumors member
Mar 11, 2017
76
43
I've experienced this with 2 2018 13"/MBP, both returned. Just got a 2018 MBA, and thought I was in the clear until this AM when it just restarted on its' own, and no KP. So it's under the 14 days, and going back. They can have it...

I'll try an MB and see what happens. Luckily it's a work machine, so its no skin off my back. But if it happens with that one, I'll buy a DELL or or a Lenovo. I really like Mac's and MacOS, but if it's not reliable why bother for that kind of $...? Not sure what's happened, but Tim Apple bette get off the stick. Having events talking about how wonderful their stuff is, and going to a video of Jonnie Ive and his ALUUU-MINIUM design nonsense ain't cutting it...

Just curious if you did you restore from a time machine backup on these?
 

William Forrest

macrumors newbie
Dec 23, 2017
12
0
Addendum...

Cool! I'm very glad to hear this about your 2.9 i9 32GB 1TB MBP. This gives me hope for my third 2018 MBP.

Actually, I'm feeling a little sorry for the Apple engineers. They receive a MBP and it passes all of their hardware and software tests, so what do they do? They probably leave it running on their desktop along with the other dozen computers they are tasked to fix. Maybe once an hour they touch the machine, in rotation with their others. Under these circumstances it would be nearly impossible to detect these rare, random, and intermittent errors.

Both of my 2018 MBPs passed the "on machine" hardware tests without any errors -- and yet I found dozens upon dozens of errors during continuous use (my typical use, coding, actually touching the machine continuously, is roughly 18 hrs a day 7 days a week, give or take). And this reminds me of an earlier post in this thread where the poster took his/her MBP to the Apple Store and was called back a few days later to pick it up. The store hadn't done anything to the MBP since it passed their hardware tests and they hadn't seen any problems occur. When the customer picked up his/her machine, he/she opened the lid and started the laptop...almost immediately the MBP suffered a kernel panic thus demonstrating for the Apple Genius that his/her machine had problems.

Now I'm sure that Apple engineers have more sophisticated tools to test and stress the 2018 MBPs. Personally, I, for one, setup a chron job on another machine that ran an nmap attack against various ports on the 2018 MBP every five minutes all day long in an attempt to detect the WiFi connectivity issues. But who's to say than an nmap attack doesn't on its own eliminate the intermittent WiFi connection issues, or that I chose the proper ports to test? So, once again, I'm certain that Apple's engineers have more sophisticated methods and equipment for finding and fixing errors on the 2018 MBPs, but it still may be difficult even for Apple to find rare, random, and intermittent problems.

(And while I uploaded over 900 files -- 6+GB of data including pcap packet capture files taken during WiFi disconnections -- and explained in detail to the Apple Senior Advisors the nature of these problems and why they were serious, I'm not positive how much of my documentation actually landed in the hands of an Apple engineer. The Senior Advisors, who were not familiar with ssh, rsync, gpg2, nmap, wireshark, etc., may not have actually passed on my documentation to the engineers. I tried to explain to them why this documentation was precisely what the engineers would want to see, but I don't know how successful I was in my explanations. In fact, I'm sure I did a rather poor job and wasn't clear enough at all in my explanations, otherwise the following would not have occurred. At one point I was asked to take my 2018 MBP to an Apple Store and have them attach it to a WiFi router that was, and I quote, "precisely 20 feet away, no more, no less". I explained that my MBP would pass this test, that simply attaching it to another WiFi router, even one precisely 20 feet away, would not cause the rare, random, and intermittent WiFi connection issues that I had documented...the MBP would have to be in continuous use for days in order to catch these WiFi connection issues, even with the router 20 feet away. Not only that, but I explained that the nearest Apple Store to me is over 320 miles away which is at least a 6 hour drive, depending upon the traffic on I25. So this test would not only be superfluous but it would also be very difficult and expensive for me to accomplish.)
I too have been experiencing loss of WiFi sensitivity. I can send my machine into the WiFi-weak state by mounting my external Seagate backup drive using an iclever adaptor. It has to be the hard drive and iclever adaptor, i.e. it's related to the power being drawn from the USB port. Today, however, I entered the WiFi-deaf state, with nothing but the power supply plugged into one USB port. But, naturally, it recovered after 10-20 minutes. So I can't take it to the Apple repair people. But I learned, by holding the 'option' key, one can engage WiFi diagnostics. I set it to 'Monitor' and went about my business. After a short while, I got my first error 'Dropped Connection' at 3:35. I restarted the 'Monitor', and it's been 15 minutes without a further 'Dropped Connection'. I'm hopeful that with enough of these 'Dropped Connections', I can get help via AppleCare. In the meantime, I brought my wired Ethernet adaptor home in case my WiFi becomes deaf for a long time.
 

solouki

macrumors 6502
Jan 5, 2017
339
213
I too have been experiencing loss of WiFi sensitivity. I can send my machine into the WiFi-weak state by mounting my external Seagate backup drive using an iclever adaptor. It has to be the hard drive and iclever adaptor, i.e. it's related to the power being drawn from the USB port. Today, however, I entered the WiFi-deaf state, with nothing but the power supply plugged into one USB port. But, naturally, it recovered after 10-20 minutes. So I can't take it to the Apple repair people. But I learned, by holding the 'option' key, one can engage WiFi diagnostics. I set it to 'Monitor' and went about my business. After a short while, I got my first error 'Dropped Connection' at 3:35. I restarted the 'Monitor', and it's been 15 minutes without a further 'Dropped Connection'. I'm hopeful that with enough of these 'Dropped Connections', I can get help via AppleCare. In the meantime, I brought my wired Ethernet adaptor home in case my WiFi becomes deaf for a long time.

Hi William,

I've literally carefully documented 100s of WiFi dropped connections, under every possible condition imaginable -- battery power, different WiFi routers, different locations, only plugged into power brick, only plugged into eGPU, SMB-mounted drives attached, etc. It's not that the WiFi isn't working, it is that the MBP "forgets" its DNS information. My connections are RSSI=-40dBm with a Noise=-90dBm but the MBP has disconnected from everything on my LAN and WAN because it no longer remembers its DNS information. These "WiFi connection problems" typically last 1 to 10 minutes, and they fix themselves. But I also experience them lasting 2 hr to 16 hr without fixing themselves. If you cycle your MBP's WiFi Off then back On, this will manually fix the problem.

I also experience Bluetooth disconnects, for instance sometimes the external Magic Trackpad will disconnect (battery=90%) while the external Magic Keyboard will remain connected, or vice versa. I get failed Software Updates because of the WiFi disconnects. When I attempted the first Time Machine backup to an Apple Time Capsule, it failed four times in a row, the fifth time the TM backup was successful but it took 5.5 days to complete! (I suspect the extraordinary long backup time was because of the WiFi random and intermittent disconnections.) AirDrop at times fails for me because of the WiFi disconnects.

I can't get Apple Support to do anything, as they will not recognize these problems and the 2018 MBP passes hardware tests so they claim that there is no problem. I experience ping failures, rsync failures, ssh failures (all of these are Apple macOS utilities, not third-party apps), all caused by WiFi disconnects. I've experienced the macOS deleting a file on an SMB-mounted disk drive, I have cryptographic documentation (and there is no stronger evidence) of the macOS corrupting a file on its own internal SSD. At times I can't read my emails because of the WiFi disconnects. And, of course, I also experience KPs. But the rate of KPs has slowed down with the latest macOS version, thus I use the 2018 MBP sparingly to build pieces of code and run some number crunching routines, but since I can't trust the 2018 MBP to not corrupt files I never entrust all of my code or build everything on the 2018 MBP the way that I can on the 2016 MBP or iMac. I do like the speed of the 2018 MBP, and if it weren't for this speed increase I'd abandon it totally. But all coding I do on the 2018 MBP I transfer to the 2016 MBP or my iMac and build the final versions of everything on these older machines where I can trust them.

In summary, the WiFi is still working during these WiFi dropouts, and it is working with a very strong signal (50dBm S/N), so there is nothing "weak" about the WiFi in my hands. But the WiFi disconnects because it no longer has DNS information.

Solouki
 

dimgr

macrumors newbie
Dec 17, 2018
7
1
I managed to get a replacement for my i9-32GB 15" 2018 MBP model which experienced lots of KPs throughput different versions of Mojave.

I received a new, same spec, model at the beginning on Feb; upgraded to 10.14.3 (from 10.14.2 which it came with), restored my time machine backup and shortly after got a sudden freeze / reboot which *didn't* get registered as a KP in console. After this incident, almost two months after, I have not had a single KP on a heavily used, almost always-on, machine.

Getting a replacement was just due to my company's IT dept. which just bought me a new one and is going to follow up with Apple on the problematic one. I am very happy that I have a solid trustworthy machine now but I feel rather confident, by reading feedback here and from other colleagues, that there's some hardware issue any new laptop may or may not have ...
 
Last edited:

doitdada

Suspended
Oct 14, 2013
946
557
In summary, the WiFi is still working during these WiFi dropouts, and it is working with a very strong signal (50dBm S/N), so there is nothing "weak" about the WiFi in my hands. But the WiFi disconnects because it no longer has DNS information.

Yes, I feel with you. I get to a point where my Internet is slow or stalling. Have to disconnect, then connect again to get it working. Happens more often on 5Ghz than 2.4Ghz. Connected to an Airport Time Capsule / Airport Express with latest firmware.
 

csurfr

macrumors 68020
Dec 7, 2016
2,310
1,748
Seattle, WA
I've had my replacement machine going on what.. a little over a month now, and haven't had any issues really. Every once in a while my 2nd UltraFine doesn't wake with the system, but a quick unplug / plug fixes that quickly. Of course I probably shouldn't post this and will most definitely jinx myself.
[doublepost=1553629365][/doublepost]
Notice - no T2 on the new iMac
I DID notice this. . . I was a little surprised / not surprised. They seemed to be all in on this.
 

RumorConsumer

macrumors 68000
Jun 16, 2016
1,627
1,123
Yes, I believe that's correct, but more specifically any spinning hard drive. I'm sure I'll be corrected if I'm wrong...
That would make total sense. Accidental Tech Podcast was talking about this - that the iMac Pro and the iMac look totally the same on the outside but are different beasts entirely on the inside which makes sense. So this sounds like it was the last revision of the current rev iMac. Betting next one bumps to T3.
 
  • Like
Reactions: DCIFRTHS

star-affinity

macrumors 68000
Nov 14, 2007
1,977
1,312
I just had a sudden restart in the middle of using my MBP 13" from 2018 with MacOS 10.14.4, but am unsure how to see if the cause was Bridge OS. Where in Console.app can I find info about it?

Can't seem to find anything about Bridge OS, so maybe it was something else.
 

xgman

macrumors 603
Aug 6, 2007
5,694
1,425
I just had a sudden restart in the middle of using my MBP 13" from 2018 with MacOS 10.14.4, but am unsure how to see if the cause was Bridge OS. Where in Console.app can I find info about it?

Can't seem to find anything about Bridge OS, so maybe it was something else.
I've never seen it in console, just a notice/report on startup of the bos crash. There is a folder somewhere with bos related logs but I can't remember where. probably in this long thread somewhere. What do you wanna bet that 10.14.5 beta makes no difference either...
 

Trey M

macrumors 6502a
Jul 25, 2011
961
329
USA
I just had a sudden restart in the middle of using my MBP 13" from 2018 with MacOS 10.14.4, but am unsure how to see if the cause was Bridge OS. Where in Console.app can I find info about it?

Can't seem to find anything about Bridge OS, so maybe it was something else.

Just had a KP on 10.14.3...this is at least my third. It occurred when docking into Thunderbolt 3 dock (had never happened with this use-case before).

The logs for the T2 KP crashes are located in MacintoshHD > Library > Logs > Diagnostic Reports > ProxiedDevice-Bridge.

If it's a true KP crash, the filename should begin with 'ResetCounter' and then a timestamp.

I had to change my permissions to even be able to view the logs, so you might have to do the same.


{"bug_type":"115","timestamp":"2019-03-28 15:14:50.10 +0000","name":"Reset count","os_version":"Bridge OS 3.3 (16P3133)","incident_id":"61E917A9-7396-43CD-9EE0-7433E9190FA4"}
Incident Identifier: 61E917A9-7396-43CD-9EE0-7433E9190FA4
CrashReporter Key: c0dec0dec0dec0dec0dec0dec0dec0dec0de0001
Date: 2019-03-28 15:14:50.08 +0000
Reset count: 0
Boot failure count: 1
Boot faults: force_off
Boot stage: 255
Boot app: 0
 
Last edited:
  • Like
Reactions: star-affinity

star-affinity

macrumors 68000
Nov 14, 2007
1,977
1,312
Just had a KP on 10.14.3...this is at least my third. It occurred when docking into Thunderbolt 3 dock (had never happened with this use-case before).

The logs for the T2 KP crashes are located in MacintoshHD > Library > Logs > Diagnostic Reports > ProxiedDevice-Bridge.

If it's a true KP crash, the filename should begin with 'ResetCounter' and then a timestamp.

I had to change my permissions to even be able to view the logs, so you might have to do the same.


{"bug_type":"115","timestamp":"2019-03-28 15:14:50.10 +0000","name":"Reset count","os_version":"Bridge OS 3.3 (16P3133)","incident_id":"61E917A9-7396-43CD-9EE0-7433E9190FA4"}
Incident Identifier: 61E917A9-7396-43CD-9EE0-7433E9190FA4
CrashReporter Key: c0dec0dec0dec0dec0dec0dec0dec0dec0de0001
Date: 2019-03-28 15:14:50.08 +0000
Reset count: 0
Boot failure count: 1
Boot faults: force_off
Boot stage: 255
Boot app: 0

Thanks! Found it. But like you said there's probably something about permissions that prevents the file from being seen in Console.app. What I did was to right-click one of the items in ”ProxiedDevice-Bridge” that I could see (tasking.da3.proxy) and do ”Reveal in Finder”. There in the ”Retired” folder I found a log file (ResetCounter-2019-03-28-095130.ips) showing very similar details as yours except for the Bridge OS being version 3.4 since I'm on Mojave 10.14.4.

I will create a bug report with Apple, but I guess someone else might already have...
 

Trey M

macrumors 6502a
Jul 25, 2011
961
329
USA
Thanks! Found it. But like you said there's probably something about permissions that prevents the file from being seen in Console.app. What I did was to right-click one of the items in ”ProxiedDevice-Bridge” that I could see (tasking.da3.proxy) and do ”Reveal in Finder”. There in the ”Retired” folder I found a log file (ResetCounter-2019-03-28-095130.ips) showing very similar details as yours except for the Bridge OS being version 3.4 since I'm on Mojave 10.14.4.

I will create a bug report with Apple, but I guess someone else might already have...

You can create a bug report but they have thousands at this point, it's just a matter of getting them to do something about it.

Out of curiosity, what is the "bug_type" that leads your log file? As you can see mine is 115, all 3 of mine have been 115 and many others have had this as well, but there are other codes (I believe 210 is another).
 
  • Like
Reactions: SDColorado

star-affinity

macrumors 68000
Nov 14, 2007
1,977
1,312
You can create a bug report but they have thousands at this point, it's just a matter of getting them to do something about it.

Yup, I'm expecting a notification that it's a duplicate.

Out of curiosity, what is the "bug_type" that leads your log file? As you can see mine is 115, all 3 of mine have been 115 and many others have had this as well, but there are other codes (I believe 210 is another).

Mine is 115 too.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.