From owner-freebsd-hackers@freebsd.org Wed Feb 24 23:37:16 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7437954D009 for ; Wed, 24 Feb 2021 23:37:16 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DmC4r2z7Zz4n2p for ; Wed, 24 Feb 2021 23:37:16 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from [192.168.1.10] (unknown [98.42.164.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 0B7BCF129 for ; Wed, 24 Feb 2021 23:37:15 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/16.45.21011103 Date: Wed, 24 Feb 2021 15:37:12 -0800 Subject: `sysctl vm.pmap.kernel_maps' spins on 12.2-RELEASE-p3 w/ nvdimm.ko From: Ravi Pokala To: "freebsd-hackers@freebsd.org" Message-ID: <2C7B4C6A-0432-44A6-B512-D7114F2B092B@freebsd.org> Thread-Topic: `sysctl vm.pmap.kernel_maps' spins on 12.2-RELEASE-p3 w/ nvdimm.ko Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 23:37:16 -0000 Hi folks, A colleague and I both independently observed `sysctl -a' appear to hang on nodes running FreeBSD 12.2-RELEASE-p3; it didn't emit any output, and ^C didn't kill it. We could still establish a new terminal session to the node, via SSH or serial console, and we were able to see that it was actually spinning, not hung, and was consuming an entire CPU. We eventually determined that it was specifically `sysctl vm.pmap.kernel_maps' which was spinning, and subsequently that it only spinned if nvdimm.ko was loaded. It was not necessary to access the device node associated with the NVDIMM; merely having the module loaded was sufficient. I know nvdimm(4) isn't terribly widely used, but hopefully someone who uses it can at least confirm my findings on this. Help in debugging would be even more appreciated. Thanks, Ravi (rpokala@)