Hi, we're seeing a panic when we SIGSTOP the logd pid.
panic(cpu 2 caller 0xfffffe0020e9a364): userspace watchdog timeout: no successful checkins from logd (0 induced crashes) in 120 seconds
You may ask "well why would you do that?" and the answer is that we're seeing panics from watchdog/logd when we hammer the diskIO for a download/write (APFS sparse file creation) operation in our software.
Is it normal to see this?
Some other logs to understand what we're seeing:
com.apple.logd.store in TH_WAIT | TH_UNINT for ~120–200s
com.apple.firehose.drain-io / io-wl blocked behind it
then watchdog: no logd checkins for 120s
userspace watchdog timeout: no successful checkins from logd ... 120 seconds
unresponsive dispatch queue(s): com.apple.firehose.io-wl
Watchdog timeout panics when logd is unresponsive for so long are completely expected yes. As for:
we're seeing panics from watchdog/logd when we hammer the diskIO for a download/write (APFS sparse file creation) operation in our software.
Is the file sparse during the download process only, or is it supposed to remain sparse afterwards too? If the former, you are encouraged to use fcntl(F_PREALLOCATE) to fully allocate the blocks before initiating the download; this will ease the filesystem metadata load while subsequently writing out the file data and hopefully prevent this sort of issue. (It should also result in a more optimal write/allocation pattern for the file.)
