Thanks for that context Corvin. I was interpreting this code as a general vcpu synchronization fix that happens to target the deadlock at boot time, since I didn't see any conditional logic of it specifically written for boot and/or Windows 11. Sorry for the noise!

I think there may still be a relationship, jbo, since I've been having a different experience than you. However for now I'll try out some other bisecting before coming back to this. I'm going to test out switching out the "nvme" emulation for my drive to "ahci-hd" and see if that has any stability effect. I know people have also experienced issues with the nvme emulation before.

I also forgot to mention that I have both Windows 10 and 11 using the bhyve nvme, not virtio.. and I do notice that the NVME is running at 100% in the windows task manager (since I'm installing games on it and they take a while to install). I do remember reading somewhere else that some people were experiencing some crashes with the nvme driver but that was many years ago and it has been fixed.

I applied the patch on top of FreeBSD 14.3-RELEASE and tested the Windows 11 25H2 VM. It ran for about 1h34m before I got my first "WHEA_UNCORRECTABLE_ERROR" crash. On the next boot it lasted about 15m before it crashed with the same error. It may have possibly improved things given before it would crash more frequently, but there either might be a different issue, or another edge case. I'm going to test my Windows 11 24H2 VM which I already know how it normally behaves (or how often it "should" be crashing). I'll report back when I get more data.

It may be possible that the issues I've been experiencing on Windows 10 Pro (22H2) could also be related to this as well. Although my VM has been running fine for the past 5 days (no reboots). I'm going to apply this patch on my server (running FreeBSD 14.3-RELEASE) and will test the stability of it on Windows 10 Pro (my main gaming VM) which has been experiencing similar issues. I'll also test it on Windows 11 Pro (25H2) running in bhyve (all requirements bypassed).

In D37868#894489, @yuri_aetern.org wrote:

In D37868#894488, @jon_xyinn.org wrote:

Just got a notice on my original bug report for this. Thanks for taking this on @yuri_aetern.org.

Minor question, what does the U stand for in ${PORTSDIR:U/usr/ports, I'm familiar with the other parts of shell variable substitution / replacement, but I haven't seen the U before haha.

It's a make(1) construct now, meaning the same as '-' in shell var subst.

Just got a notice on my original bug report for this. Thanks for taking this on @yuri_aetern.org.

I sent this message earlier to Doug, but putting it here now that my review account is activated: