CalDigit TS3 Plus -> 16" M1 Max MBP: Kernel Panic repeatedly on sleep.

[KuDeTa]

I've had this beast of a machine (16" M1 Max, 64GB Ram, 2TB) for only 3 days and appear to have hit a major snag with my external dock - a CalDigit TS3+.

Every time the Mac goes to sleep with the dock plugged in, after a few minutes it reboots with the following kernel panic.

panic(cpu 2 caller 0xfffffe002d557c40): "pci-bridge: pci restore invalid deviceid 0x15d48086\n" @IOPCIBridge.cpp:1524
Debugger message: panic
Memory ID: 0x6
OS release type: User
OS version: 21A559
Kernel version: Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
Fileset Kernelcache UUID: 3B2CA3833A09A383D66FB36667ED9CBF
Kernel UUID: 67BCB41B-BAA4-3634-8E51-B0210457E324

I've copied a couple of examples out here: https://pastebin.com/4Vx83HQ6.

Attached items:
Hub (TB3)
-> LG 38WN95C (TB3) main monitor
-> LG 32UN880-B (DP) second display
-> Sensei Series 10 Mouse (USB A)
-> Ethernet

I can't give an absolutely cast iron guarantee at this stage, but by disconnecting the dock and plugging everything in directly or via the monitor hubs, i don't seem to be able to reproduce this any more, so i'm pretty confident it's the dock.

I reached out to CalDigit who tell me that their docks are basically unreliable on all mac software since BigSur - and they don't have a fix of any kind and it's up to Apple.

Anyone else having a similar experience?

 

[KuDeTa]

Thank you for contacting us. Unfortunately, 11.0 or higher has known issues of kernal panics, here is an official forum post about kernel panics / crashes on Big Sur: https://developer.apple.com/forums/thread/678644

The issues with kernel panics and crashes are purely a Mac issues unfortunately and has been present since the start of Big Sur. It still hasn’t been fixed to this day with more and more reports about it from users using different brands of docking stations and some even directly connecting using a straight adapter or no adapter at all. MacRumors has reports on it, the official forums have reports on it, Reddit has reports on it and we have been trying to push Apple themselves for a fix to see if we can get them to take action but nothing has happened as of late. Kernal panics/crashes have been made worse with each Big Sur OS version they release and they originally started back at the end of Catalina with 10.15.6 and 10.15.7.

We’re going to be honest with you, there is no firmware updates or troubleshooting we can provide that we haven’t tried already and it has all been unsuccessful. We took it upon ourselves, as a company, to try and help customers with these issues to no success. No matter what we did, be it firmware, software or drivers the problem still occurred as it’s background processes of Big Sur and something to do with their OS code that is causing it. When this issue first occurred we had this knowledge base article about it: https://www.caldigit.com/my-intel-based-mac-crashes-when-un-docking-or-re-docking/.

Big Sur has been, quite honestly, a mess of an OS. So many issues and bugs and a lot of new reports of different issues daily with different OS version of Big Sur (from 11.1 all the way up to 11.4). It’s not just kernel panics but Display issues too which MacRumors has reported on here: https://www.macrumors.com/2021/02/03/macos-big-sur-external-display-issues/. At this stage we have no idea if or when Apple will decide to fix this and with so many reports its worrying that no action has been taken by them.

Reply from CalDigit. These links are confusing as the seem to be focused on Intel machines, and i certainly don't seem to be getting the same stack traces. I've asked them to have another look.

 

[joevt]

I did a search for pci restore invalid deviceid on opensource.apple.com. The latest version (for Big Sur 11.5) is this one:
https://opensource.apple.com/source/IOPCIFamily/IOPCIFamily-428.80.2/IOPCIBridge.cpp.auto.html

The value 0x15d48086 is stored in a variable named data and represents the device ID/vendor ID of the Alpine Ridge Thunderbolt controller in the Thunderbolt dock:
https://pci-ids.ucw.cz/read/PC/8086/15d4

The data variable is initialized like this:
data = device->configRead32(kIOPCIConfigVendorID);
The value seems to be normal and valid (if it were 0xffffffff then it means the device might be asleep still or disabled or hiding and 0xffff0001 would mean the device is not ready yet).

According to https://en.wikipedia.org/wiki/PCI_configuration_space , it is expected for the vendor id (8086) to follow the device ID (15d4) so that's ok.

The value is compared to a field in the device's savedConfig state. Apparently, there's a mismatch which causes the panic. The panic only occurs for non-Intel Macs (M1 Macs don't have ACPI_SUPPORT which I guess might be used to finish waking the device properly on an Intel Mac).

The problem with the panic message is that it doesn't tell us what the savedConfig value is (the expected device/vendor id) which would help discovering the actual cause of the problem. savedConfig is supposed to be a copy of the PCI configuration space registers. I suppose it may be a quirk of some Thunderbolt controllers that the vendor or device ID might change. For example, a host Thunderbolt controller can hide itself by setting it's vendor and device IDs to 0xffff until a thunderbolt driver in firmware or the macOS enables power to the Thunderbolt controller. But the CalDigit is a peripheral device, not a host device.

Maybe something weird happened such as the bus numbers changing so that the vendor/device is being read from a different PCIe device.

Maybe the bus number is correct but it's reading from a different PCIe domain. I think M1 Macs are the first Macs to have multiple PCIe domains such that devices in different domains can have the same bus/device/function number. I think it's unlikely for Apple to screw this up though. Certainly the value in savedConfig would tell us if this were the problem.

Anyway, I would use the Apple Feedback Assistant to send the info to Apple and tell them to fix their sh*t. Then I would disable sleep and wait half a decade.

 

[KuDeTa]

I did a search for pci restore invalid deviceid on opensource.apple.com. The latest version (for Big Sur 11.5) is this one:
https://opensource.apple.com/source/IOPCIFamily/IOPCIFamily-428.80.2/IOPCIBridge.cpp.auto.html

The value 0x15d48086 is stored in a variable named data and represents the device ID/vendor ID of the Alpine Ridge Thunderbolt controller in the Thunderbolt dock:
https://pci-ids.ucw.cz/read/PC/8086/15d4

The data variable is initialized like this:
data = device->configRead32(kIOPCIConfigVendorID);
The value seems to be normal and valid (if it were 0xffffffff then it means the device might be asleep still or disabled or hiding and 0xffff0001 would mean the device is not ready yet).

According to https://en.wikipedia.org/wiki/PCI_configuration_space , it is expected for the vendor id (8086) to follow the device ID (15d4) so that's ok.

The value is compared to a field in the device's savedConfig state. Apparently, there's a mismatch which causes the panic. The panic only occurs for non-Intel Macs (M1 Macs don't have ACPI_SUPPORT which I guess might be used to finish waking the device properly on an Intel Mac).

The problem with the panic message is that it doesn't tell us what the savedConfig value is (the expected device/vendor id) which would help discovering the actual cause of the problem. savedConfig is supposed to be a copy of the PCI configuration space registers. I suppose it may be a quirk of some Thunderbolt controllers that the vendor or device ID might change. For example, a host Thunderbolt controller can hide itself by setting it's vendor and device IDs to 0xffff until a thunderbolt driver in firmware or the macOS enables power to the Thunderbolt controller. But the CalDigit is a peripheral device, not a host device.

Maybe something weird happened such as the bus numbers changing so that the vendor/device is being read from a different PCIe device.

Maybe the bus number is correct but it's reading from a different PCIe domain. I think M1 Macs are the first Macs to have multiple PCIe domains such that devices in different domains can have the same bus/device/function number. I think it's unlikely for Apple to screw this up though. Certainly the value in savedConfig would tell us if this were the problem.

Anyway, I would use the Apple Feedback Assistant to send the info to Apple and tell them to fix their sh*t. Then I would disable sleep and wait half a decade.

Great post and thanks for the detective work. I’ve already opened a case with Apple and sent some feedback.

Probably easier just to buy a new dock at this point, once we know certain models work reliably. :sigh:.

One thing I’ve noticed is that the system seems more stable if I keep the dock plugged in but put the monitors directly into the usb/tb ports. Is it possible that the monitor + dock combo are the ultimate cause?

 

[joevt]

Is it possible that the monitor + dock combo are the ultimate cause?

I don't think so. Display stuff is separate from PCI stuff in a Thunderbolt dock.

 

[octhegreat]

I have a similar issue. The external displays connected via CalDigit TS3+ randomly turned on while my M1M Mac was in sleep mode.

Occasionally after the MBP woke from sleep, the monitors can't wake up.

 

[likegadgets]

FWIW I have a similar setup. M1 Max, 64MB with 4TB. I have a Caldigit TS3+ with almost all ports used. An LG 5K connected to it. An Apple XDR is connected to a second Thunderbolt port on the Mac. So far so good - no crashes and it as bee continuously on (and goes to sleep) for more than a week

 

[octhegreat]

FWIW I have a similar setup. M1 Max, 64MB with 4TB. I have a Caldigit TS3+ with almost all ports used. An LG 5K connected to it. An Apple XDR is connected to a second Thunderbolt port on the Mac. So far so good - no crashes and it as bee continuously on (and goes to sleep) for more than a week

M1M 64GB & 4TB also lol.. my solution is a switch that I can turn on and off the Caldigit dock so I don't have to unplug the TB cable & shorten the life of the USB C port

 

[datboi]

Hi!

I have same problem with my Caldigit TS3+ dock since I've been using it with the new MacBook Pro 16 M1 Max.

When I'm turning off MacBook, or going to sleep TS3+ dock is going to sleep for about 10 seconds. Then it wakes up (blue light), then after about 20 seconds goes to sleep, wakes up after 10 s. and loop continues. Sometimes after a short period, Mac is resetting itself and displaying kernel panic.

My exact setup is:
Caldigit TS3+ dock connected to MacBook Pro 16 M1 Max 64Gb (only one cable connected to laptop).

TS3+ connections:

• Display Port - LG 4K monitor
• Ethernet Cable
• USB lightning Cable
• USB Logitech Unifying Reciever

I've tried unplugging each cable at once and the problem persists.

Also tried plugging in MagSafe charging cable but with no results.

I had run a couple of more tests to pinpoint where is the problem.
So I unplugged everything from the dock, besides power and tb3 cable, and connected it to three of my Macs

1. iMac Pro with Monterey - no issues
2. MacBook Pro 13 M1 Big Sur - no issues
3. MacBook Pro 16 M1 Max Monterey (fresh from the box, latest OS update) - the dock is in a loop

I believe it is not OS specific problem but a hardware / firmware issue with MacBook M1 Max ports. Yes, I tried this on all 3 usb-c ports.

I'm not sure if this is a problem with my specific Mac or it is a common issue with 87W charging docks. I've contacted Caldigit support, and they said the problem is at Apple's side.

The 12.1 update did't solved this issue.

 

[rbmanian75]

for me ts3 plus docks works well. but i have an issue. when i restart the m1 max with ts3 plus dock connected the magsafe light turns amber and stays like that even though if it is fully charged? Do you have this kind of issue

for the loop problem try to disable the wake for lan access.

 

[datboi]

for me ts3 plus docks works well. but i have an issue. when i restart the m1 max with ts3 plus dock connected the magsafe light turns amber and stays like that even though if it is fully charged? Do you have this kind of issue

for the loop problem try to disable the wake for lan access.

Disabling wake for lan don't solve this issue

 

[dingobiatch]

Just a heads up, I have the same problem (M1 Max, TS3+) but my buddy also has this issue but with an Anker USB hub.

 

[pmozdzanowski]

I have exact same issue with TS3+ and M1 Max 14"

 

[pmozdzanowski]

It looks like ticking "Prevent your Mac from automatically sleeping when the display is off" resolved the problem for me:

 

[dingobiatch]

It looks like ticking "Prevent your Mac from automatically sleeping when the display is off" resolved the problem for me:
View attachment 1943321

This didn’t fix it for me, because the computer still seems to sleep if I turn my external monitor off while I’m in clamshell mode.

Since then I’ve also tried amphetamine, which seems to prevent the issue sometimes, but it’s still happening.

 

[Inconsequential]

Bumping this as this is still happening to me too (loginwindow crashes too), even with setting caffeinate -i (which is supposed to stop it sleeping...)

Contacted Caldigit to ask for an ETA for a fix as it works 100% OK without the dock connected...

 

[childoftheko4n]

i know this doesnt answer the problem above, but I am waiting on my MBP to ship, and was eyeing a CalDigit (the HDMI dock one though). With these docks, what is the best way to dismount? Do you manually unmount drives that are plugged into your dock before disconnecting, or are you able to unmount the entire dock at once?

 

[Inconsequential]

Caldigit has an app that runs in the menu bar to disconnect all external drives.

I however just select them all and eject that way.

Also Caldigit got back to me saying nothing they can do, all with Apple, so I've tried to escalate it with Apple.

Sadly because I'm running a PB they can't do anything so I'll have to wait until 12.5 is out...

 

[lepatrick]

It's still there:

MacBook Pro M1Pro, Monterey 12.6, Caldigit TS3+ --> Panic
MacBook Pro M1Pro, Monterey 12.6, Caldigit Element Hub --> Panic

 

[Inconsequential]

Its been fixed for me and has been for a while in Ventura.

 

[rex4mac]

many users had been reported the same blanking video issues for years, and most cases had been happened to with Apple silicon MB or MBP . It's proofed that had been caused by the firmware of CalDigit docking station.

Blank screen issues: CalDigit TS3+ and CalDigit TS4 docking station with MBP M1/M2/M3 ...etc.

Solution: Monitor setting DP 1.4 changed to DP1.2 .
for monitors without the DP version setting, then you need to turn off -on the monitor or unplug/replug the monitor.

https://discussions.apple.com/thread/254605412?sortBy=best