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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 41615C33CB6 for ; Thu, 23 Jan 2020 00:20:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 114AB24125 for ; Thu, 23 Jan 2020 00:20:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ebiH8eRb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726234AbgAWAUi (ORCPT ); Wed, 22 Jan 2020 19:20:38 -0500 Received: from mail-io1-f53.google.com ([209.85.166.53]:34615 "EHLO mail-io1-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725911AbgAWAUi (ORCPT ); Wed, 22 Jan 2020 19:20:38 -0500 Received: by mail-io1-f53.google.com with SMTP id z193so1236288iof.1; Wed, 22 Jan 2020 16:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q9OnONyP09Moztbo+Zld7RNuaGBt8c5OJNarX5zYoeg=; b=ebiH8eRbwZ28AjEsFCJJHr853iDHjGjVrGPQyBE+C4kSWhZrMTY5qTGrRqyzRfItMx WPUv6BCv8YQlYO8fI6mtFTrKMkHm5dH8tmhsaLJn2Dsfgdn9VdpHw3WqJB5x2uLI1Ow/ 4JvQRh8i5kL1AGZsWgYRWDPnQKGrIYrIedltSH9sdxsd1H94yiHG3B19WpRJsWq3R/tv vMlJR719RY9L0utBNAET+N7qQ0LZW6waGyWuwlRVcd2ydvM9EejpcfYZP3I7sEAX0ev8 KqI3xXugFinIHlHp1IYH26IwUsnDjKSrgwPCktCIy0jWP5Z8sbNqAXpDySh8586rWEMe rvhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q9OnONyP09Moztbo+Zld7RNuaGBt8c5OJNarX5zYoeg=; b=sabfhGZ/qqUBndHAw4uC3/XfE9RdNkClC63TNgkpqwWqnqQqjKpqjej/d2hkf6h9Jh raVoMMAzssXjd8+ItwtIKW51iBaCNIntBvltTmAi3krCiGEWPRmvMHbee6vNyWGs32Df tAEXJhml0y2paoYErlcfA2aMmaTS8A8Bnkkti797AUILKxZ9i046OEXOEzvvenURG/OA cf9Az5XPSbZ27fHM+5ZaJtAG7Ekl+BKhlIcsDvG4vcJ2tH2a15p6fKObTF1qBMeFq9Gu YY+OGEU4io5G1qJyIWJh82jLzuBtsRa6ax19ppK48NnrL7w9L2SumM+dwp18MqSoDefD WEOg== X-Gm-Message-State: APjAAAU70U7qjEMlvD9I2oULd/shef87O0g7wJQzPZRZe1/oith67OY0 wTwOsewifEyj0njoMLyq6eC1t8Fy2RrjfyfZSSY= X-Google-Smtp-Source: APXvYqynSFq+/hmW/yTpgk43hU/Ydwm6maWK274YlWABDs1iN5tMK4oeZExEFYIXJtVONfNIp6dUTYx+YnluZQxC4D4= X-Received: by 2002:a5e:d515:: with SMTP id e21mr4706750iom.100.1579738837257; Wed, 22 Jan 2020 16:20:37 -0800 (PST) MIME-Version: 1.0 References: <20190217235951.GA20700@darkstar.musicnaut.iki.fi> <20190610214938.GB7147@darkstar.musicnaut.iki.fi> <20190612192412.GF26504@darkstar.musicnaut.iki.fi> In-Reply-To: <20190612192412.GF26504@darkstar.musicnaut.iki.fi> From: Matt Turner Date: Wed, 22 Jan 2020 16:20:26 -0800 Message-ID: Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers To: Aaro Koskinen Cc: "Maciej W. Rozycki" , Alexandre Oliva , Tom Li , James Hogan , Jiaxun Yang , Huacai Chen , Ralf Baechle , linux-mips@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 12, 2019 at 12:25 PM Aaro Koskinen wrote: > > Hi, > > On Wed, Jun 12, 2019 at 06:55:28AM +0100, Maciej W. Rozycki wrote: > > 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 > > The first spurious IRQ is right after the driver registers: > > [ 4.732000] [] show_stack+0x90/0x140 > [ 4.732000] [] ata_bmdma_interrupt+0x2b4/0x39c > [ 4.732000] [] __handle_irq_event_percpu+0xb0/0x178 > [ 4.732000] [] handle_irq_event_percpu+0x34/0x9c > [ 4.732000] [] handle_irq_event+0x3c/0x74 > [ 4.732000] [] handle_level_irq+0x118/0x154 > [ 4.732000] [] generic_handle_irq+0x34/0x50 > [ 4.732000] [] do_IRQ+0x18/0x24 > [ 4.732000] [] handle_int+0x17c/0x188 > [ 4.732000] [] arch_local_irq_restore+0x18/0x30 > [ 4.732000] [] __setup_irq+0x660/0x7a0 > [ 4.732000] [] request_threaded_irq+0x114/0x19c > [ 4.732000] [] devm_request_threaded_irq+0xa0/0x10c > [ 4.732000] [] ata_pci_sff_activate_host+0x1c0/0x274 > [ 4.732000] [] ata_pci_init_one+0x170/0x1c4 > [ 4.732000] [] cs5536_init_one+0x94/0xb8 > > and the following ones do not seem to provide much info as I can only > see the IRQ stack: > > [ 4.736000] [] show_stack+0x90/0x140 > [ 4.736000] [] ata_bmdma_interrupt+0x2b4/0x39c > [ 4.736000] [] __handle_irq_event_percpu+0xb0/0x178 > [ 4.736000] [] handle_irq_event_percpu+0x34/0x9c > [ 4.736000] [] handle_irq_event+0x3c/0x74 > [ 4.736000] [] handle_level_irq+0x118/0x154 > [ 4.736000] [] generic_handle_irq+0x34/0x50 > [ 4.736000] [] do_IRQ+0x18/0x24 > [ 4.736000] [] handle_int+0x17c/0x188 > [ 4.736000] [] irq_exit+0x68/0xcc > > > 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? > > Not sure what you mean but here's the output: > > $ cat /proc/interrupts > CPU0 > 2: 0 XT-PIC 2 cascade > 3: 20 XT-PIC 3 ttyS0 > 5: 543358 XT-PIC 5 timer > 11: 0 XT-PIC 11 ehci_hcd:usb1, ohci_hcd:usb2 > 14: 100000 XT-PIC 14 pata_cs5536 > 18: 0 MIPS 2 cascade > 22: 0 MIPS 6 cascade > 36: 3052 bonito_irq eth0 > ERR: 0 > > A. Has any more progress been made? Thanks, Matt