From owner-freebsd-arm@freebsd.org Fri Apr 19 15:28:10 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D53F156F9DC for ; Fri, 19 Apr 2019 15:28:10 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 D39EC83965 for ; Fri, 19 Apr 2019 15:28:08 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1555686718; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=YTo5x2IDV06wJiKQabehp/tkC3pLY4PGXxpn+SLrIrTB5hdqh2sgamCQyvB+V0juGyy43mmSCJBNN QcOloP8GEsBP/u8lZj0NPwHkMru7Ti/nlthIKhRGdohtUIhldDoZBPW7+28xyJjnGIYzm/thlW7UDU UcPb2u/4MdC0r3JT0nqKjIBl4j7YgNrneo48SNIgFX6p2PgI9REj/ApeDCvJDpwT71Hc03Q5gzd2d+ JShz7viSyLfECggVQJdS+EdukzZU4Zdyyma1abAfqSakmvWoIuj0h8WTW8oChx+5hjApcgW2gmXO6E Z2meZKFuz7yxFpn5J4U1yfO2HEFtG1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=+KqWUP2wno65VKit5VPNGZrab7xjZg7PTfGyKl5KXYw=; b=YkPkWKKLX/H7aBWdwi6O3/Wz4OOD/fsVR3alsQX8+dO10dCEvtHLLDi/dmI+re/wGUu+iSxKFeqPl a0uG1yHZQ5+td3CqGqyiFK80ZiDdmUERsbE/FzCnwe2JkK8LD+Slqqsfr1q3D9Agp3MZdAVSAbrt5s KmEW3TyyeHeHPGGSOC6iAZos1rOTeeb3ST51X58jvD5F4wVAXBSOIxoNVOHZATOtevdM8cMVPH/C5i quJiZ5MNHqHsE49mYBUn+Mu8krcxXDbv7TEqY8UbJDUJ+ReUswyQq9dnpMLeoptM+u5lkSBClACMo0 8eYl8WoHFjwAqfjzClkBLSQNFvBcqSQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.155.78; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=+KqWUP2wno65VKit5VPNGZrab7xjZg7PTfGyKl5KXYw=; b=khKOuzbB55ofv8XQEjyCdhkK1t9qAKmje9xM1BYItFKIOS4hinbBGXuyLI+C20t4I4TcHDcXrC6U8 N7XV5Jvo7IEzk0EwFCpSrgi7N1oXFMwoZN6vChiB8JaetEdv1LAQukRoZerj6uKZvKMwPR7s5zglKj unfLqjXJzZjGP6dos+t7F3Jbro/6ZGNKuV0KovlSOwGkkX5ymaaH8OL6AHpkGwN3kP7I69EK7wWZN+ pLHCHk+muN5gG+YJ3SeTHNKVfEpZMK15DvAgmaZ5PYnUm/AjkEgKkgrS/MK5iSxAwlcV9N4ZmsMgMD H8o928gNGRc+4FhCHiOxvlqlRrJt+5w== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 76a9f554-62b5-11e9-919f-112c64a8cf29 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.155.78 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.155.78]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 76a9f554-62b5-11e9-919f-112c64a8cf29; Fri, 19 Apr 2019 15:11:56 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x3JFBqf6077930 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Apr 2019 17:11:52 +0200 (CEST) (envelope-from per@hedeland.org) Subject: Re: I2c producing crazy console messages [[Re: insanely-high interrupt rates -- PARTIAL resolution (Pi2)]] To: Karl Denninger Cc: Ian Lepore , freebsd-arm@freebsd.org References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> <874l7fyrpr.fsf@news-spur.riddles.org.uk> <701e011f-3088-8ed4-4fbb-6fa93ac698f5@denninger.net> <67133e19-2be5-ccd1-2ded-008b36a866ec@denninger.net> <6f6f8471-8624-c5e2-547c-42b712254126@denninger.net> <8bcdb1e1-e561-6255-848d-e532ad4d5918@denninger.net> <499b53d5-23ed-c33b-3715-018720c536a3@hedeland.org> From: Per Hedeland Message-ID: <46baf0cd-ce31-9641-4a99-689db9aecc75@hedeland.org> Date: Fri, 19 Apr 2019 17:11:52 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D39EC83965 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=khKOuzbB X-Spamd-Result: default: False [-5.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; MX_GOOD(-0.01)[cached: hedeland.org]; NEURAL_HAM_SHORT(-0.96)[-0.956,0]; RECEIVED_SPAMHAUS_PBL(0.00)[78.155.228.81.zen.spamhaus.org : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; ARC_ALLOW(-1.00)[i=1]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-1.23)[ipnet: 54.148.0.0/15(-4.79), asn: 16509(-1.31), country: US(-0.06)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[64.219.148.54.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 15:28:10 -0000 On 2019-04-19 16:16, Karl Denninger wrote: > On 4/19/2019 06:32, Per Hedeland wrote: >> On 2019-04-19 03:25, Karl Denninger wrote: >>> >>> On 4/18/2019 17:57, Ian Lepore wrote: >>>> On Thu, 2019-04-18 at 16:51 -0500, Karl Denninger wrote: >>>>> Up until 12.0 this code both worked and did *not* generate complaints >>>>> about unhandled interrupts. It still runs fine and returns valid >>>>> data >>>>> BUT if there are any analog endpoints actually on the bus that the >>>>> code >>>>> can read then it generates a lot of these: >>>>> >>>>> local_intc0: Spurious interrupt detected >>>>> local_intc0: Spurious interrupt detected >>>>> intc0: Spurious interrupt detected >>>>> >>>>> ..... >>>>> >>>>> If I do not connect the I2c device then there are no messages. If I >>>>> stop the code that is running (e.g. no accesses to the i2c bus) then >>>>> the >>>>> messages stop as well, so it's not something that happens but remains >>>>> active after the code halts; it's happening on the actual accesses to >>>>> the bus from those ioctl's. >>>> Hmm, another interesting question occurred to me: Can you tell whether >>>> you are getting multiple spurious interrupt messages per single >>>> transfer your code does, or is it one per transfer, or more >>>> intermittent, like not on every transfer? >>>> >>>> -- Ian >>> >>> It logs the message on "many" accesses, but not all. >>> >>> The code scans each of the declared analogs once per second. There are >>> two inputs defined on this unit right now, so if it was on every access >>> there would be two messages per second logged, and there isn't; nor is >>> it "one per cluster" of accesses. I removed the reset and restarted the >>> code and this is the frequency of log entries I'm getting, which implies >>> frequent and random, but much less than 1:1. >>> >>> Apr 18 20:22:25 Pool-MCP kernel: intc0: Spurious interrupt detected >>> Apr 18 20:22:26 Pool-MCP kernel: local_intc0: Spurious interrupt detected >>> Apr 18 20:22:27 Pool-MCP kernel: intc0: Spurious interrupt detected >>> Apr 18 20:22:33 Pool-MCP kernel: local_intc0: Spurious interrupt detected >>> Apr 18 20:22:36 Pool-MCP kernel: intc0: Spurious interrupt detected >>> Apr 18 20:22:38 Pool-MCP kernel: local_intc0: Spurious interrupt detected >>> Apr 18 20:22:39 Pool-MCP kernel: intc0: Spurious interrupt detected >>> Apr 18 20:22:40 Pool-MCP syslogd: last message repeated 1 times >>> Apr 18 20:22:40 Pool-MCP kernel: local_intc0: Spurious interrupt detected >>> Apr 18 20:22:42 Pool-MCP kernel: intc0: Spurious interrupt detected >>> Apr 18 20:22:49 Pool-MCP kernel: local_intc0: Spurious interrupt detected >>> Apr 18 20:22:52 Pool-MCP kernel: intc0: Spurious interrupt detected >>> Apr 18 20:22:53 Pool-MCP kernel: local_intc0: Spurious interrupt detected >> >> Hm, I've recently gotten an i2c device to work on RPi - FWIW it's an >> ads1015 AD-converter, my code is pretty similar to yours - you may >> actually be using the same device - and I don't see *any* "Spurious >> interrupt" messages when using it. But a) I've only run it on RPi Zero >> (currently connected) and RPi 1B (briefly when testing), and b) I >> don't have a console connected (but I assume the messages should also >> show up in dmesg and /var/log/messages, the above seems to be from the >> log). >> >> But anyway I would be *extremely* surprised if I saw them, since AFAIU >> the i2c bus per se has no concept of interrupts - you need to connect >> some other wire from the device to e.g. a gpio pin (with appropriate >> config) in order to generate interrupts - and I haven't done that. (The >> ads1015 does have an ALERT/RDY pin that could potentially be used for >> it, but since FreeBSD AFAIK doesn't have a way to deliver the >> interrupts to userland code, I had no interest in it.) > > Correct. Indeed these are ADS1015s -- the code also supports ads1115s. The delay for conversion is different, thus the multiplier (you set a different constant in the config file) plus, of course, > the shift required for 12-bit alignment into a 16-bit result. > >> >> So, your code like mine doesn't seem to use interrupts at all - do you >> nevertheless have some interrupt-generating connection from the >> device? > > No. Thus the delay for conversion via usleep within my code since there's no way for a device on the I2c bus itself (at least as far as I know) to alert that the conversion is complete. While > theoretically I could use the Alert/RDY pin I do not at present. > > The spurious interrupt message is coming from sys/arm/broadcom/bcm2835/bcm2835_intr.c -- which is, of course, not present in a RPI3 build since that's aarch64 (the "arm64" branch of the sys tree) and > not arm. OK, but... - the interrupts "have to" be generated by some "electrical change" *somewhere* - if you haven't connected anything else, that would seem to leave only the actual SDA/SCL lines of the i2c bus itself. Which would be "crazy", and everyone using any i2c device would see them - at least on the RPi 2... > But the below is indeed interesting.... > >> And if these interrupts really happen only on RPi 2 and not on >> any of 0/1/3, I guess it makes sense to look at the dts/dtb files. >> Diffing bcm2708-rpi-0-w.dts and bcm2709-rpi-2-b.dts, I see this: >> >> interrupt-controller@7e00b200 { >> >> - compatible = "brcm,bcm2835-armctrl-ic"; >> + compatible = "brcm,bcm2836-armctrl-ic"; >> reg = <0x7e00b200 0x200>; >> interrupt-controller; >> #interrupt-cells = <0x2>; >> + interrupt-parent = <0x3>; >> + interrupts = <0x8>; >> phandle = <0x1>; >> }; >> >> and this: >> >> + local_intc@40000000 { >> + >> + compatible = "brcm,bcm2836-l1-intc"; >> + reg = <0x40000000 0x100>; >> + interrupt-controller; >> + #interrupt-cells = <0x1>; >> + interrupt-parent = <0x3>; >> + phandle = <0x3>; >> + }; >> >> I have (as yet) no idea what it actually means, but it clearly seems >> to be interrupt-related... There are a few more "interrupt-related" >> diffs, but those two kind of "stand out" for me. Btw, shouldn't these >> .dts files exist somewhere under /usr/src/sys/gnu/dts/arm? I >> decompiled them from the .dtb's in installed images to be able to >> compare... >> >> --Per Hedeland > > The "newer build environment" has both rpi-firmware and u-boot running off packages/ports, which are nominally in /usr/local/share; in this case /usr/local/share/rpi-firmware. The dtb files are > there, but not the source dts files. FreeBSD picks up the binary dtb files; it does not compile the .dts files at build time. Thanks, all clear now! --Per > root@NewFS:/usr/local/share/rpi-firmware # ls -al > total 9427 > drwxr-xr-x 3 root wheel 26 Feb 10 12:08 . > drwxr-xr-x 112 root wheel 113 Mar 4 11:31 .. > -rw-r--r-- 1 root wheel 18693 Nov 12 10:05 COPYING.linux > -rw-r--r-- 1 root wheel 1494 Nov 12 10:05 LICENCE.broadcom > -rw-r--r-- 1 root wheel 5888 Feb 8 11:55 armstub8.bin > -rw-r--r-- 1 root wheel 23315 Nov 12 10:05 bcm2708-rpi-0-w.dtb > -rw-r--r-- 1 root wheel 23071 Nov 12 10:05 bcm2708-rpi-b-plus.dtb > -rw-r--r-- 1 root wheel 22812 Nov 12 10:05 bcm2708-rpi-b.dtb > -rw-r--r-- 1 root wheel 22589 Nov 12 10:05 bcm2708-rpi-cm.dtb > -rw-r--r-- 1 root wheel 24115 Nov 12 10:05 bcm2709-rpi-2-b.dtb > -rw-r--r-- 1 root wheel 25574 Nov 12 10:05 bcm2710-rpi-3-b-plus.dtb > -rw-r--r-- 1 root wheel 25311 Nov 12 10:05 bcm2710-rpi-3-b.dtb > -rw-r--r-- 1 root wheel 24087 Nov 12 10:05 bcm2710-rpi-cm3.dtb > -rw-r--r-- 1 root wheel 52116 Nov 12 10:05 bootcode.bin > -rw-r--r-- 1 root wheel 89 Feb 8 11:55 config.txt > -rw-r--r-- 1 root wheel 151 Feb 8 11:55 config_rpi3.txt > -rw-r--r-- 1 root wheel 114 Feb 8 11:55 config_rpi_0_w.txt > -rw-r--r-- 1 root wheel 6666 Nov 12 10:05 fixup.dat > -rw-r--r-- 1 root wheel 2621 Nov 12 10:05 fixup_cd.dat > -rw-r--r-- 1 root wheel 9895 Nov 12 10:05 fixup_db.dat > -rw-r--r-- 1 root wheel 9895 Nov 12 10:05 fixup_x.dat > drwxr-xr-x 2 root wheel 151 Feb 10 12:08 overlays > -rw-r--r-- 1 root wheel 2857060 Nov 12 10:05 start.elf > -rw-r--r-- 1 root wheel 678532 Nov 12 10:05 start_cd.elf > -rw-r--r-- 1 root wheel 5120484 Nov 12 10:05 start_db.elf > -rw-r--r-- 1 root wheel 4057956 Nov 12 10:05 start_x.elf > > root@NewFS:/usr/local/share/rpi-firmware # pkg info |grep rpi > rpi-firmware-1.20181112 Firmware for RaspberryPi Single Board Computer > u-boot-rpi2-2019.01 Cross-build das u-boot for model rpi2 > u-boot-rpi3-2019.01 Cross-build das u-boot for model rpi3 > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/