1

I have a personal ThinkPad laptop and USB-C Dock Gen 2 that work great. In the past, I've used Macs for work and they paired just fine with my ThinkPad dock. However, on my current MacBook I will often get a weird freezing effect followed up a shutdown of my Mac when I plug in the USB-C connector.

In the past, I'm pretty sure I had to install some driver update for my Mac, but on their official website they only have Windows OS drivers available. I've talked to Lenovo customer support and gotten no help.

Am I crazy or aren't there some drivers for Macbooks? Some other solution I'm not thinking of?

output of pmset -g log | grep -i cause

2021-10-07 09:44:27 -0700 ShutdownCause         SMC shutdown cause: -20:                                                              
2021-10-07 09:51:59 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-08 09:28:34 -0700 ShutdownCause         SMC shutdown cause: -20:                                                              
2021-10-08 09:32:14 -0700 ShutdownCause         SMC shutdown cause: 1: Normal warm reset                                              
2021-10-08 09:40:54 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-08 09:46:01 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-08 11:26:10 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-08 11:30:44 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-08 11:33:58 -0700 ShutdownCause         SMC shutdown cause: 1: Normal warm reset                                              
2021-10-11 10:38:59 -0700 ShutdownCause         SMC shutdown cause: -20:                                                              
2021-10-11 10:43:11 -0700 ShutdownCause         SMC shutdown cause: 1: Normal warm reset                                              
2021-10-11 10:47:31 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-11 12:41:56 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-12 00:43:51 -0700 ShutdownCause         SMC shutdown cause: 1: Normal warm reset                                              
2021-10-12 00:48:21 -0700 ShutdownCause         SMC shutdown cause: 5: Software initiated shutdown                                    
2021-10-12 00:53:13 -0700 ShutdownCause         SMC shutdown cause: 1: Normal warm reset                                              
2021-10-13 10:17:20 -0700 ShutdownCause         SMC shutdown cause: -20: 
9
  • Can you share your panic log(s) with us? It/they would be found in /Library/Logs/DiagnosticReports and end with .panic. (Please use the 'codeblock' feature to add it/them to your original question.)
    – pion
    Oct 13 at 20:29
  • @pion Unfortunately my DiagnosticReports directory is empty except for a "Retired" subfolder with no content.
    – Hofbr
    Oct 13 at 20:38
  • What do you see with pmset -g log | grep -i cause?
    – pion
    Oct 13 at 20:48
  • When I type that command within the Logs directory in the terminal nothing is getting returned.
    – Hofbr
    Oct 13 at 20:54
  • That is very odd. As a sanity check can you just do pmset -g log?
    – pion
    Oct 13 at 21:01
1

A shutdown cause of -20 means that the T2 chip, which is the hardware root device for the 16" MBP and is an essential component in its operation, has detected that certain critical processes on it have hung and there is no safe way to continue running while maintaining data coherency, so the only option left is to shut the system down.

By definition, any action on the part of the user which induces this behavior is considered to be a bug in the operating system. Regardless of any bad user actions or badly designed hardware or software, the OS must always be resilient and fail gracefully. A shutdown or reboot here means that you have found, at minimum, a bug in macOS (or, probably more likely, bridgeOS), and possibly also a bug in the ThinkPad.

Apple has a longstanding history of latent bugs being exposed by faulty peripherals and you are stumbling into yet-another of these. At the end of the day, because you are not an Apple engineer with access to their source code and debugging tools, you will never find and fix the root cause yourself. So the one thing to always do in these situations is to report the bug to Apple (links one and two). Please do this first so that they are able to collect failed-state data from you.

Then, until this bug is fixed and an update issued, your next step is to find a workaround. A few things come to mind:

  1. Obviously, you can try to avoid using the ThinkPad, but this doesn't really count as a workaround.
  2. Update to the latest macOS, which you have already done.
  3. Can you try attaching to the USB-C ports on the other side of the MBP? There is an actual hardware difference in the signal path between the left and right sides which occasionally makes a difference for these kinds of bugs.
  4. Can you try attaching through another device (like a USB hub) rather than directly into your MBP?
  5. If this is the result of a software race condition, we can fiddle with a few big hammers. One is to temporarily disable CPU C-states. Note that this will dramatically increase power consumption so you should reenable them after testing. The procedure is to add the cstates=0 argument to your boot-args. (If you're not familiar: First disable SIP, reboot back into normal macOS, and run sudo nvram boot-args="cstates=0", making sure that you're using straight quotes by copy-pasting rather than entering smart/curly quotes. Reboot and now you're running with C-states disabled. See if this problem goes away or not. If so, it's valuable info to pass on to Apple. To undo, run sudo nvram -d boot-args and reboot; you can turn SIP back off at that point.)
  6. Similar to the above but having a more dramatic effect on performance: You can temporarily run in a single-threaded CPU mode. Same procedure as #5 except instead of cstates=0 you would put cpus=1. You will really feel the effects of this as everything will be slower. But it's a good test to try.
1
  • Thank you pion for the thoroughness. I'll submit the bug as suggested and test out some of the work-arounds and report back.
    – Hofbr
    Oct 13 at 22:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .