Since installing Catalina yesterday, multiple crashes from userspace watchdog timeout

So this seems like a consistent problem w/o a real workaround besides either not using clamshell mode and two monitors simultaneously or only using one monitor with clamshell. There's a thread about it on Macrumors. I think this is an issue w/ Catalina as I can use clamshell and two monitors on my Mojave mac without issues. Has

https://forums.macrumors.com/threads/16-inch-mbp-10-15-4-crashing-2-displays-clamshell.2232755/

Awesome, i'll try that out. Has anyone tried plugging their power on the right and running a fan? I think this might be a heating issue and I saw on macrumors that the left ports will trigger a kernel task when things heat up too much

I have been using a 16" MBPro running Catalina for a few months in clamshell mode with an external Philips monitor with no occurrence of this problem. Today I updated to 10.15.5 (from 10.15.4, I'm 90% sure) and my system now locks up and eventually crashes every time the display sleeps. Guess that's progress of a kind! If anyone out there is still running < 10.15.5, don't update.

I tried the suggestion about disabling spotlight, but the system crashed again the very next time it went to sleep.

Yuck!

Thanks - looping a video "fixes" the issue. No more crashes. I'm running in Clamshell mode with one Dell 2K monitor with 10.15.5. Was rebooting / crashing with the userspace watchdog timeout. I had already unchecked "Enable Power Nap..." - that had improved things but was still getting crashes. I also have "Prevent computer from sleeping..." checked. All of the problems started to occur when I upgraded to Catalina - especially around 10.15.4. At least the crashing / reboot stopped for now.

Running 'caffeinate -u -d' in a Terminal and powering off my external monitor (leaving the USB-C cable attached) when I step away from the system for any extended period seems to be a reliable workaround for me so far. Thanks to all the folks here for those suggestions!

Good suggestion to run ‘caffeinate -u -d’. Another option that seems to work is to avoid the clamshell mode altogether. Keeping the laptop lid open enough for the screen to stay on does the trick. I like to use the clamshell mode and place the laptop in a vertical stand, but this causes the crash to occur when connected to a external monitor.

I also have this issue. The only change was a new 49" Samsung C49HG90 monitor, running my laptop with the lid closed while connected to the monitor with HDMI. Consistently happens if I leave my laptop idle for a few hours. Catalina 10.15.5, MacBook Pro 2019.

Were you by any chance also running Time Machine backup?

Someone at work thinks Time Machine maybe a common trigger for some users. I'm just trying to gather any supporting evidence, or refute the claim so time is not wasted looking explicitly at Time Machine, but maybe on the conditions running Time Machine creates, and then see if there are other apps that create similar conditions.

Someone else found the panics went away after removing a USB dongle for wireless mouse, so it is also possible that Time Machine was talking to a USB disk, and it is the USB device that is the common item.

Anyway, I would be interested in what information you can pass along.

Hi Bob,

I do not use Time Machine. I have an attached HooToo USB hub with (i) power input, (ii) external mouse and sometimes (iii) printer connection. I also have a Belkin USB-C ethernet dongle plugged directly into the Mac, and sometimes a portable USB hard drive.

I never experienced this problem until I upgraded from 10.15.4 to 10.15.5 about ten days ago. I was using the same hardware setup for about 3 months prior to that, i.e. 2019 PowerBook with above doodads running in clamshell mode connected to an external Philips monitor. The thing went to sleep every night and woke up happily the next day for 90 days in a row. Since the 10.15.5 update it reliably hangs and reboots every single time it tries to wake up (until I started using the caffeinate workaround to keep it from sleeping).

Hope this info helps.

RogerDavis wrote:

Hi Bob,

I do not use Time Machine. I have an attached HooToo USB hub with (i) power input, (ii) external mouse and sometimes (iii) printer connection. I also have a Belkin USB-C ethernet dongle plugged directly into the Mac, and sometimes a portable USB hard drive.

I never experienced this problem until I upgraded from 10.15.4 to 10.15.5 about ten days ago. I was using the same hardware setup for about 3 months prior to that, i.e. 2019 PowerBook with above doodads running in clamshell mode connected to an external Philips monitor. The thing went to sleep every night and woke up happily the next day for 90 days in a row. Since the 10.15.5 update it reliably hangs and reboots every single time it tries to wake up (until I started using the caffeinate workaround to keep it from sleeping).

Hope this info helps.

Well, it says the Time Machine software is not the actual cause, but if the person at work was using a USB device, then maybe the common element are external devices, and a change to the macOS Catalina USB device drivers.

Historically (and I'm going back to some very early Mac OS X versions), there have been times perfectly working devices (or in one case 3rd party RAM) that started causing the system to panic after a major operating system upgrade. Now this could be because the device was not fully in spec, but the previous software did not exercise it in such a way that the spec flaws caused any problems. Or this could be changed macOS code that is not taking into account some real-world situations, and we get this watchdog timeout.

I do not know, but as I seem to like looking at kernel panic reports, I would like to either have watchdog timer magically go away (because I can never figure out from the panic report why it happened), or find a common root cause that I can give useful diagnostic suggests to users experiencing it, that might lead to them not having it any more.

So thank you for your feedback.

PS. As with most users in these forums, I'm just another user. In my day job I do work inside the kernel of other operating systems, which is why I seem to like looking at panic reports.

Panic(cpu 1 caller 0xffffff7f8d1aead5): userspace watchdog timeout: no successful checkins from com.apple.logd in 120 seconds

service returned not alive with context : unresponsive dispatch queue(s): com.apple.firehose.io-wl

service: com.apple.logd, total successful checkins since load (217162 seconds ago): 21688, last successful checkin: 120 seconds ago

service: com.apple.WindowServer, total successful checkins since load (217132 seconds ago): 21713, last successful checkin: 0 seconds ago.

After last update ( ) it still happens even while using the computer and it is not sleeping on screen saver. Yes there are multi monitors. Also since up grading to Catalina the system is running really slowly especially network connections.

  Model Name: iMac

 Model Identifier: iMac13,1

 Processor Name: Quad-Core Intel Core i5

 Processor Speed: 2.9 GHz

 Number of Processors: 1

 Total Number of Cores: 4

 L2 Cache (per Core): 256 KB

 L3 Cache: 6 MB

 Memory: 16 GB

 Boot ROM Version: 291.0.0.0.0

 SMC Version (system): 2.9f5

My last theory was blown to dust today (external devices).

So I'm invented a new theory. IPv6

I am standing on very thin ice with this theory, and it will not take much to disprove it.

The theory is that while IPv6 has been around for years, it has mostly been ignored, especially by home router vendors.

At work we have people that have to disable IPv6 to maintain a reliable VPN connection.

I think this is because there are hundreds of home routers old and new, and each with their own IPv6 implementation some which having not had their firmware updated in years. So IPv6 quality is questionable at best.

What if some of the watchdog timeout panics are because a change to Apple's IPv6 implementation running up against an IPv6 implementation that is not doing what Apple expects.

I know I'm grasping at straws, but I cannot find a common thread to watchdog timeout causes in the panics themselves.

To test my theory change IPv6 to "Link-local only"

System Preferences -> Network -> select interface in the left column -> Advanced -> TCP/IP -> Configure IPv6 -> Link-local only

I was wondering if there is a correlation between the "userspace watchdog timeout" Kernel Panic and this one?

panic(cpu 2 caller 0xffffff801ac9167c): Sleep transition timed out after 180 seconds while calling power state change callbacks. Suspected bundle: com.apple.iokit.IOGraphicsFamily. Thread 0xc5dbf.

Decided to see if Mac OS 11.0 Developer Beta 1 (20A4299v) would make a difference. As I noted previously, running 10.15.5 on my 2019 MacBook Pro 16" resulted in the WatchDog timeout as noted throughout this thread. Unfortunately, the problem remains. I submitted a Feedback / Problem report for what it is worth and referenced this discussion thread as well. With 26 pages of entries and more than 1000 saying "I have this question too", I sure hope this issue gets some attention. For now, I am just checking "Prevent computer from sleeping automatically when the display is off". That seems to prevent the issue and I can use the clamshell mode. All other settings are default, including leaving "Enable Power Nap while plugged into a power adapter" checked.

---------------------------------------------

panic(cpu 10 caller 0xffffff8012127a69): userspace watchdog timeout: no successful checkins from com.apple.WindowServer in 120 seconds

service: com.apple.logd, total successful checkins since wake (2900 seconds ago): 291, last successful checkin: 0 seconds ago

service: com.apple.WindowServer, total successful checkins since wake (2900 seconds ago): 266, last successful checkin: 120 seconds ago

service: com.apple.remoted, total successful checkins since wake (2900 seconds ago): 291, last successful checkin: 0 seconds ago

Backtrace (CPU 10), Frame : Return Address

0xffffffb0c81636a0 : 0xffffff800ecbe00d

0xffffffb0c81636f0 : 0xffffff800edfbf03

0xffffffb0c8163730 : 0xffffff800eded2da

0xffffffb0c8163780 : 0xffffff800ec63b2f

0xffffffb0c81637a0 : 0xffffff800ecbd84d

0xffffffb0c81638c0 : 0xffffff800ecbdb43

0xffffffb0c8163930 : 0xffffff800f4b88e4

0xffffffb0c81639a0 : 0xffffff8012127a69

0xffffffb0c81639b0 : 0xffffff801212778e

0xffffffb0c81639d0 : 0xffffff800f44191e

0xffffffb0c8163a20 : 0xffffff8012126c3c

0xffffffb0c8163b20 : 0xffffff800f44bc4b

0xffffffb0c8163c80 : 0xffffff800eda97c1

0xffffffb0c8163d90 : 0xffffff800ecc3ef7

0xffffffb0c8163e00 : 0xffffff800ec9a691

0xffffffb0c8163e60 : 0xffffff800ecb16f5

0xffffffb0c8163ef0 : 0xffffff800edd22c3

0xffffffb0c8163fa0 : 0xffffff800ec64316

Kernel Extensions in backtrace:

com.apple.driver.watchdog(1.0)[813A55E7-E453-3745-8BCB-454098C5D76F]@0xffffff8012124000->0xffffff8012127fff

Process name corresponding to current thread: watchdogd

Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:

20A4299v

In summary - here are the only things that consistently work for me as a temporary fix, per suggestions from others:

Run a QuickTime movie looping continuously in the background.

OR

Run 'caffeinate -u -d' in a Terminal session and power off the external monitor (leaving the USB-C cable / adapter attached) when away from the system.

I have not tried the eGPU approach but that seems to work for others as well.