I am currently exploring my new MBP. It is connected to a TS 3 plus dock so I don’t have to take care of the other devices and I am wondering
how is the battery coping with being constantly charged?
can I detach the MBP by just pulling the one Thunderbolt plug?
It is attached to an EIZO monitor. How can I keep separate resolutions?
Something odd: the MBP has quietly restarted when it was supposed to be sleeping. It produces error reports with hints towards the TS 3 dock.
Any ideas?
Apple’s smart charging (“battery health management”) should take care of point 1.
Yes to point 2, just make sure in Finder you’ve ejected all disk connected to the dock first.
Point 3: System Prefs > Displays > Display will show a panel on each screen separately to allow you to do what you want.
What error reports exactly and how do they point to the dock?
Thanks for that!
1 and 2 marked “solved”
3 is a bit trickier since I just had a fleeting glimpse of the report. I barely remember having seen the word “…dock…” among the IT-gibberish.
It happened again. The report looks different - if I recall correctly. These are the first lines:
panic(cpu 1 caller 0xfffffe003020fd9c): Sleep transition timed out after 35 seconds while calling power state change callbacks. Suspected bundle: com.apple.driver.AppleTypeCPhy. Thread 0x80a90.
Debugger message: panic
Memory ID: 0x6
OS release type: User
OS version: 20C69
Kernel version: Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASE_ARM64_T8101
Fileset Kernelcache UUID: 3E6AA74DF723BCB886499A5AAB34FA34
Kernel UUID: 48F71DB3-6C91-3E62-9576-3A1DCEF2B536
iBoot version: iBoot-6723.61.3
secure boot?: YES
Paniclog version: 13
KernelCache slide: 0x0000000027e58000
KernelCache base: 0xfffffe002ee5c000
Kernel slide: 0x0000000028998000
Kernel text base: 0xfffffe002f99c000
Kernel text exec base: 0xfffffe002fa64000
mach_absolute_time: 0x9382f4b68b
Epoch Time: sec usec
Boot : 0x5fde0915 0x0005a7cd
Sleep : 0x5fde6fd0 0x0006c8e0
Wake : 0x5fde6fd0 0x00084ed6
Calendar: 0x5fde702e 0x0000829a
I am still convinced this is connected to the monitor. It keeps acting up … like … going into sleep mode, waking up and the same behavior all over again.
And again - after trying to start a program I had copied from my “old” Mac:
panic(cpu 4 caller 0xfffffe0012751068): initproc exited – exit reason namespace 7 subcode 0x1 description: assertion failed: 20C69: libxpc.dylib + 192296 [D87D7BAA-9E73-3A84-8247-3456B703C302]: 0xd
Debugger message: panic
Memory ID: 0x6
OS release type: User
OS version: 20C69
Kernel version: Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASE_ARM64_T8101
Fileset Kernelcache UUID: 3E6AA74DF723BCB886499A5AAB34FA34
Kernel UUID: 48F71DB3-6C91-3E62-9576-3A1DCEF2B536
iBoot version: iBoot-6723.61.3
secure boot?: YES
Paniclog version: 13
KernelCache slide: 0x000000000a35c000
KernelCache base: 0xfffffe0011360000
Kernel slide: 0x000000000ae9c000
Kernel text base: 0xfffffe0011ea0000
Kernel text exec base: 0xfffffe0011f68000
mach_absolute_time: 0x809edbd156
Epoch Time: sec usec
Boot : 0x5fde8b65 0x000dde8c
Sleep : 0x5fdf1d10 0x0007731b
Wake : 0x5fdf234d 0x000db256
Calendar: 0x5fdf7b74 0x00027fca
somewhere in the Apple message may help.
Mike
Thanks for finding and forwarding this.
I think I am at peace with things as they are, though it may not be as intended by Apple: I put the MBP to sleep and then switch off the monitor. The monitor would keep acting up (on-off-on-off) in its sleep mode if I’d let it run its course. I suppose this is why I did not see an involuntary restart which I described earlier during the last two days.
I’m also using an M1 with a TS3 Plus dock and a Thunderbolt monitor. I was regularly seeing the same problem - spontaneous reboots (usually overnight) with the same kernel panic error: “Suspected bundle: com.apple.driver.AppleTypeCPhy”
As a workaround, I’ve connected the display directly to the Mac instead of the dock. That was a few days ago and I’ve seen no crashes since.
I’ll report this to CalDigit.
My workaround - as mentioned before - is: putting the MBP to sleep and switching the monitor off. Let us know if you get any feedback from CalDigit.
CalDigit support wrote in part: “Our team is looking into this issue but at the moment, our workaround would also be to connect the display directly to the computer. I apologize for the inconvenience that this causes.”
It happened with the monitor plugged directly into the Mac as well.
Three days ago I switched to a Viewsonic VP2771 external Thunderbolt display without the TS3+ and the problem has not recurred. If my luck continues then the problem seems likely to be either:
a) combination of the M1, TS3+, and any external Thunderbolt Display
or
b) combination of the M1 and the Apple Thunderbolt Display, the TS3+ not being relevant.
I have more data now. My M1 MacBook Air rebooted itself while directly attached to the Apple Thunderbolt Display. The M1 is not connected to the TS3+ in any way - I’m getting power from the adapter that shipped with the M1. This would seem to absolve the TS3+ of any responsibility for the reboots I’m seeing.
The kernel panic report I see identifies AppleTypeCPhy, as did Hartmut’s. It begins:
panic(cpu 0 caller 0xfffffe0019c93d9c):
Sleep transition timed out after 35 seconds while calling power state change callbacks.
Suspected bundle: com.apple.driver.AppleTypeCPhy. Thread 0x263cf8.
I wonder what is behind all this. For the time being I’ll put the MBP to sleep and switch off my monitor.
I’m in the same boat, so to speak. I have an Apple Thunderbolt Display and a CalDigit TS3+ Dock, and while I initially suspected the dock, I experienced the panics (“Sleep transition timed out after 35 seconds”) with the TB Display connected directly and no CalDigit Dock. In these cases, the panic occurred “while calling power state change callbacks” and the suspected KEXT was “com.apple.driver.AppleThunderboltNHI”. However, and most recently, my M1 panicked when I woke up my M1 MBP after disconnecting it from the TB Display. Same 35-second sleep transition message, but this time “while entering darkwake on way to sleep” (weird, because I had woken up the MBP, but I guess the panic occurred while it was trying to enter darkwake). In addition, this time the suspected KEXT was “com.apple.iokit.IOUSBHostFamily” and not the “com.apple.driver.AppleThunderboltNHI.”
So I urge all those affected to contact Apple Support and file a ticket with Engineering including a sysdiag dump.
Having read all this, it seems that there is some funkiness popping up here and there with very specific gear combinations.
I’ll just add mine to it for fun:
I have at work the latest Intel Mac Mini which is going to run headless as a DICOM file server. For now I have an HP 27" 2K monitor attached. This results in having to hard reboot the Mini in the morning as it will have quit putting out video over night. When I simply turn off the monitor at the end of the day, there’s no problem at all.
Go figure…
My M1 mac is always attached to power. After 2 months it’s still rated at 100% capacity. the charging seems a little different, not always stay at exactly 100% and the last few percents charge more slowly.