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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 1676CC48BC2 for ; Mon, 21 Jun 2021 14:42:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F110C6115B for ; Mon, 21 Jun 2021 14:42:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230232AbhFUOok (ORCPT ); Mon, 21 Jun 2021 10:44:40 -0400 Received: from angie.orcam.me.uk ([78.133.224.34]:59768 "EHLO angie.orcam.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230076AbhFUOog (ORCPT ); Mon, 21 Jun 2021 10:44:36 -0400 Received: by angie.orcam.me.uk (Postfix, from userid 500) id 060F492009C; Mon, 21 Jun 2021 16:42:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id F28A192009B; Mon, 21 Jun 2021 16:42:19 +0200 (CEST) Date: Mon, 21 Jun 2021 16:42:19 +0200 (CEST) From: "Maciej W. Rozycki" To: Arnd Bergmann cc: Thomas Gleixner , Heiner Kallweit , Nikolai Zhubr , netdev , Jeff Garzik , the arch/x86 maintainers , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" Subject: Re: Realtek 8139 problem on 486. In-Reply-To: Message-ID: References: <60B24AC2.9050505@gmail.com> <60B2E0FF.4030705@gmail.com> <60B36A9A.4010806@gmail.com> <60B3CAF8.90902@gmail.com> <60B41D00.8050801@gmail.com> <60B514A0.1020701@gmail.com> <60B560A8.8000800@gmail.com> <49f40dd8-da68-f579-b359-7a7e229565e1@gmail.com> <60B611C6.2000801@gmail.com> <60B65BBB.2040507@gmail.com> <877dipgyrb.ffs@nanos.tec.linutronix.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, 21 Jun 2021, Arnd Bergmann wrote: > > A warning surely won't hurt, but TBH I'd just reprogram any incorrectly > > configured PCI interrupt line unconditionally where the ELCR is available. > > The chance someone uses a broken PCI card that drives its interrupt line > > as edge-triggered and is actually handled by a Linux driver both at a time > > is IMO nil. Such a card requires special provisions hardly any system > > provides and has anyone here seen a report of such a beast? > > I looked some more through the git history and found at least one time > that the per-chipset ELCR fixup came up for discussion[1], and this > appears to have resulted in generalizing an ALI specific fixup into > common code into common code[2], so we should already be doing > exactly this in many cases. If Nikolai can boot the system with debugging > enabled for arch/x86/pci/irq.c, we should be able to see exactly > which code path is his in his case, and why it doesn't go through > setting that register at the moment. > > I also found an slightly more recent discussion, from where it seems > that the authoritative decision when it came up in the past was that edge > triggered interrupts are supposed to work as long as they are not > shared [3][4]. Sadly Linus's rule applies both ways: if a device has been designed with level-triggered interrupts in mind, there may be no race-free way to ensure an active-to-inactive-to-active transition has happened on its IRQ line as the driver acknowledges handling in the relevant device's CSR. The rule of thumb is to acknowledge early in the handler, and to work around broken configurations it may be desirable to also briefly mask all the interrupt sources with the device so as to make sure it deasserts its IRQ line even if another interrupt has already been queued. OTOH if IRQ sharing is to be supported a device absolutely has to have an interrupt mask register, as the system cannot rely on masking at the interrupt controller if multiple devices are to be handled with a single line. I suspect many of our drivers do not do such precautionary masking though. Is there a mask register with the 8139? NB I find it amazing how people can break such relatively simple concepts, like not getting PCI IRQ steering right in early designs or messing up edge and level triggering. I mean wired interrupts are not rocket science. Sigh... Maciej