From owner-freebsd-arm@freebsd.org Fri Apr 21 15:54:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 011FED494A8 for ; Fri, 21 Apr 2017 15:54:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-20.reflexion.net [208.70.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B02A0803 for ; Fri, 21 Apr 2017 15:54:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 706 invoked from network); 21 Apr 2017 15:54:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Apr 2017 15:54:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 21 Apr 2017 11:54:53 -0400 (EDT) Received: (qmail 17990 invoked from network); 21 Apr 2017 15:54:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Apr 2017 15:54:52 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 44393EC8F25; Fri, 21 Apr 2017 08:54:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Pine64 spurious interrupts From: Mark Millard In-Reply-To: Date: Fri, 21 Apr 2017 08:54:51 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <28157698-A5E9-4194-9B5D-77D7B487ADFB@dsl-only.net> To: Tom Vijlbrief X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:54:55 -0000 On 2017-Apr-21, at 2:21 AM, Tom Vijlbrief 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 = : > [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 = 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