From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 00:44:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17A658CF; Sat, 6 Sep 2014 00:44:36 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC4EC17C6; Sat, 6 Sep 2014 00:44:35 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id j107so49511qga.18 for ; Fri, 05 Sep 2014 17:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UYXur3/Z+7bJFREjtmI5KF7Al6YN4KRO5P++8FdRIjQ=; b=XWLTMtBlLnKs6yhPT/Fi71WH4cJBAEtwwlxOlOZu8dOZEsXoo18X/B7qJ0HJbjBJPE 1BhwN3BRzRaXTpYuqVdKLLwy5nlV+U1iRtESmiMtU9slVKMg0oNOvTbNiEw5lwRMDlam qryeOAGz6uuJUtrzgibkQGsJ1Yxol0oxOke3kJs9c4aXWWG7g6xlL2Sz1PKsoHYLHr70 /Euh/LSsZviVqjr7facMstDjayBdKelip7hHWtXgEMdMUYZFyMGMNcXiL2rEkp/Q59ZN r1gRSNZ5mmm6UOFdu3yL8lxsHkPPfYqNYDa/C5Mh6rEKD74ukLCeVPfdeigUZa5tvV/v ovnA== MIME-Version: 1.0 X-Received: by 10.224.75.73 with SMTP id x9mr23859515qaj.63.1409964274978; Fri, 05 Sep 2014 17:44:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Fri, 5 Sep 2014 17:44:34 -0700 (PDT) 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> Date: Fri, 5 Sep 2014 17:44:34 -0700 X-Google-Sender-Auth: P1v5hWHYo9e5D2BMCAR43lbLdoo Message-ID: Subject: Re: Cubieboard: Spurious interrupt detected From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 00:44:36 -0000 On 5 September 2014 16:11, Ian Lepore 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