Date: Fri, 21 Apr 2017 08:54:51 -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: <BCE3405A-4CDF-4317-A821-2DABFFE001CF@dsl-only.net> In-Reply-To: <CAOQrpVd%2BroHjoxhy6rqxy-OmQwcXm91=F=BLb6Gi1itMZ9Pfzw@mail.gmail.com> References: <CAOQrpVexBMEaMfRw%2BA0Km35dgYW7QcybRrKnkjOZmbrvX593=Q@mail.gmail.com> <28157698-A5E9-4194-9B5D-77D7B487ADFB@dsl-only.net> <CAOQrpVd%2BroHjoxhy6rqxy-OmQwcXm91=F=BLb6Gi1itMZ9Pfzw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Apr-21, at 2:21 AM, Tom Vijlbrief <tvijlbrief@gmail.com> wrote:
> Hi Mark,
>=20
> Thanks for your feedback!
>=20
> On boot I often find a single spurious interrupt 92 generated on my =
1GB Pine64+:
>=20
> root@pine64:~ # dmesg | grep pur
> gic0: Spurious interrupt detected: last irq: 92 on CPU0
>=20
> I used to get a lot of 1023's but the current kernel gives me:
I'll note that the messages do not print the current IRQ
value but just the prior/last one. (Possibly because 1023
was not useful once known.) It is the current IRQ number
that seems to always be 1023 in my testing.
> ic0: Spurious interrupt detected: last irq: 92 on CPU0
> root@pine64:~ # gic0: Spurious interrupt detected: last irq: 106 on =
CPU3
> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 27 on CPU3
> 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 CPU3
> gic0: gic0: Spurious interrupt detected: last irq: 27 on CPU2
> Spurious interrupt detected: last irq: 27 on CPU1
> gic0: Spurious interrupt detected: last irq: 106 on CPU3
> gic0: Spurious interrupt detected: last irq: 27 on CPU2
> gic0: Spurious interrupt detected: last irq: 27 on CPU1
>=20
> I want to upgrade my RPI first model (256Mb :-) which is my low power =
server to this Pine64 board,
> but this spurious interrupt issue holds me back.
>=20
>=20
>=20
> Op vr 21 apr. 2017 om 10:57 schreef Mark Millard =
<markmi@dsl-only.net>:
> [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. . .]
>=20
> On 2017-Apr-21, at 1:07 AM, Tom Vijlbrief <tvijlbrief@gmail.com> =
wrote:
>=20
> > I have a lot of spurious interrupts on my Pine64.
>=20
> 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.
>=20
> 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.)
>=20
> > Even in idle single user mode:
> >
> > # pstree
> > -+=3D 00001 root /sbin/init --
> > \-+=3D 01783 root -sh (sh)
> > \-+=3D 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.
>=20
> 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.
>=20
> If I re-enable the notices I should try -j3 vs. -j4
> and see how much of a difference it makes.
>=20
> 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.
>=20
> > I have ethernet connected and a small USB hard disk with it's own =
power supply, which hosts /usr/{src,obj,ports}.
>=20
> 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 .
>=20
> > In addition I noticed an ethernet lock up from time to time. =
Executing "dmesg" in a ssh session is often sufficient to trigger it.
>=20
> 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.
>=20
> One of the fixes to fork was avoiding interrupts
> corrupting a special register.
>=20
> > 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.
>=20
> 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.
>=20
> > Can others reproduce these findings?
>=20
> 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.
>=20
> > Thanks in advance for any hints.
>=20
> 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.)
>=20
> I've not figured out how to get any more useful
> information so far.
>=20
> 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?BCE3405A-4CDF-4317-A821-2DABFFE001CF>