I've noticed that when an SMB link stalls, in a scenario such as a time machine network backup, due to any cause (NAS disk or network sleep, Wi-Fi roam/drop), in-flight SMB I/O blocks uninterruptibly instead of completing or returning an error. This unfortunately leaves APFS with outstanding I/O against a backing store that will neither finish nor fail.
This results in any sort of network stall turning into a kernel panic, since nothing in the I/O path enforces a timeout or error return. I've experienced this since Sequoia, and is still present in Golden Gate.
I'm sure if this is the best place to post this, but I have not been able to find a workaround to-date to prevent this from consistently happening. When I open my MacBook in the morning there's a 50/50 chance that it kernel panicked overnight.
I also filed a feedback (FB24460131), but have heard no response.
I’m not exactly sure how I could tweak its "soft" behaviour.
You can change its default behavior by modifying "/etc/nsmb.conf" (see "man nsmb.conf").
If the radar could possibly be referred internally to the correct CoreOS team, I would be extremely grateful.
It's with the right team; however, I'll warn you that you probably won't get a notification if/when your issue is addressed. At this point, most kernel panics (particularly watchdog panics) actually involve some degree of complex interaction between components, which means fixing them often involves multiple changes across different teams and different releases, all of which make it difficult to correctly track when an issue is actually "fixed" so that the bug can be sent back to you.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
