Re: Sendmail eats CPU on r317039 [after -r316874 it may be -r316951 and -r316973 are not enough to fix everything]

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)

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
===================================================================
--- /usr/src/sys/arm/arm/gic.c	(revision 317015)
+++ /usr/src/sys/arm/arm/gic.c	(working copy)
_at__at_ -672,9 +672,13 _at__at_
 
 	if (irq >= sc->nirqs) {
 #ifdef GIC_DEBUG_SPURIOUS
+#define EXPECTED_SPURIOUS_IRQ 1023
+	    if (irq != 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);
 	}
_at__at_ -720,6 +724,16 _at__at_
 	if (irq < sc->nirqs)
 		goto dispatch_irq;
 
+	if (irq != 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):

	• 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