Date: Thu, 18 Apr 2019 16:57:47 -0600 From: Ian Lepore <ian@freebsd.org> To: Karl Denninger <karl@denninger.net>, freebsd-arm@freebsd.org Subject: Re: I2c producing crazy console messages [[Re: insanely-high interrupt rates -- PARTIAL resolution (Pi2)]] Message-ID: <ec6a5200c9c0b255094f6a46a1d2f95cd9334ea6.camel@freebsd.org> In-Reply-To: <6f6f8471-8624-c5e2-547c-42b712254126@denninger.net> References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <ac7d434f16f3a89f5ef247678d6becdbeded5c3f.camel@freebsd.org> <CE40E2B5-2244-4EF9-B67F-34A54D71E2E8@jeditekunum.com> <f60ea6d2-b696-d896-7bcb-ac628f41f7b8@denninger.net> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.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> <fc17ac0f77832e840b9fffa9b1074561f1e766d8.camel@freebsd.org> <d96c7f42-f01b-8990-a558-ee92d631b51d@denninger.net> <dc56a8964cae942354cbe2b5b0620f2eebb569bb.camel@freebsd.org> <874l7fyrpr.fsf@news-spur.riddles.org.uk> <701e011f-3088-8ed4-4fbb-6fa93ac698f5@denninger.net> <aefa1d778e7684f71ffed49ce32ee80e2273d033.camel@freebsd.org> <67133e19-2be5-ccd1-2ded-008b36a866ec@denninger.net> <6f6f8471-8624-c5e2-547c-42b712254126@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ec6a5200c9c0b255094f6a46a1d2f95cd9334ea6.camel>