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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 BBF6DC4743C for ; Mon, 21 Jun 2021 15:23:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A407B6023C for ; Mon, 21 Jun 2021 15:23:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230161AbhFUPZf (ORCPT ); Mon, 21 Jun 2021 11:25:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:53520 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230057AbhFUPZc (ORCPT ); Mon, 21 Jun 2021 11:25:32 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 734AF61156 for ; Mon, 21 Jun 2021 15:23:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624288998; bh=gNra/Ej0I36Z6E74Xnlm3clEIoHXIvp7+bs2+vb9THQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FAGcJIVBz1mnnkI4ocaYDxirI97rkrcOqnrtlosQUslBdRK8Z98R2+qOoCpL/Wga+ g6Gmjd/Tv/jIYSSTOb59NujP9vGVmbBlqVTalbw7U1Y9KjoD/y5P2srTN8G8Eba4nY K96KH5jMH9s/34Kbie8UH7Y1wLffP35Tbl8hRDYRT0qRXBQJuDjltMLKmSpNRgzlbK WmEMbaiJIVI0QNFdcueYciJ8cIzmW30fQD78ExppxzMJuMfmzSJ7+fNxFhH9WrswOw 7a205UUwqDeZJyRhfMxchfqgjZoTwaQeFWT0Mb+o6LQ0tbQiBowXTBXSTSSb879Zle Y7CmpItBC4k6g== Received: by mail-wr1-f52.google.com with SMTP id j2so9588880wrs.12 for ; Mon, 21 Jun 2021 08:23:18 -0700 (PDT) X-Gm-Message-State: AOAM533h73gq8y04Qr4PdwRuQ/5aTOUMvPDkwd9A3r0j7CLdEJ8hNIhX cJZw0uV1yHUVwVrrwJPFSNU0KdZ9lAwsApR7UfA= X-Google-Smtp-Source: ABdhPJxf8ZM5gM6lm4UWwfoj4dKdSh8BZZSyWdhxabY73npVuYOcffQnxg000SQDEBB4qnL0k7wjnVsLfJXNiNiyxgg= X-Received: by 2002:a5d:5905:: with SMTP id v5mr4053551wrd.361.1624288996976; Mon, 21 Jun 2021 08:23:16 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Arnd Bergmann Date: Mon, 21 Jun 2021 17:20:59 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Realtek 8139 problem on 486. To: "Maciej W. Rozycki" Cc: Thomas Gleixner , Heiner Kallweit , Nikolai Zhubr , netdev , Jeff Garzik , "the arch/x86 maintainers" , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Jun 21, 2021 at 4:42 PM Maciej W. Rozycki wrote: > > On Mon, 21 Jun 2021, Arnd Bergmann wrote: > > > 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? Ah, it seems that the Cc list got dropped in a different sub-thread, see https://pastebin.com/3FUUrg7C for a version of my patch that Nikolai tested successfully. This one goes further by completely masking all interrupts between the hardirq handler and the subsequent napi_complete_done(). This may not be the most efficient way of doing it, but it seems good enough according to his measurements, and it is a relatively safe and straightforward change. Arnd