On 2017-Apr-20, at 2:31 AM, Tom Vijlbrief <tvijlbrief at gmail.com> wrote:

>> Op wo 19 apr. 2017 09:11 schreef Tom Vijlbrief <tvijlbrief at gmail.com>:
>> I'm currently rebuilding world and kernel on a just completed SVN checkout.
>> Note that the normal sendmail daemon which listens for incoming traffic does 
>> NOT loop.
>> The sendmail instance which tries local delivery (echo Hi | mail root) or 
>> the msp_queue instance is looping.
>> It might be an arm64 specific issue, but a few weeks ago this was not an 
>> issue.
> I just completed a full rebuild on the Pine64 and I cannot reproduce the 
> problem, so there is probably no issue anymore...
> (Except the spurious interrupts issue)


I've not seen a spurious interrupts notification on

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
--- /usr/src/sys/arm/arm/gic.c  (revision 317015)
+++ /usr/src/sys/arm/arm/gic.c  (working copy)
@@ -672,9 +672,13 @@
        if (irq >= sc->nirqs) {
+           if (irq != EXPECTED_SPURIOUS_IRQ) {
-                   "Spurious interrupt detected: last irq: %d on CPU%d\n",
+                   "Spurious interrupt %d detected of %d: last irq: %d on 
+                   irq, sc->nirqs,
                    sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid));
+            }
                return (FILTER_HANDLED);
@@ -720,6 +724,16 @@
        if (irq < sc->nirqs)
                goto dispatch_irq;
+       if (irq != EXPECTED_SPURIOUS_IRQ) {
+               device_printf(sc->gic_dev,
+                   "Spurious end interrupt %d detected of %d: last irq: %d on 
+                   irq, sc->nirqs,
+                   sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid));
+       }
        return (FILTER_HANDLED);

It has never reported a non-1023 IRQ.

Quoting arm_gic_architecture_specification.pdf (various places about the 1023 
IRQ figure):

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

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

Mark Millard
markmi at dsl-only.net

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to