From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9D37C31E48 for ; Wed, 12 Jun 2019 05:55:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B60E220874 for ; Wed, 12 Jun 2019 05:55:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730706AbfFLFzc (ORCPT ); Wed, 12 Jun 2019 01:55:32 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:60554 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725601AbfFLFzb (ORCPT ); Wed, 12 Jun 2019 01:55:31 -0400 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23990398AbfFLFz2EBmjF (ORCPT + 1 other); Wed, 12 Jun 2019 07:55:28 +0200 Date: Wed, 12 Jun 2019 06:55:28 +0100 (BST) From: "Maciej W. Rozycki" To: Aaro Koskinen cc: Alexandre Oliva , Tom Li , James Hogan , Jiaxun Yang , Huacai Chen , Ralf Baechle , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers In-Reply-To: <20190610214938.GB7147@darkstar.musicnaut.iki.fi> Message-ID: References: <20190211230614.GB22242@darkstar.musicnaut.iki.fi> <20190217235951.GA20700@darkstar.musicnaut.iki.fi> <20190610214938.GB7147@darkstar.musicnaut.iki.fi> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 11 Jun 2019, Aaro Koskinen wrote: > However, with your patch the "nobody cared" is never reached so all is > good. I tried 10 boots with the patch and all were successful. Without > the patch 8 out of 10 failed with the "nobody cared" warning. I wouldn't call it "good", just less obvious or painful. This is still causing wasted CPU cycles that are used for taking the phantom interrupts. There is clearly a completion barrier missing somewhere that causes the interrupt request to linger beyond the point interrupts are reenabled at the CPU. One way to attempt to narrow it down might be taking a backtrace from where IRQ 14 is found to be spurious. This would indicate the offending interrupt unmask action. E.g. I see no explicit completion barrier between the final `outb' in `mask_and_ack_8259A' and the following call to `raw_spin_unlock_irqrestore', which are obviously otherwise unordered WRT each other (because `outb' is I/O or MMIO and `raw_spin_unlock_irqrestore' is contained within the CPU on UP). I can see provisions however for issuing an architecture-specific barrier in `do_raw_spin_unlock', which is the workhorse for `raw_spin_unlock_irqrestore', so maybe this is the place to look into? Also how's IRQ 14 registered as indicated by /proc/interrupts? Maciej