Re: port-alpha/53809: kernel locks up

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jan 2, 2019, at 1:30 AM, Martin Husemann <martin%duskware.de@localhost> wrote:
> 
> The following reply was made to PR port-alpha/53809; it has been noted by GNATS.
> 
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: 
> 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 =eject=
> [ 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().

Stay tuned

> 
> Guess I should stop trying DEBUG :-/
> 
> Martin
> 

-- thorpej