Date: Fri, 21 Apr 2017 01:57:53 -0700 From: Mark Millard <markmi@dsl-only.net> To: Tom Vijlbrief <tvijlbrief@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Pine64 spurious interrupts Message-ID: <28157698-A5E9-4194-9B5D-77D7B487ADFB@dsl-only.net> In-Reply-To: <CAOQrpVexBMEaMfRw%2BA0Km35dgYW7QcybRrKnkjOZmbrvX593=Q@mail.gmail.com> References: <CAOQrpVexBMEaMfRw%2BA0Km35dgYW7QcybRrKnkjOZmbrvX593=Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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@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:
>=20
> # pstree
> -+=3D 00001 root /sbin/init --
> \-+=3D 01783 root -sh (sh)
> \-+=3D 01804 root pstree
> \--- 01805 root ps -axwwo user,pid,ppid,pgid,command
> #=20
>=20
> 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
>=20
> 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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28157698-A5E9-4194-9B5D-77D7B487ADFB>