head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023]

[Mark Millard]

On 2017-Apr-25, at 12:25 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Apr-24, at 10:03 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 
>> I found some basic reference material for the 
>> "last irq" numbers for the A64 that is in the
>> Pine64+ 2GB (and 1GB). . .
>> 
>> IRQ  27: PPI 11                   interrupt, vector 0x006C
>> (I've no clue about this one beyond it being a
>> "Private Peripheral Interrupt" example, somehow
>> specific to each core separately.)
> 
> Looks to be a timer, not that I can tell
> much about it:
> 
>        timer {
>                compatible = "arm,armv8-timer";
>                interrupts = <GIC_PPI 13
>                        (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>                             <GIC_PPI 14
>                        (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>                             <GIC_PPI 11
>                        (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>                             <GIC_PPI 10
>                        (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>        };
> 
> But looking around I've seen references to needing IRQ_TYPE_NONE
> if the register is read-only, avoiding writes to read-only
> registers, --with such timers as examples (not necessarily
> A64 specific material though).
> 
>> The rest of the IRQs are "Shared Peripheral
>> Interrupt"s. . .
>> 
>> IRQ  92: SD/MMC Host Controller 0 interrupt, vector 0x0170
>> 
>> IRQ 106: USB-EHCI0                interrupt, vector 0x01A8
>> 
>> 
>> There were some:
>> 
>> IRQ 114: EMAC                     interrupt, vector 0x01C8
>> IRQ  32: UART 0                   interrupt, vector 0x0080
>> 
>> And the first "last irq:" for each boot was
>> one of:
>> 
>> IRQ 107: USB-OHCIO                interrupt, vector 0x0A1C
>> IRQ  64: External Non-Mask        Interrupt, vector 0x0100
>> 
>> Neither 107 or 64 occurred again after the first
>> message for a boot. 64 showed up when no USB device
>> was plugged in; 107 showed when one was left plugged
>> in (plugged in before powering on the Pine64+ 2GB).
>> 
>> 1023 for the current irq number is special
>> and not specific to the A64.
>> 
>> 
>> So far I can not tell if the kernel mishandles the
>> A64 in some way that leads to 1023's vs. if this
>> is just what an A64 does for some odd reason, even
>> with fully-correct software.

When arm_gic_intr(.) jumps to "next_irq:" and finds that
there is no next interrupt that is indicated by
gic_c_read_4 of GICC_IAR returning 1023 according to
arm_gic_architecture_specification_v2.0.pdf .

So all the "nextirq:" messages that are in what I
reported are as-expected.

It is the messages that do not say "nextirq:" that are
in question, the ones were the first gic_c_read_4 for
GICC_IAR returns 1023 up front for some reason.

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