Re: port-vax/55415: vax no longer preempts in a timely fashion

[oster%netbsd.org@localhost]

The following reply was made to PR port-vax/55415; it has been noted by GNATS.

From: oster%netbsd.org@localhost
To: Anders Magnusson <ragge%tethuvudet.se@localhost>, gnats-bugs%netbsd.org@localhost,
 oster%netbsd.org@localhost
Cc: 
Subject: Re: port-vax/55415: vax no longer preempts in a timely fashion
Date: Thu, 30 Jul 2020 14:49:55 -0600

 On 7/30/20 1:38 PM, Anders Magnusson wrote:
 > 
 > 
 > Den 2020-07-30 kl. 21:30, skrev oster%netbsd.org@localhost:
 >> The following reply was made to PR port-vax/55415; it has been noted 
 >> by GNATS.
 >>
 >> From: oster%netbsd.org@localhost
 >> To: gnats-bugs%netbsd.org@localhost, port-vax-maintainer%netbsd.org@localhost,
 >>   gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, oster%netbsd.org@localhost
 >> Cc:
 >> Subject: Re: port-vax/55415: vax no longer preempts in a timely fashion
 >> Date: Thu, 30 Jul 2020 13:25:48 -0600
 >>
 >>   On 7/30/20 1:10 PM, Anders Magnusson wrote:
 >>   > The following reply was made to PR port-vax/55415; it has been 
 >> noted by GNATS.
 >>   >
 >>   > From: Anders Magnusson <ragge%tethuvudet.se@localhost>
 >>   > To: gnats-bugs%netbsd.org@localhost, oster%netbsd.org@localhost
 >>   > Cc:
 >>   > Subject: Re: port-vax/55415: vax no longer preempts in a timely 
 >> fashion
 >>   > Date: Thu, 30 Jul 2020 21:07:37 +0200
 >>   >
 >>   >   >   I've done a bit more debugging...   What I'm seeing is that in
 >>   >   >   kern_runq.c:sched_resched_cpu() the call to 
 >> cpu_need_resched(ci, l, f)
 >>   >   >   happens, cpu_need_resched() sets up the AST.  Except it's 
 >> only once in a
 >>   >   >   while that the trap with the AST fires, userret() gets 
 >> called, and
 >>   >   >   preemption happens!  Sometimes the trap with AST fires once, 
 >> and not
 >>   >   >   again... sometimes it fires 5 times in a row, and then 
 >> misses.... but I
 >>   >   >   don't know why an AST that has been posted would 
 >> subsequently get missed
 >>   >   >   sometimes....
 >>   >   >
 >>   >   >   So it's able to hit a situation where cpu_need_resched() is 
 >> called, but
 >>   >   >   the corresponding AST never fires. The loop in 
 >> sched_resched_cpu() that
 >>   >   >   sets ci->ci_want_resched keeps thinking (correctly!) that 
 >> the AST has
 >>   >   >   already been setup, and so doesn't try to call 
 >> cpu_need_resched() again.
 >>   >   >     When it gets 'stuck' like this, we never see an AST until 
 >> the process
 >>   >   >   completes.  (nor do we see preemption until the process 
 >> completes.)
 >>   >   >   That seems to be because if I check the AST status with:
 >>   >   >
 >>   >   >     if (mfpr(PR_ASTLVL) != AST_OK)
 >>   >   >
 >>   >   >   that condition is always true... (meaning the AST is not 
 >> setup...)
 >>   >   >
 >>   >   >   Any ideas on how an AST can just 'disappear'?  (I'm using 
 >> the same
 >>   >   >   mfpr() check right after the mtpr() setting of PR_ASTLVL, 
 >> and there it
 >>   >   >   thinks it's set just fine... so how does it go missing a few 
 >> moments
 >>   >   >   after????)
 >>   >   >
 >>   >   The AST is only acked if it has been taken.  This is done in 
 >> trap(),
 >>   >   just before userret() is called.
 >>   >   Losing the AST should not be possible.
 >>   >
 >>   >   Reading the VAX manual says that ASTLVL is not saved by svpctx, 
 >> so if a
 >>   >   process switch occurs before the AST is delivered it will be lost.
 >>   >   Can this ever happen?
 >>   Hmm... svpctx happens in softint_common(), which seems to be called 
 >> from
 >>   lots of softFOO functions...   So if I'm reading this correctly, if we
 >>   happen to get into softint_common then the AST will get lost....
 > AST is itself a softint (called at Softint level 2).
 > But we should probably add saving of AST levels in the PCB anyway.
 
 I'm happy to test :)
 
 Later...
 
 Greg Oster