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:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 31 11:25:00 +0000 2020
>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

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.