NetBSD Problem Report #55325

From  Sun May 31 11:22:25 2020
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer " CA" (not verified))
	by (Postfix) with ESMTPS id 5DA011A9218
	for <>; Sun, 31 May 2020 11:22:25 +0000 (UTC)
Message-Id: <>
Date: Sun, 31 May 2020 11:22:24 +0000 (UTC)
Subject: oea/pmap: inconsistency in usage of two PVO pools
X-Send-Pr-Version: www-1.0

>Number:         55325
>Category:       port-powerpc
>Synopsis:       oea/pmap: inconsistency in usage of two PVO pools
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-powerpc-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 31 11:25:00 +0000 2020
>Closed-Date:    Wed Jul 07 00:28:39 +0000 2021
>Last-Modified:  Wed Jul 07 00:28:39 +0000 2021
>Originator:     Rin Okuyama
>Release:        9.99.64
Department of Physics, Meiji University
NetBSD macmini 9.99.64 NetBSD 9.99.64 (GENERIC) #65: Sun May 31 01:11:41 JST 2020  rin@latipes:/usr/src/sys/arch/macppc/compile/GENERIC macppc
In powerpc/oea/pmap.c, there are two pools of PVO:
- pmap_upvo_pool for PVO entries for unmanaged pages
- pmap_mpvo_pool for PVO entries for managed pages

At the moment, we determine to which pool freed PVO is put back by
PVO_MANAGED flag. However, this is *wrong* when PVO is obtained by
pmap_pvo_reclaim(). That is, PVO for unmanaged pages can be reclaimed
from pool for managed, and vice versa.
Enable DIAGNOSTIC, and put a system in heavy memory pressure, like

$ cd /usr/pkgsrc/devel/gcc10 && make MAKE_JOBS=2

Then, the system crashes for a while as:

panic: pr_phinpage_check: [pmap_upvopl] item 0xf619c0 poolid 36 != 1
Although I'm not sure whether this is a correct fix or not, but this
patch seems to fix a problem:

Here, I introduced a new flag that represents from which pool PVO is

#define PVO_POOL_MANAGED        0x0080
#define PVO_POOL_MANAGED_P(pvo) ((pvo)->pvo_vaddr & PVO_POOL_MANAGED)

Then, use this flag instead of PVO_MANAGED to determine to which pool
we should pool_put(9) into.

Alternatively, we can reclaim PVO from the same pool in
pmap_pvo_reclaim(). However, this attempt fails for me, by ended up in:

panic: pmap_pvo_enter: failed


From: "Martin Husemann" <>
Subject: PR/55325 CVS commit: src/sys/arch/powerpc/oea
Date: Sun, 27 Jun 2021 12:26:33 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sun Jun 27 12:26:33 UTC 2021

 Modified Files:
 	src/sys/arch/powerpc/oea: pmap.c

 Log Message:
 PR 55325: unify both pvo pools (for managed and unmanaged pages).
 Analyzis by rin, fix suggested by chs.

 To generate a diff of this commit:
 cvs rdiff -u -r1.105 -r1.106 src/sys/arch/powerpc/oea/pmap.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Havard Eidnes <>
Subject: Re: port-powerpc/55325: oea/pmap: inconsistency in usage of two
 PVO pools
Date: Wed, 07 Jul 2021 00:01:34 +0200 (CEST)


 after the commit of src/sys/arch/powerpc/oea/pmap.c mentioned in
 this PR, I have spun up my dual-CPU G4 again which earlier fell
 victim to this problem, and this time it (unsurprisingly, perhaps)
 no longer fails with this error.

 In fact, it managed to complete a full build of wip/rust using both
 CPUs, and my trust in the system's stability for the upcoming
 release has solidified.

 So ... as far as I'm concerned this PR can now be closed.


 - Havard

State-Changed-From-To: open->closed
State-Changed-When: Wed, 07 Jul 2021 00:28:39 +0000
confirmed fixed, thanks


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD:,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.