NetBSD Problem Report #53173
From www@NetBSD.org Tue Apr 10 18:33:40 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id CA7987A154
for <gnats-bugs@gnats.NetBSD.org>; Tue, 10 Apr 2018 18:33:39 +0000 (UTC)
Message-Id: <20180410183338.DA11B7A212@mollari.NetBSD.org>
Date: Tue, 10 Apr 2018 18:33:38 +0000 (UTC)
From: bsiegert@NetBSD.org
Reply-To: bsiegert@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: (earmv7hf) "go test net/http" locks up the machine
X-Send-Pr-Version: www-1.0
>Number: 53173
>Notify-List: gson@gson.org
>Category: port-arm
>Synopsis: (earmv7hf) "go test net/http" locks up the machine
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: port-arm-maintainer
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Apr 10 18:35:00 +0000 2018
>Closed-Date: Mon Jul 26 10:54:17 +0000 2021
>Last-Modified: Mon Jul 26 10:54:17 +0000 2021
>Originator: Benny Siegert
>Release: NetBSD 8.99.14, pkgsrc 2018Q1
>Organization:
The NetBSD Foundation
>Environment:
NetBSD (redacted) 8.99.14 NetBSD 8.99.14 (SUNXI) #0: Sun Mar 18 13:18:39 UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/SUNXI evbarm
go version go1.10 netbsd/arm
>Description:
I am running a continuous NetBSD builder on this OrangePi Plus 2E and noticed lockups of the system during tests. They tend to occur during the net/http test suite.
Symptom: the console stops updating or accepting input. The system gets warm, presumably the CPU is busy spinlocking.
>How-To-Repeat:
1. install lang/go from pkgsrc
2. Run "go test net/http", you may have to repeat a few times.
>Fix:
>Release-Note:
>Audit-Trail:
From: Benny Siegert <bsiegert@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Tue, 10 Apr 2018 19:56:16 +0000
It looks like the crash occurs in the test named
TestServerDuplicateBackgroundRead, defined here:
https://golang.org/src/net/http/serve_test.go#L5592
You can get more verbose output with "go test -v net/http".
From: Andreas Gustafsson <gson@gson.org>
To: bsiegert@NetBSD.org, gnats-bugs@NetBSD.org
Cc: Christos Zoulas <christos@zoulas.com>, Martin Husemann <martin@duskware.de>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Wed, 9 May 2018 11:35:35 +0300
Hello Benny,
I believe this kernel hang has been fixed in -current by
src/sys/kern/kern_lwp.c 1.192. Can you confirm this?
I have requested a pullup to -8 (#805), but it has been stalled due
to claims that it "breaks golang". If you can help either confirm or
refute those claims, that would also be helpful.
--
Andreas Gustafsson, gson@gson.org
State-Changed-From-To: open->feedback
State-Changed-By: gson@NetBSD.org
State-Changed-When: Wed, 09 May 2018 08:44:07 +0000
State-Changed-Why:
feedback requested
From: Benny Siegert <bsiegert@netbsd.org>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@netbsd.org, Christos Zoulas <christos@zoulas.com>,
Martin Husemann <martin@duskware.de>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Wed, 09 May 2018 20:43:50 +0000
On Wed, May 9, 2018 at 10:35 AM Andreas Gustafsson <gson@gson.org> wrote:
> I believe this kernel hang has been fixed in -current by
> src/sys/kern/kern_lwp.c 1.192. Can you confirm this?
I'll be able to confirm next week when I can try it on the real hardware,
is that okay?
> I have requested a pullup to -8 (#805), but it has been stalled due
> to claims that it "breaks golang". If you can help either confirm or
> refute those claims, that would also be helpful.
I remember 1.191 was supposed to fix hanging Go processes, yes. This
occurred on the amd64 builders though. You should be able to confirm this
by extracting the Go 1.10.1 tarball somewhere and then doing "cd src &&
all.bash" on a system with 1.192 on it.
--
Benny
From: Andreas Gustafsson <gson@gson.org>
To: Benny Siegert <bsiegert@netbsd.org>
Cc: gnats-bugs@netbsd.org,
Christos Zoulas <christos@zoulas.com>,
Martin Husemann <martin@duskware.de>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Thu, 10 May 2018 11:50:52 +0300
Benny Siegert wrote:
> On Wed, May 9, 2018 at 10:35 AM Andreas Gustafsson <gson@gson.org> wrote:
> > I believe this kernel hang has been fixed in -current by
> > src/sys/kern/kern_lwp.c 1.192. Can you confirm this?
>
> I'll be able to confirm next week when I can try it on the real hardware,
> is that okay?
I think so - as far as I'm concerned the main purpose of checking this
is just to allow the PR to be closed (or rather, switched to the
pending-pullups state). I have not heard anything from releng to
suggest that the outcome could affect their stance regarding the
pullup request (Martin please correct me if I'm wrong).
> > I have requested a pullup to -8 (#805), but it has been stalled due
> > to claims that it "breaks golang". If you can help either confirm or
> > refute those claims, that would also be helpful.
>
> I remember 1.191 was supposed to fix hanging Go processes, yes. This
> occurred on the amd64 builders though. You should be able to confirm this
> by extracting the Go 1.10.1 tarball somewhere and then doing "cd src &&
> all.bash" on a system with 1.192 on it.
I will follow up on this part separately in the context of releng
ticket #805.
--
Andreas Gustafsson, gson@gson.org
From: Martin Husemann <martin@duskware.de>
To: Andreas Gustafsson <gson@gson.org>
Cc: Benny Siegert <bsiegert@netbsd.org>, gnats-bugs@netbsd.org,
Christos Zoulas <christos@zoulas.com>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the
machine
Date: Thu, 10 May 2018 11:27:28 +0200
On Thu, May 10, 2018 at 11:50:52AM +0300, Andreas Gustafsson wrote:
> I think so - as far as I'm concerned the main purpose of checking this
> is just to allow the PR to be closed (or rather, switched to the
> pending-pullups state). I have not heard anything from releng to
> suggest that the outcome could affect their stance regarding the
> pullup request (Martin please correct me if I'm wrong).
Currently there is no clear picture which state is better, as soon
as that gets clear, we should make sure that -8 is in the best state
possible.
We want all (default) tests working and a well supported golang when
8.0 comes out. (And a pony, before we go on to world domination and the
desktop market)
Martin
From: Benny Siegert <bsiegert@netbsd.org>
To: Martin Husemann <martin@duskware.de>
Cc: Andreas Gustafsson <gson@gson.org>, gnats-bugs@netbsd.org,
Christos Zoulas <christos@zoulas.com>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Tue, 15 May 2018 21:10:59 +0200
So with a -current kernel from today (2018-05-15), "go test net/http" in Go
1.10 still locks up the machine, reproducibly.
From: Andreas Gustafsson <gson@gson.org>
To: Benny Siegert <bsiegert@netbsd.org>
Cc: Martin Husemann <martin@duskware.de>,
gnats-bugs@netbsd.org,
Christos Zoulas <christos@zoulas.com>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Wed, 16 May 2018 07:47:42 +0300
Benny Siegert wrote:
> So with a -current kernel from today (2018-05-15), "go test net/http" in Go
> 1.10 still locks up the machine, reproducibly.
I'm sorry to hear that. This is still on the Orange Pi
uniprocessor system, right?
Could you give step-by-step instructions for how to reproduce this on
a freshly installed -current, including the download and install of Go?
--
Andreas Gustafsson, gson@gson.org
From: Benny Siegert <bsiegert@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: port-arm-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, Andreas Gustafsson <gson@gson.org>
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Sun, 8 Jul 2018 13:44:37 +0200
Sorry for not following up earlier on this.
> Benny Siegert wrote:
> > So with a -current kernel from today (2018-05-15), "go test net/http" in Go
> > 1.10 still locks up the machine, reproducibly.
>
> I'm sorry to hear that. This is still on the Orange Pi
> uniprocessor system, right?
Yes, though it is a quad-core (4 CPUs).
> Could you give step-by-step instructions for how to reproduce this on
> a freshly installed -current, including the download and install of Go?
cd /usr/pkgsrc/lang/go
make package-install
go test net/http
--
Benny
From: Andreas Gustafsson <gson@gson.org>
To: Benny Siegert <bsiegert@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Mon, 9 Jul 2018 18:53:50 +0300
Benny Siegert wrote:
> cd /usr/pkgsrc/lang/go
> make package-install
> go test net/http
I don't have an Orange Pi, so I tried this on the closest
thing I have, a Raspberry Pi 3 model B, by installing
-current from 2018.07.08.14.46.23 and pkgsrc from
ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz as
of the same same day, but was unable to reproduce the
problem - the test passed:
ok net/http 94.189s
--
Andreas Gustafsson, gson@gson.org
From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the machine
Date: Tue, 7 Aug 2018 17:04:30 +0300
I have now run the net/http test case 100 times in a row on my
Raspberry Pi 3 model B, using -current from 2018.07.08.14.46.23 and
pkgsrc from ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz as
of today, and I'm still unable to make the machine lock up. Three out
of the 100 runs reported "--- FAIL: TestTimeoutHandlerRace", and the
other 97 passed.
These are the commands I ran:
cd /usr/pkgsrc/lang/go
make package-install
seq 100 | while read i
do
GOCACHE=off /usr/pkg/go/bin/go test net/http
done
--
Andreas Gustafsson, gson@gson.org
From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-arm/53173
Date: Mon, 21 Jan 2019 14:41:03 +0100
Sorry for the radio silence. This still locks up the system
reproducibly on my Orange Pi with go-1.11.3 from pkgsrc. Entering "go
test net/http" locks up the system without *any* kernel messages.
The kernel is
NetBSD 8.99.24 (SUNXI) #0: Sat Aug 18 06:52:57 2018
I'll try a newer kernel tomorrow.
--
Benny
From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-arm/53173
Date: Mon, 21 Jan 2019 14:52:40 +0100
On Mon, Jan 21, 2019 at 2:41 PM Benny Siegert <bsiegert@gmail.com> wrote:
>
> Sorry for the radio silence. This still locks up the system
> reproducibly on my Orange Pi with go-1.11.3 from pkgsrc. Entering "go
> test net/http" locks up the system without *any* kernel messages.
>
> The kernel is
> NetBSD 8.99.24 (SUNXI) #0: Sat Aug 18 06:52:57 2018
I think I have a lead:
The machine has an urtwn Wi-Fi dongle. If I pull out the dongle before
running the test, it succeeds (most of the time), as you describe. So
it sounds like a bug in the urtwn driver?
--
Benny
State-Changed-From-To: feedback->open
State-Changed-By: bsiegert@NetBSD.org
State-Changed-When: Mon, 21 Jan 2019 13:55:45 +0000
State-Changed-Why:
Feedback provided
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-arm/53173
Date: Mon, 21 Jan 2019 14:59:58 +0100
On Mon, Jan 21, 2019 at 01:55:00PM +0000, Benny Siegert wrote:
> The machine has an urtwn Wi-Fi dongle. If I pull out the dongle before
> running the test, it succeeds (most of the time), as you describe. So
> it sounds like a bug in the urtwn driver?
Can you try with the on-board interface? Maybe it is network connectivity
that makes the difference (instead of the concrete driver).
Martin
State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 05 Feb 2019 22:02:55 +0000
State-Changed-Why:
Duplicate kern/53922
State-Changed-From-To: closed->feedback
State-Changed-By: bsiegert@NetBSD.org
State-Changed-When: Sat, 16 Feb 2019 16:03:54 +0000
State-Changed-Why:
This is a different bug than 53922.
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: bsiegert@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the
machine
Date: Fri, 19 Apr 2019 18:12:23 +0200
--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
hello,
can you see if the attached patch fixes the issue for you ?
I had similar lock up on network load, and it should fix it.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=diff
Index: arm32/pmap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/arm/arm32/pmap.c,v
retrieving revision 1.371
diff -u -p -u -r1.371 pmap.c
--- arm32/pmap.c 28 Oct 2018 14:59:17 -0000 1.371
+++ arm32/pmap.c 19 Apr 2019 15:55:30 -0000
@@ -217,6 +217,10 @@
#include <arm/locore.h>
+#ifdef DDB
+#include <arm/db_machdep.h>
+#endif
+
__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.371 2018/10/28 14:59:17 skrll Exp $");
//#define PMAP_DEBUG
@@ -516,7 +520,8 @@ static size_t cnptes;
#endif
vaddr_t memhook; /* used by mem.c & others */
kmutex_t memlock __cacheline_aligned; /* used by mem.c & others */
-kmutex_t pmap_lock __cacheline_aligned;
+kmutex_t pmap_pg_lock __cacheline_aligned;
+kmutex_t kpm_lock __cacheline_aligned;
extern void *msgbufaddr;
int pmap_kmpages;
/*
@@ -538,9 +543,14 @@ vaddr_t pmap_directlimit;
static inline void
pmap_acquire_pmap_lock(pmap_t pm)
{
+#if defined(MULTIPROCESSOR) && defined(DDB)
+ if (__predict_false(db_onproc != NULL))
+ return;
+#endif
+
if (pm == pmap_kernel()) {
#ifdef MULTIPROCESSOR
- KERNEL_LOCK(1, NULL);
+ mutex_enter(&kpm_lock);
#endif
} else {
mutex_enter(pm->pm_lock);
@@ -550,9 +560,13 @@ pmap_acquire_pmap_lock(pmap_t pm)
static inline void
pmap_release_pmap_lock(pmap_t pm)
{
+#if defined(MULTIPROCESSOR) && defined(DDB)
+ if (__predict_false(db_onproc != NULL))
+ return;
+#endif
if (pm == pmap_kernel()) {
#ifdef MULTIPROCESSOR
- KERNEL_UNLOCK_ONE(NULL);
+ mutex_exit(&kpm_lock);
#endif
} else {
mutex_exit(pm->pm_lock);
@@ -562,20 +576,20 @@ pmap_release_pmap_lock(pmap_t pm)
static inline void
pmap_acquire_page_lock(struct vm_page_md *md)
{
- mutex_enter(&pmap_lock);
+ mutex_enter(&pmap_pg_lock);
}
static inline void
pmap_release_page_lock(struct vm_page_md *md)
{
- mutex_exit(&pmap_lock);
+ mutex_exit(&pmap_pg_lock);
}
#ifdef DIAGNOSTIC
static inline int
pmap_page_locked_p(struct vm_page_md *md)
{
- return mutex_owned(&pmap_lock);
+ return mutex_owned(&pmap_pg_lock);
}
#endif
@@ -3057,6 +3071,10 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
#else
const bool vector_page_p = (va == vector_page);
#endif
+ struct pmap_page *pp = pmap_pv_tracked(pa);
+ struct pv_entry *new_pv = NULL;
+ struct pv_entry *old_pv = NULL;
+ int error = 0;
UVMHIST_FUNC(__func__); UVMHIST_CALLED(maphist);
@@ -3072,6 +3090,12 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
* test for a managed page by checking pg != NULL.
*/
pg = pmap_initialized ? PHYS_TO_VM_PAGE(pa) : NULL;
+ /*
+ * if we may need a new pv entry allocate if now, as we can't do it
+ * with the kernel_pmap locked
+ */
+ if (pg || pp)
+ new_pv = pool_get(&pmap_pv_pool, PR_NOWAIT);
nflags = 0;
if (prot & VM_PROT_WRITE)
@@ -3095,7 +3119,8 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
if (l2b == NULL) {
if (flags & PMAP_CANFAIL) {
pmap_release_pmap_lock(pm);
- return (ENOMEM);
+ error = ENOMEM;
+ goto free_pv;
}
panic("pmap_enter: failed to allocate L2 bucket");
}
@@ -3118,8 +3143,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
} else
opg = NULL;
- struct pmap_page *pp = pmap_pv_tracked(pa);
-
if (pg || pp) {
KASSERT((pg != NULL) != (pp != NULL));
struct vm_page_md *md = (pg != NULL) ? VM_PAGE_TO_MD(pg) :
@@ -3228,9 +3251,10 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
}
#endif
} else {
- pmap_release_page_lock(md);
- pv = pool_get(&pmap_pv_pool, PR_NOWAIT);
+ pv = new_pv;
+ new_pv = NULL;
if (pv == NULL) {
+ pmap_release_page_lock(md);
pmap_release_pmap_lock(pm);
if ((flags & PMAP_CANFAIL) == 0)
panic("pmap_enter: "
@@ -3241,7 +3265,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
0, 0, 0, 0);
return (ENOMEM);
}
- pmap_acquire_page_lock(md);
}
pmap_enter_pv(md, pa, pv, pm, va, nflags);
@@ -3278,9 +3301,9 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
paddr_t opa = VM_PAGE_TO_PHYS(opg);
pmap_acquire_page_lock(omd);
- struct pv_entry *pv = pmap_remove_pv(omd, opa, pm, va);
+ old_pv = pmap_remove_pv(omd, opa, pm, va);
pmap_vac_me_harder(omd, opa, pm, 0);
- oflags = pv->pv_flags;
+ oflags = old_pv->pv_flags;
pmap_release_page_lock(omd);
#ifdef PMAP_CACHE_VIVT
@@ -3288,7 +3311,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
pmap_cache_wbinv_page(pm, va, true, oflags);
}
#endif
- pool_put(&pmap_pv_pool, pv);
}
}
@@ -3390,7 +3412,13 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
pmap_release_pmap_lock(pm);
- return (0);
+
+ if (old_pv)
+ pool_put(&pmap_pv_pool, old_pv);
+free_pv:
+ if (new_pv)
+ pool_put(&pmap_pv_pool, new_pv);
+ return (error);
}
/*
@@ -3425,6 +3453,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
/*
* we lock in the pmap => pv_head direction
*/
+
pmap_acquire_pmap_lock(pm);
#ifndef ARM_MMU_EXTENDED
@@ -3463,6 +3492,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
for (;sva < next_bucket;
sva += PAGE_SIZE, ptep += PAGE_SIZE / L2_S_SIZE) {
pt_entry_t opte = *ptep;
+ struct pv_entry *opv = NULL;
if (opte == 0) {
/* Nothing here, move along */
@@ -3480,17 +3510,15 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
*/
if (pg != NULL) {
struct vm_page_md *md = VM_PAGE_TO_MD(pg);
- struct pv_entry *pv;
pmap_acquire_page_lock(md);
- pv = pmap_remove_pv(md, pa, pm, sva);
+ opv = pmap_remove_pv(md, pa, pm, sva);
pmap_vac_me_harder(md, pa, pm, 0);
pmap_release_page_lock(md);
- if (pv != NULL) {
+ if (opv != NULL) {
if (pm->pm_remove_all == false) {
- flags = pv->pv_flags;
+ flags = opv->pv_flags;
}
- pool_put(&pmap_pv_pool, pv);
}
}
mappings += PAGE_SIZE / L2_S_SIZE;
@@ -3503,7 +3531,7 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
*/
l2pte_reset(ptep);
PTE_SYNC_CURRENT(pm, ptep);
- continue;
+ goto free_opv;
}
#ifdef ARM_MMU_EXTENDED
@@ -3545,6 +3573,12 @@ pmap_remove(pmap_t pm, vaddr_t sva, vadd
}
}
#endif
+free_opv:
+ if (opv) {
+ pmap_release_pmap_lock(pm);
+ pool_put(&pmap_pv_pool, opv);
+ pmap_acquire_pmap_lock(pm);
+ }
}
#ifndef ARM_MMU_EXTENDED
@@ -3807,7 +3841,6 @@ pmap_kremove(vaddr_t va, vsize_t len)
#ifdef UVMHIST
u_int total_mappings = 0;
#endif
-
PMAPCOUNT(kenter_unmappings);
UVMHIST_FUNC(__func__); UVMHIST_CALLED(maphist);
@@ -3815,15 +3848,15 @@ pmap_kremove(vaddr_t va, vsize_t len)
UVMHIST_LOG(maphist, " (va=%#jx, len=%#jx)", va, len, 0, 0);
const vaddr_t eva = va + len;
+ pmap_t kpm = pmap_kernel();
- pmap_acquire_pmap_lock(pmap_kernel());
+ pmap_acquire_pmap_lock(kpm);
while (va < eva) {
vaddr_t next_bucket = L2_NEXT_BUCKET_VA(va);
if (next_bucket > eva)
next_bucket = eva;
- pmap_t kpm = pmap_kernel();
struct l2_bucket * const l2b = pmap_get_l2_bucket(kpm, va);
KDASSERT(l2b != NULL);
@@ -3879,7 +3912,7 @@ pmap_kremove(vaddr_t va, vsize_t len)
total_mappings += mappings;
#endif
}
- pmap_release_pmap_lock(pmap_kernel());
+ pmap_release_pmap_lock(kpm);
cpu_cpwait();
UVMHIST_LOG(maphist, " <--- done (%ju mappings removed)",
total_mappings, 0, 0, 0);
@@ -5904,7 +5937,7 @@ pmap_growkernel(vaddr_t maxkvaddr)
* whoops! we need to add kernel PTPs
*/
- s = splhigh(); /* to be safe */
+ s = splvm(); /* to be safe */
mutex_enter(kpm->pm_lock);
/* Map 1MB at a time */
@@ -6147,15 +6180,8 @@ pmap_bootstrap(vaddr_t vstart, vaddr_t v
#endif
VPRINTF("locks ");
-#if defined(PMAP_CACHE_VIPT) && !defined(ARM_MMU_EXTENDED)
- if (arm_cache_prefer_mask != 0) {
- mutex_init(&pmap_lock, MUTEX_DEFAULT, IPL_VM);
- } else {
-#endif
- mutex_init(&pmap_lock, MUTEX_DEFAULT, IPL_NONE);
-#if defined(PMAP_CACHE_VIPT) && !defined(ARM_MMU_EXTENDED)
- }
-#endif
+ mutex_init(&pmap_pg_lock, MUTEX_DEFAULT, IPL_VM);
+ mutex_init(&kpm_lock, MUTEX_DEFAULT, IPL_VM);
mutex_init(&pm->pm_obj_lock, MUTEX_DEFAULT, IPL_NONE);
uvm_obj_init(&pm->pm_obj, NULL, false, 1);
uvm_obj_setlock(&pm->pm_obj, &pm->pm_obj_lock);
--cWoXeonUoKmBZSoM--
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-arm/53173: (earmv7hf) "go test net/http" locks up the
machine
Date: Sun, 8 Nov 2020 09:46:56 +0100
Any chance of retesting this with -current?
pro: pagedaemon changes could help
cons: might hit the infamous "amap corruption" bug seen on similar hardware
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 24 Jul 2021 20:33:15 +0000
State-Changed-Why:
this PR was improperly placed in feedback in Feb 2019
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 24 Jul 2021 20:33:38 +0000
State-Changed-Why:
however, a patch has since been proposed...
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-arm/53173 ((earmv7hf) "go test net/http" locks up the
machine)
Date: Sun, 25 Jul 2021 01:02:37 +0000
On Sat, Jul 24, 2021 at 08:33:38PM +0000, dholland@NetBSD.org wrote:
> Synopsis: (earmv7hf) "go test net/http" locks up the machine
>
> State-Changed-From-To: open->feedback
> State-Changed-By: dholland@NetBSD.org
> State-Changed-When: Sat, 24 Jul 2021 20:33:38 +0000
> State-Changed-Why:
> however, a patch has since been proposed...
Er, let me correct that: the patch was committed. Does this still
happen on current?
--
David A. Holland
dholland@netbsd.org
State-Changed-From-To: feedback->closed
State-Changed-By: bsiegert@NetBSD.org
State-Changed-When: Mon, 26 Jul 2021 10:54:17 +0000
State-Changed-Why:
The machine in question is running a 9.2_STABLE kernel now.
I tried running the test in question a number of times but
have not observed any lockups or errors.
So I think this is fixed. Thanks everyone!
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home