Pine64 spurious interrupts

[Mark Millard]

[I had done the spurious-interrupt code change long enough ago
that having not had any notices of non-1023 for the current
irq that I'd forgotten which board I'd had the problem
with. It was the Pine64+ 2GB. So correcting my earlier
notes. . .]

On 2017-Apr-21, at 1:07 AM, Tom Vijlbrief <tvijlbrief at gmail.com> wrote:

> I have a lot of spurious interrupts on my Pine64.

I've seen this as well. I sent out notes on the
lists back on 2016-Nov-07 and 2017-Jan-28/31. It
is a Pine64+ 2GB. I later got access to a rpi3
as well but I run the same world and kernel build
on it and so do not know if it would generate the
messages. I'll have to try that at some point.

I'd seen a couple of the notices on armv7 (a bpim3)
before I'd made any changes to what I build. But
very rare. (I'd swapped the status in my head when
I wrote before.)

> Even in idle single user mode:
> 
> # pstree
> -+= 00001 root /sbin/init --
>  \-+= 01783 root -sh (sh)
>    \-+= 01804 root pstree
>      \--- 01805 root ps -axwwo user,pid,ppid,pgid,command
> # 
> 
> gic0: Spurious interrupt detected: last irq: 27 on CPU3
> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 27 on CPU2
> gic0: Spurious interrupt detected: last irq: 114 on CPU1
> gic0: Spurious interrupt detected: last irq: 27 on CPU3
> gic0: Spurious interrupt detected: last irq: 27 on CPU3
> gic0: Spurious interrupt detected: last irq: 114 on CPU1
> gic0: Spurious interrupt detected: last irq: 27 on CPU2
> gic0: Spurious interrupt detected: last irq: 27 on CPU2
> gic0: Spurious interrupt detected: last irq: 27 on CPU2
> gic0: gic0: Spurious interrupt detected: last irq: 27 on CPU3
> Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 114 on CPU1
> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> 
> When building world (3 threads) the frequency is about a few each second, idle perhaps a few each hour.

I got thousands in sort order during buildworld buildkernel
(-j4). Idle was normally rare for one to be generated but
it did happen on occasion.

If I re-enable the notices I should try -j3 vs. -j4
and see how much of a difference it makes.

The 1023 IRQ can be delivered because another core
has handled the original IRQ as I remember what I
quoted in the prior message. So keeping all cores
busy might generate more of these notices.

> I have ethernet connected and a small USB hard disk with it's own power supply, which hosts /usr/{src,obj,ports}.

Similarly here (but an SSD on a powered hub), with the
whole root file system on the SSD. Only booting through
the kernel stage comes from /dev/mmcsd0 .

> In addition I noticed an ethernet lock up from time to time. Executing "dmesg" in a ssh session is often sufficient to trigger it.

I used to get this but I've not seen it since the
recent fixes to fork behavior. May be it would happen
again if I re-enabled the gic0 messages for current
irq 1023, another potential experiment.

One of the fixes to fork was avoiding interrupts
corrupting a special register.

> The weird thing is that after some boots (perhaps 1 out of 10) the spurious interrupts do not happen! I have not been able to detect a pattern here.

I also had occasions when it would not happen after booting,
or at least for a significant time after booting, even if
I did a buildworld buildkernel. I did have examples where
it eventually started getting the messages again.

> Can others reproduce these findings?

I have in the past but I currently have things set up
to generate messages only when the current irq is not
1023 --which generates no such messages to speak of.

> Thanks in advance for any hints.

I only got as far as learning that the current IRQ
was (nearly?) always 1023. I really did not learn
any more. (I went after investigating fork issues
once I could use the console reasonably.)

I've not figured out how to get any more useful
information so far.

But the code change that I sent should get rid of the
notices. That in turn makes the console far more useful.
Other than that it just masks the problem, whatever the
problem is.

===
Mark Millard
markmi at dsl-only.net