Date: Fri, 5 Sep 2014 17:44:34 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, ticso@cicely.de Subject: Re: Cubieboard: Spurious interrupt detected Message-ID: <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com> In-Reply-To: <1409958716.1150.321.camel@revolution.hippie.lan> References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 September 2014 16:11, Ian Lepore <ian@freebsd.org> wrote: > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: >> > And another problem: every now and then the kernel says something like that: >> > Sep 5 19:22:37 kernel: Spurious interrupt detected >> > Sep 5 19:22:37 kernel: Spurious interrupt detected >> > Sep 5 19:23:46 last message repeated 10 times >> > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the >> > problem here? >> >> Means something generates inetrrupts, which are not handled by a driver. >> Could be the cause for your load problem too. >> > > No, that would be stray interrupts. Spurious interrupts happen when an > interrupt is asserted, but by time the processor asks the interrupt > controller for the current active interrupt, it is no longer active. > > One way it can happen is when an interrupt handler writes to a device to > clear a pending interrupt and that write takes a long time to complete > because the device is on a slow bus, and the interrupt controller is on > a faster bus. The EOI to the controller outraces the device write that > would clear the pending interrupt condition, so the processor is > re-interrupted, but by time it asks for the next active interrupt the > device write has finally completed and the interrupt is no longer > pending. > > That sequence used to happen a lot, and it was "fixed" by adding an > l2cache sync (basically a "drain write buffer") just before an EOI. You > sometimes still see an occasional spurious interrupt, but it shouldn't > be happening multiple times per second as seen in the logging above. Hm, interesting. I remember your discussion about it on IRC. The atheros code ends up working around this in the driver by doing a read from the ISR after writing out bits to clear things, so the clear is flushed out. I wonder if we should be asking all device drivers to be doing their own ISR flushing before returning from their interrupt handlers. -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ>