port-amd64/59496: netbsd-10 assert_sleepable panic on i9

[Manuel.Bouyer%lip6.fr@localhost]

>Number:         59496
>Category:       port-amd64
>Synopsis:       netbsd-10 assert_sleepable panic on i9
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 30 12:20:00 +0000 2025
>Originator:     Manuel Bouyer
>Release:        NetBSD 10.1_STABLE
>Organization:
>Environment:
System: NetBSD armandeche.soc.lip6.fr NetBSD 10.1_STABLE (GENERIC_CAN) #32: Mon Jun 30 13:26:31 CEST 2025 amd64
Architecture: x86_64
Machine: amd64
>Description:

A recent netbsd-10 kernel built with DIAGNOSCIC panics at boot on i9 with:
panic()
assert_sleepable()
pool_get()
pool_cache_get_slow()
pool_cache_get_paddr()
uvm_map_clip_start()
uvm_map_protect()
fpuinit_mxcsr_mask()
cpu_init()
cpu_hatch()

It seems that uvm_map_protect() just isn't ready to be called from
non-sleepable context.
BTW, fpuinit_mxcsr_mask() calls uvm_km_alloc() with UVM_KMF_WAITVA which
is probably wrong too if we can't sleep here.

Older netbsd-10 kernels didn't have this issue, probably a fallout from
ticket 1119


>How-To-Repeat:
	boot a netbsd-10 kernel with DIAGNOSCTIC on a recent CPU
>Fix:
	workaround: commenting out the uvm_km_protect() calls in
	fpuinit_mxcsr_mask() allows the machine to boot.