From owner-freebsd-hackers@freebsd.org Wed Apr 26 04:30:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 617BDD511A0 for ; Wed, 26 Apr 2017 04:30:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 252CB6C4 for ; Wed, 26 Apr 2017 04:30:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18887 invoked from network); 26 Apr 2017 04:33:32 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Apr 2017 04:33:32 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 26 Apr 2017 00:30:22 -0400 (EDT) Received: (qmail 23247 invoked from network); 26 Apr 2017 04:30:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Apr 2017 04:30:21 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1ACD8EC7B46; Tue, 25 Apr 2017 21:30:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: Date: Tue, 25 Apr 2017 21:30:20 -0700 Cc: Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: <23D019EB-DF40-45FD-A981-50CED7EC3ABA@dsl-only.net> References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 04:30:24 -0000 On 2017-Apr-25, at 2:51 PM, Mark Millard wrote: > On 2017-Apr-25, at 12:25 AM, Mark Millard = wrote: >=20 >> On 2017-Apr-24, at 10:03 PM, Mark Millard = 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_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (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