Date: Tue, 25 Apr 2017 21:59:36 -0700 From: Mark Millard <markmi@dsl-only.net> To: mmel@FreeBSD.org, freebsd-arm <freebsd-arm@freebsd.org>, freebsd-hackers@freebsd.org Cc: Tom Vijlbrief <tvijlbrief@gmail.com> Subject: Should sys/arm/arm/gic.h 's GIC_DEBUG_SPURIOUS be disabled? It would help Pine64+ 2GB and 1GB console use --and possibly other A64's Message-ID: <446204CA-0347-49FE-9EDC-24F4F273A0A3@dsl-only.net>
next in thread | raw e-mail | index | archive | help
This note is prompted by problems using the console
on Pine64+ 2GB 's when it is busy. (And 1GB 's as
reported by Tom V.) There are extensive messages
about spurious interrupts.
The following notes are written from the view of the
A64's documented gic-400.
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" turns out to be the 1023 value. I find no
evidence of any such generation of large irq's other than
automatic 1023's generated by the gic itself.
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 for a core. Other gics might not. (I've not
checked the gic status in an rpi3 but an rpi3 with the
same kernel does not generate the spurious interrupt
messages.)
The "next_irq:" code should get a 1023 when no more
interrupts are available for the core for an ARM64
and its gic --and it does.
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
the extra activity and its consequences).
This might help other A64's too.
The same sort of thing goes for stable/11's
sys/arm/arm/gic.c that still has the older
code structure but with GIC_DEBUG_SPURIOUS
defined and used to cause the messages.
The GIC_DEBUG_SPURIOUS goes back to gic.c
in head -r291424 from 2015-Nov 28 (UTC) via
mmel. While GIC_DEBUG_SPURIOUS moved to gic.h
it seem to have stayed enabled since it was
added.
Note: In my testing I temporarily made
variations of the messages that reported more. I
found nothing I could point to as suggesting an
error. It all seemed fine because of the 1023
status and the code's handling that that.
[Some --but far form all-- this activity is
visible in a different sequence of list
submittals. The above is the overall conclusion
of my investigation. The other messages clearly
show my learning-as-I-go status for this.]
=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?446204CA-0347-49FE-9EDC-24F4F273A0A3>