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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 185FCC43381 for ; Thu, 7 Mar 2019 20:22:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D2C5920851 for ; Thu, 7 Mar 2019 20:22:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726200AbfCGUWA (ORCPT ); Thu, 7 Mar 2019 15:22:00 -0500 Received: from emh02.mail.saunalahti.fi ([62.142.5.108]:46896 "EHLO emh02.mail.saunalahti.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726214AbfCGUWA (ORCPT ); Thu, 7 Mar 2019 15:22:00 -0500 Received: from darkstar.musicnaut.iki.fi (85-76-81-108-nat.elisa-mobile.fi [85.76.81.108]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id E358220090; Thu, 7 Mar 2019 22:21:56 +0200 (EET) Date: Thu, 7 Mar 2019 22:21:56 +0200 From: Aaro Koskinen To: Alexandre Oliva Cc: "Maciej W. Rozycki" , 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 Message-ID: <20190307202156.GB30189@darkstar.musicnaut.iki.fi> References: <20190208083038.GA1433@localhost.localdomain> <20190211125506.GA21280@localhost.localdomain> <20190211230614.GB22242@darkstar.musicnaut.iki.fi> <20190217235951.GA20700@darkstar.musicnaut.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org Hi, On Thu, Mar 07, 2019 at 03:41:01AM -0300, Alexandre Oliva wrote: > On Feb 17, 2019, "Maciej W. Rozycki" wrote: > > > Is there an MMIO completion barrier missing there somewhere by any chance > > causing an IRQ that has been handled already to be redelivered because an > > MMIO write meant to clear the IRQ at its origin at handler's completion > > has not reached its destination before interrupts have been reenabled in > > the issuing CPU? Just a thought. > > I've finally got a chance to bisect the IRQ14 (nobody cared) regression > on my yeeloong. It took me to MIPS: Enforce strong ordering for MMIO > accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f). This is interesting, thanks for the research, but I'm afraid it doesn't seem to be the root cause. While your patch seems to help also on Mini-PC (only briefly tested with a dozen of reboots), there's still excessive amount of interrupts during the boot - I'm getting something like 50000-70000, while with the old IDE driver it's around 2500. ~ # cat /proc/irq/14/spurious count 57805 unhandled 57799 last_unhandled 4294673092 ms ~ # cat /proc/interrupts CPU0 2: 0 XT-PIC 2 cascade 3: 174 XT-PIC 3 ttyS0 5: 14653 XT-PIC 5 timer 11: 0 XT-PIC 11 ehci_hcd:usb1, ohci_hcd:usb2 14: 57805 XT-PIC 14 pata_amd 15: 0 XT-PIC 15 pata_amd 18: 0 MIPS 2 cascade 22: 0 MIPS 6 cascade ERR: 0 Could you check your /proc/interrupts counters after the boot with your change? A.