Date: Tue, 25 Apr 2017 14:51:35 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-arm <freebsd-arm@freebsd.org>, freebsd-hackers@freebsd.org Cc: Tom Vijlbrief <tvijlbrief@gmail.com> Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] Message-ID: <E606AD72-A222-4552-B616-C3734998F452@dsl-only.net> In-Reply-To: <C6B9A15F-D8C7-46F6-B59A-DBCB70BE3C44@dsl-only.net> References: <B4FDA80F-1E72-4A2B-BE0C-E6F7BE6CDC5F@dsl-only.net> <D128A050-9688-4BDB-9D16-50DFEF15D6A5@dsl-only.net> <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> <C6B9A15F-D8C7-46F6-B59A-DBCB70BE3C44@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E606AD72-A222-4552-B616-C3734998F452>