Date: Tue, 25 Apr 2017 21:30:20 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-arm <freebsd-arm@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] Message-ID: <23D019EB-DF40-45FD-A981-50CED7EC3ABA@dsl-only.net> In-Reply-To: <E606AD72-A222-4552-B616-C3734998F452@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> <E606AD72-A222-4552-B616-C3734998F452@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Apr-25, at 2:51 PM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2017-Apr-25, at 12:25 AM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>> On 2017-Apr-24, at 10:03 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>>=20
>>> I found some basic reference material for the=20
>>> "last irq" numbers for the A64 that is in the
>>> Pine64+ 2GB (and 1GB). . .
>>>=20
>>> 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.)
>>=20
>> Looks to be a timer, not that I can tell
>> much about it:
>>=20
>> timer {
>> compatible =3D "arm,armv8-timer";
>> interrupts =3D <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)>;
>> };
>>=20
>> 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).
_HIGH is an incorrect description for A64's gic.
Allwinner_A64_User_Manual_V1.0.pdf explicitly says, quoting:
3.12. GIC
For details about GIC, please refer to the GIC PL400 technical reference
manual and ARM GIC Architecture Specification V2.0.
DDI0471B_gic400_r0p1_trm.pdf is explicit about the
actual type of signal, quoting:
2.3.2 PPIs
A PPI is an interrupt that is specific to a single processor.
All PPI signals are active-LOW level-sensitive.
arm_gic_architecture_specification_v2.0.pdf is not as specific.
DDI0471B_gic400_r0p1_trm.pdf does describe what irq 27 (so
PPI 11) is specifically. It also mentions that GICD) ICFGRn's
even bits (Int_config[0]'s) are implemented but are always
read-only, provided only for legacy software.
But when I looked around more it looked like there was explicit
code structure that ignored various details and forced other
settings so that the _HIGH status was actually not used.
>>> The rest of the IRQs are "Shared Peripheral
>>> Interrupt"s. . .
>>>=20
>>> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170
>>>=20
>>> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8
>>>=20
>>>=20
>>> There were some:
>>>=20
>>> IRQ 114: EMAC interrupt, vector 0x01C8
>>> IRQ 32: UART 0 interrupt, vector 0x0080
>>>=20
>>> And the first "last irq:" for each boot was
>>> one of:
>>>=20
>>> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C
>>> IRQ 64: External Non-Mask Interrupt, vector 0x0100
>>>=20
>>> 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).
>>>=20
>>> 1023 for the current irq number is special
>>> and not specific to the A64.
>>>=20
>>>=20
>>> 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.
>=20
> 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 .
>=20
> So all the "nextirq:" messages that are in what I
> reported are as-expected.
>=20
> 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.
All my testing has only found the A64's gic architecture's
1023 irq as the irq for everything the code classifies as
spurious, everything that is "too large to be one of the
used irq's". I find no evidence of any such generation
other than automatic 1023's from the gic.
arm_gic_intr handles the 1023's appropriately from what I
read. No 1023 should be a problem.
I've not found anything saying that the 1023's should not
be generated by the gic, it appears optional for various
ones being generated that are seen in the first read of
GICC_IAR. Other gics might not. (I've not checked the
gic status in an rpi3 but an rpi3 with the same kernel
does not generate these 1023's seen on Pine64+ 2GB and 1GB
boxes --and possibly other A64 boxes.)
It appears that something like:
# svnlite diff /usr/src/sys/arm/arm/gic.h =
=
Index: =
/usr/src/sys/arm/arm/gic.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /usr/src/sys/arm/arm/gic.h (revision 317015)
+++ /usr/src/sys/arm/arm/gic.h (working copy)
@@ -39,7 +39,7 @@
#ifndef _ARM_GIC_H_
#define _ARM_GIC_H_
=20
-#define GIC_DEBUG_SPURIOUS
+//#define GIC_DEBUG_SPURIOUS
=20
#define GIC_FIRST_SGI 0 /* Irqs 0-15 are =
SGIs/IPIs. */
#define GIC_LAST_SGI 15
would be more appropriate for at least the
Pine64+ 2GB and 1GB so that the debug messages
do not mess up use of the console (and
cause extra activity and its consequences).
This might help other A64's too.
The GIC_DEBUG_SPURIOUS goes back to gic.c
in head -r291424 from 2015-Nov 28 (UTC). While
it moved to gic.h it seem to have stayed enabled
since it was added.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23D019EB-DF40-45FD-A981-50CED7EC3ABA>