Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?)

[Mark Millard]

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 = arg;
        struct gic_irqsrc *gi;
        uint32_t irq_active_reg, irq;
        struct trapframe *tf;

        irq_active_reg = gic_c_read_4(sc, GICC_IAR);
        irq = irq_active_reg & 0x3FF;
            
        /*
. . .
         */
 
        if (irq >= 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==1023 and sc->nirqs==224 in every message
that I've seen so far. 1023==0x3FF .

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):



	• 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.

. . .

	• 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:

		• 1022 for a Secure read when the highest priority interrupt is Non-secure

		• 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:

	• forwarding of interrupts by the Distributor to the CPU interface is disabled

	• signaling of interrupts by the CPU interface to the connected processor is disabled

	• no pending interrupt on the CPU interface has sufficient priority for the interface to signal it to the processor.


	• 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



===
Mark Millard
markmi at dsl-only.net