Date: Thu, 18 Apr 2019 16:36:06 -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: <97662f2d206f404348a607cc7b2d5ff42936fb47.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 BTW, a spurious interrupt is not an unhandled interrupt. What it means is that some device signalled an interrupt, then by time the interrupt dispatching code runs, the interrupt controller says "there are no interrupts pending". That means that whatever condition signalled the interrupt went away by itself before software could see what it is, and that is sometimes a sign of trouble, but is usually harmless. Usually there are two things that can lead to a spurious interrupt: - A device driver writes to a device register to cause the condition signalling the interrupt to be cleared, then returns from the driver interrupt handler to the interrupt dispatcher code. The dispatcher does EOI processing which includes unmasking the interrupt at the interrupt controller. If the i2c device and the interrupt controller device are on separate busses that run at unequal speeds, it can happen that the write to unmask the interrupt arrives at the controller before the write to clear the interrupt-signalling condition at the i2c device. So, as soon as the interrupt is unmasked, a fresh IRQ is signalled to the arm processor. But before the arm gets around to dispatching it, the write finally arrives at the i2c hardware, clears the condition, and the interrupt goes away. Then we complain that the interrupt was spurious. - An interrupt is configured as shared, so it gets dispatched to multiple cores at once, and each of those cores asks the interrupt controller "what interrupts are pending right now?" One core gets a good answer "the i2c device" and the other core(s) get told "there is no pending interrupt" (because it just got delivered to some other core). So we complain that it was spurious. This situation is normal and expected and it's why we don't complain about spurious interrupts anymore in any multicore chip except RPi. We need to stop complaining on rpi as well. But it does seem a bit strange to me that you never saw them until 12.0, so I would like to understand the situation better before just removing the message. (Actually, it won't get removed, but it will be off by default with a tunable/sysctl to enable it.) -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97662f2d206f404348a607cc7b2d5ff42936fb47.camel>