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

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

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:38:35 +0200

 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.
 
 -- Ragge