Re: [OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)

[Paul Gortmaker <paul.gortmaker@windriver.com>]

[Re: [OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)] On 16/08/2023 (Wed 09:55) Rasmus Villemoes wrote:

> On 15/08/2023 15.08, Paul Gortmaker via lists.openembedded.org wrote:
> > [Dilemma on changes - merge or not to merge (e.g. 6.4)] On 14/08/2023 (Mon 10:54) Richard Purdie wrote:
> > 
> >> Remaining are:
> >>   * an error upon boot on preempt-rt on qemux86-64
> >>      (e.g. https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/7616/steps/36/logs/stdio)
> >>      We'll probably just have to ignore it in parselogs as it has been??
> >>      around for a while and nobody seems interested in fixing it upstream.
> > 
> > Just back from vacation and I see an internal report of 10-ish at boot
> 
> it seems to be rate-limited to 10 per boot, so it should never appear
> more than those 10ish times:
> 
> static bool report_idle_softirq(void)
> {
> ...
>         if (ratelimit >= 10)
>                 return false;
> ...
>         ratelimit++;
> ...

Amusingly enough - you were looking right at the problem.  Just a few
stable kernels ago, it was inadvertently ratelimited to zero.  :-P

https://lists.openembedded.org/g/openembedded-core/message/186343

Paul.
--

> }
> 
> (it's all non-atomic/lockfree, so ofc it could just happen to get
> emitted 11 or 12 times if the stars align just right...)
> 
> > 
> >   NOHZ tick-stop error: local softirq work is pending, handler #80!!!
> > 
> > ..on the 6.1.43-rt10-yocto-preempt-rt kernel, on real hardware.  So it
> > seems we can't blame that one entirely on v6.4 kernel (or qemu).
> > 
> > We used to get (late 3.x and 4.x era) pretty common "NOHZ: local softirq
> > pending" messages even on common/popular distro kernels.  But I haven't
> > seen those for a long time and they didn't scream "error" or have the
> > alarmist three exclamation marks either.
> 
> FWIW, we're also seeing exactly that "NOHZ tick-stop error" message on
> 6.4.6-rt8 running on a couple of different imx8mp based boards.
> 
> Rasmus
>