[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-alpha/53809: kernel locks up
The following reply was made to PR port-alpha/53809; it has been noted by GNATS.
From: Jason Thorpe <thorpej%me.com@localhost>
To: "gnats-bugs%netbsd.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Subject: Re: port-alpha/53809: kernel locks up
Date: Wed, 2 Jan 2019 09:31:49 -0800
> On Jan 2, 2019, at 1:30 AM, Martin Husemann <martin%duskware.de@localhost> =
> The following reply was made to PR port-alpha/53809; it has been noted =
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Subject: Re: port-alpha/53809: kernel locks up
> Date: Wed, 2 Jan 2019 10:29:30 +0100
> Another DIAGNOSTIC hit:
> [ 2741.2335401] Using reserved ASN! (line 2135)
> [ 2741.2335401] panic: PMAP_ACTIVATE_ASN_SANITY
> [ 2741.2335401] cpu0: Begin traceback...
> [ 2741.2335401] alpha trace requires known PC =3Deject=3D
> [ 2741.2335401] cpu0: End traceback...
> [ 2741.2335401] cpu1: shutting down...
Hm... A call to pmap_asn_alloc() immediately precedes the call to =
PMAP_ACTIVATE() on line 2135, and one should never come out of there =
with PMAP_ASN_RESERVED, unless the pmap is referencing the =
kernel_lev1map. The the sanity check fails because the pmap is NOT =
referencing kernel_lev1map, but the pmap's ASN info for the current CPU =
has PMAP_ASN_RESERVED assigned.
Any process that's running user code should never be referencing =
kernel_lev1map, so I'm having a hard time seeing how two threads could =
be racing here (the pmap is not locked in pmap_activate()). Though, =
maybe there's some case I'm not thinking of. I'll build you a GENERIC =
kernel with a change to lock the pmap across pmap_activate(), and also =
to disable the problematic test in pmap_emulate_reference().
> Guess I should stop trying DEBUG :-/
Main Index |
Thread Index |