From owner-freebsd-arm@freebsd.org Fri Apr 21 08:57:57 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 13256D3B3DE for ; Fri, 21 Apr 2017 08:57:57 +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 CCE6C1D6A for ; Fri, 21 Apr 2017 08:57:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8700 invoked from network); 21 Apr 2017 08:58:59 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Apr 2017 08:58:59 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 21 Apr 2017 04:57:54 -0400 (EDT) Received: (qmail 3421 invoked from network); 21 Apr 2017 08:57:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Apr 2017 08:57:54 -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 CF605EC86E7; Fri, 21 Apr 2017 01:57:53 -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 01:57:53 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <28157698-A5E9-4194-9B5D-77D7B487ADFB@dsl-only.net> References: 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 08:57:57 -0000 [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 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