Date: Fri, 21 Apr 2017 09:21:23 +0000 From: Tom Vijlbrief <tvijlbrief@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Pine64 spurious interrupts Message-ID: <CAOQrpVd%2BroHjoxhy6rqxy-OmQwcXm91=F=BLb6Gi1itMZ9Pfzw@mail.gmail.com> In-Reply-To: <28157698-A5E9-4194-9B5D-77D7B487ADFB@dsl-only.net> References: <CAOQrpVexBMEaMfRw%2BA0Km35dgYW7QcybRrKnkjOZmbrvX593=Q@mail.gmail.com> <28157698-A5E9-4194-9B5D-77D7B487ADFB@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark,
Thanks for your feedback!
On boot I often find a single spurious interrupt 92 generated on my 1GB
Pine64+:
root@pine64:~ # dmesg | grep pur
gic0: Spurious interrupt detected: last irq: 92 on CPU0
I used to get a lot of 1023's but the current kernel gives me:
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
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.
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. . .]
>
> 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:
> >
> > # 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
>
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOQrpVd%2BroHjoxhy6rqxy-OmQwcXm91=F=BLb6Gi1itMZ9Pfzw>