MacOS “Big Sur” first public version 11.0.1 that was released last week include major parts that are completely redone and is also affected by a series of severe bugs. I advise against upgrading until all serious issues are resolved.
None of them, check the error dialog after the reboot for cues. For me the problem was caused by AnyConnect 4.9.02xx that although it was compatible and worked with Big Sur, it caused the same situation. Was solved by doing by Cisco suggestion document.
Hi again.
The problem was not with Winbox or Wine, it was with macOS and LittleSnitch Firewall.
Is there a bug fix pending.
For users of LittleSnitch, in their webpage, they have a provisional solution:
When one of the following apps is started while the Little Snitch Network Extension is active, macOS Big Sur 11.0.1 may freeze and restart with a kernel panic:
panic(cpu 8 caller 0xffffff8003753a13): userspace watchdog timeout: no successful checkins from com.apple.remoted in 180 seconds
Kernel panics are, by definition, a bug in the operating system kernel. The problem has been reported to Apple and they are working on a fix. In fact it might already be fixed in Big Sur 11.1 (beta), but we don’t have enough reports to confirm this yet.
We currently don’t know a workaround or other mitigation for the bug (as of Little Snitch 5.0.2), but please stay tuned.
You may want to downgrade to Little Snitch 4.6 until the problem is fixed. See this FAQ entry for instructions how to make Little Snitch 4.6 run on macOS Big Sur.
Hi,
I test Wine with WinBox few days. From clean instalation of macOS Big Sur. Where It is working OK.
To installation of Little Snitch (with beta of 5.0.3 night build) and system will crash.
I spoke with Little Snitch support yesterday and today…I sent them URL for download WinBox (bundled package from nrlquaker)…I told them, how to reproduce this error (I made access to one of my router). They test it…and I got this answer today:
Thanks a lot! This reproduces the panic just fine. And we have 11.1 beta where no crash occurs, so I can see which packets were actually sent.
As far as I can tell, the crash occurs after a localnet broadcast where the local machine responds with its public IP. An incoming UDP packet, probably from netbiosd.