From owner-freebsd-hackers@freebsd.org Tue Apr 25 21:58:18 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 461CFD50DD7 for ; Tue, 25 Apr 2017 21:58:18 +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 E842E12B2 for ; Tue, 25 Apr 2017 21:58:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10309 invoked from network); 25 Apr 2017 21:51:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 21:51:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 17:51:36 -0400 (EDT) Received: (qmail 5846 invoked from network); 25 Apr 2017 21:51:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 21:51:36 -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 E1AAFEC8714; Tue, 25 Apr 2017 14:51:35 -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 14:51:35 -0700 Cc: Tom Vijlbrief Content-Transfer-Encoding: 7bit Message-Id: 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: Tue, 25 Apr 2017 21:58:18 -0000 On 2017-Apr-25, at 12:25 AM, Mark Millard wrote: > On 2017-Apr-24, at 10:03 PM, Mark Millard 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_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)>; > }; > > 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