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)
@@ -672,9 +672,13 @@
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);
}
@@ -720,6 +724,16 @@
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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
