From owner-freebsd-current@freebsd.org Thu Apr 20 10:22:02 2017 Return-Path: Delivered-To: freebsd-current@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 7813DD48564 for ; Thu, 20 Apr 2017 10:22:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-188.reflexion.net [208.70.211.188]) (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 3CA75685 for ; Thu, 20 Apr 2017 10:22:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20015 invoked from network); 20 Apr 2017 10:25:05 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Apr 2017 10:25:05 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 20 Apr 2017 06:22:00 -0400 (EDT) Received: (qmail 18250 invoked from network); 20 Apr 2017 10:22:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Apr 2017 10:22:00 -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 6747AEC7901; Thu, 20 Apr 2017 03:21:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything] From: Mark Millard In-Reply-To: Date: Thu, 20 Apr 2017 03:13:04 -0700 Cc: ronald-lists@klop.ws, FreeBSD Current , freebsd-arm , sobomax@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <56DF611E-E797-4D48-ADA4-0CFED35F2B2E@dsl-only.net> References: <91A4570B-69EE-4462-9C60-205C66267599@dsl-only.net> <7AD329E1-2828-42EB-9A14-B44E357CC199@dsl-only.net> To: Tom Vijlbrief X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 10:22:02 -0000 On 2017-Apr-20, at 2:31 AM, Tom Vijlbrief = wrote: >> Op wo 19 apr. 2017 09:11 schreef Tom Vijlbrief : >> I'm currently rebuilding world and kernel on a just completed SVN = checkout. >>=20 >> Note that the normal sendmail daemon which listens for incoming = traffic does NOT loop. >>=20 >> The sendmail instance which tries local delivery (echo Hi | mail = root) or the msp_queue instance is looping. >>=20 >> It might be an arm64 specific issue, but a few weeks ago this was not = an issue. >>=20 > I just completed a full rebuild on the Pine64 and I cannot reproduce = the problem, so there is probably no issue anymore... >=20 > (Except the spurious interrupts issue) FYI: I've not seen a spurious interrupts notification on arm64/aarch64. I have seen such on cortex-a7 (the armv6/7 examples that I have access to are this: so just armv7). For cortex-a7 I build with the following local experiment for information gathering: # svnlite diff /usr/src/sys/arm/arm/gic.c Index: /usr/src/sys/arm/arm/gic.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/arm/gic.c (revision 317015) +++ /usr/src/sys/arm/arm/gic.c (working copy) @@ -672,9 +672,13 @@ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS +#define EXPECTED_SPURIOUS_IRQ 1023 + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { device_printf(sc->gic_dev, - "Spurious interrupt detected: last irq: %d on = CPU%d\n", + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n", + irq, sc->nirqs, sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); + } #endif return (FILTER_HANDLED); } @@ -720,6 +724,16 @@ if (irq < sc->nirqs) goto dispatch_irq; =20 + if (irq !=3D EXPECTED_SPURIOUS_IRQ) { +#undef EXPECTED_SPURIOUS_IRQ +#ifdef GIC_DEBUG_SPURIOUS + device_printf(sc->gic_dev, + "Spurious end interrupt %d detected of %d: last irq: = %d on CPU%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); +#endif + } + return (FILTER_HANDLED); } It has never reported a non-1023 IRQ. Quoting arm_gic_architecture_specification.pdf (various places about the = 1023 IRQ figure): =E2=80=A2 A processor reads the GICC_IAR and obtains the = interrupt ID 1023, indicating a spurious interrupt. The processor can = return from its interrupt service routine without writing to its = GICC_EOIR. The spurious interrupt ID indicates that the original interrupt is no = longer pending, typically because another target processor is handling = it. and . . . =E2=80=A2 1023 This value is returned to a processor, in = response to an interrupt acknowledge, if there is no pending interrupt = with sufficient priority for it to be signaled to the processor. and . . . GICC_IAR read = GICC_CTLR.AckCtl Returned interrupt ID Highest priority pending interrupt^a is Group 0 Non-secure x = Interrupt ID 1023 No pending interrupts^a x x = Interrupt ID 1023 Interrupt signaling of the required interrupt group by CPU interface = disabled x x = Interrupt ID 1023 ^a. Of sufficient priority to be signaled to the processor if signaling = by the CPU interface is enabled. =3D=3D=3D Mark Millard markmi at dsl-only.net