NetBSD Problem Report #59496

From Manuel.Bouyer@lip6.fr  Mon Jun 30 12:17:14 2025
Return-Path: <Manuel.Bouyer@lip6.fr>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 329D91A923A
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 30 Jun 2025 12:17:14 +0000 (UTC)
Message-Id: <20250630120804.62A4A10A32@armandeche.soc.lip6.fr>
Date: Mon, 30 Jun 2025 14:08:04 +0200 (CEST)
From: Manuel.Bouyer@lip6.fr
Reply-To: Manuel.Bouyer@lip6.fr
To: gnats-bugs@NetBSD.org
Subject: netbsd-10 assert_sleepable panic on i9
X-Send-Pr-Version: 3.95

>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.

Home	PR Database Search