From owner-freebsd-arm@freebsd.org Thu Feb 2 03:07:41 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 CEA54CCC8AE for ; Thu, 2 Feb 2017 03:07:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (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 8E4EAD22 for ; Thu, 2 Feb 2017 03:07:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4135 invoked from network); 2 Feb 2017 03:07:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Feb 2017 03:07:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 01 Feb 2017 22:07:34 -0500 (EST) Received: (qmail 11496 invoked from network); 2 Feb 2017 03:07:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Feb 2017 03:07:34 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id C9E95EC909E; Wed, 1 Feb 2017 19:07:33 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Wed, 1 Feb 2017 19:07:33 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) 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: Thu, 02 Feb 2017 03:07:41 -0000 I temporarily modified the Spurious-interrupt-detected notice to also = report irq and sc->nirqs : . . . #define gic_c_read_4(_sc, _reg) \ bus_space_read_4((_sc)->gic_c_bst, (_sc)->gic_c_bsh, (_reg)) . . . int arm_gic_intr(void *arg) { struct arm_gic_softc *sc =3D arg; struct gic_irqsrc *gi; uint32_t irq_active_reg, irq; struct trapframe *tf; irq_active_reg =3D gic_c_read_4(sc, GICC_IAR); irq =3D irq_active_reg & 0x3FF; =20 /* . . . */ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS device_printf(sc->gic_dev, "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); } . . . The result was irq=3D=3D1023 and sc->nirqs=3D=3D224 in every message that I've seen so far. 1023=3D=3D0x3FF . Looking around I found in: = http://www.cl.cam.ac.uk/research/srg/han/ACS-P35/zynq/arm_gic_architecture= _specification.pdf the following on various reasons why 1023 would show up (quoting): =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. . . . The GIC architecture reserves interrupt ID numbers 1020-1023 for special = purposes. In a GICv1 implementation that does not implement the GIC = Security Extensions, the only one of these used is ID 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. It is described as a response to a spurious = interrupt. Note A race condition can cause a spurious interrupt. For example, a spurious = interrupt can occur if a processor writes a 1 to a field in an = GICD_ICENABLERn that corresponds to a pending interrupt after the CPU = interface has signaled the interrupt to the processor and the processor = has recognized the interrupt, but before the processor has read from the = GICC_IAR. . . . =E2=80=A2 If a read of the GICC_IAR does not match the security = of the interrupt, the GICC_IAR read does not acknowledge any interrupt = and returns the value: =E2=80=A2 1022 for a Secure read when the highest = priority interrupt is Non-secure =E2=80=A2 1023 for a Non-secure read when the highest = priority interrupt is Secure. . . . A read of the GICC_IAR returns the interrupt ID of the highest priority = pending interrupt for the CPU interface. The read returns a spurious = interrupt ID of 1023 if any of the following apply: =E2=80=A2 forwarding of interrupts by the Distributor to the CPU = interface is disabled =E2=80=A2 signaling of interrupts by the CPU interface to the = connected processor is disabled =E2=80=A2 no pending interrupt on the CPU interface has = sufficient priority for the interface to signal it to the processor. =E2=80=A2 The following sequence of events is an example of when = the GIC returns an interrupt ID of 1023, and shows how reads of the = GICC_IAR can be timing critical: 1. A peripheral asserts a level-sensitive interrupt. 2. The interrupt has sufficient priority and therefore the GIC signals = it to a targeted processor. 3. The peripheral deasserts the interrupt. Because there is no other = pending interrupt of sufficient priority, the GIC deasserts the = interrupt request to the processor. 4. Before it has recognized the deassertion of the interrupt request = from stage 3, the targeted processor reads the GICC_IAR. Because there = is no interrupt with sufficient priority to signal to the processor, the = GIC returns the spurious ID value of 1023. The determination of the returned interrupt ID is more complex if the = GIC supports interrupt grouping . . . Interrupt signaling of the required interrupt group by CPU interface = disabled =3D=3D=3D Mark Millard markmi at dsl-only.net