Date: Wed, 1 Feb 2017 19:07:33 -0800 From: Mark Millard <markmi@dsl-only.net> To: Tom Vijlbrief <tvijlbrief@gmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Message-ID: <F6C3286F-46DF-4819-BDD2-10904018E70C@dsl-only.net> In-Reply-To: <EB1D79C2-CF5E-4C21-BA1B-EC9F34BB737E@gmail.com> References: <CAOQrpVfK-Dw_rSo_YVY5MT1wbc6Ah-Pj%2BWv8UGjeiUQ1b3%2B-mg@mail.gmail.com> <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <CAOQrpVfxKvSR5PoahnqEsYspHhjjOGJ8iCBUetKxRV57oX_aUg@mail.gmail.com> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <CAOQrpVdKyP2T0V77sfpuKbNP3ARoD1EcwtH6E9o7p5KF%2B=A56A@mail.gmail.com> <CB36F13F-85E9-41D2-A7F3-DA183BE5985A@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> <EB1D79C2-CF5E-4C21-BA1B-EC9F34BB737E@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6C3286F-46DF-4819-BDD2-10904018E70C>