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.8 required=3.0 tests=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 83C82C2D0DB for ; Thu, 23 Jan 2020 13:09:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6061C24655 for ; Thu, 23 Jan 2020 13:09:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726605AbgAWNJF convert rfc822-to-8bit (ORCPT ); Thu, 23 Jan 2020 08:09:05 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:39975 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726170AbgAWNJF (ORCPT ); Thu, 23 Jan 2020 08:09:05 -0500 Received: from [5.158.153.53] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iucEA-00006a-Ow; Thu, 23 Jan 2020 14:08:54 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 692DD1017FA; Thu, 23 Jan 2020 14:08:54 +0100 (CET) From: Thomas Gleixner To: sean.v.kelley@linux.intel.com, Kar Hin Ong , Bjorn Helgaas Cc: linux-rt-users , LKML , "x86\@kernel.org" , "linux-pci\@vger.kernel.org" , "H. Peter Anvin" , Dave Hansen , Julia Cartwright , Keng Soon Cheah , Gratian Crisan , Peter Zijlstra Subject: Re: RE: Re: "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system In-Reply-To: <8f1e5981b519acb5edf53b5392c81ef7cbf6a3eb.camel@linux.intel.com> References: <20191031230532.GA170712@google.com> <87a76oxqv1.fsf@nanos.tec.linutronix.de> <87muanwwhb.fsf@nanos.tec.linutronix.de> <8f1e5981b519acb5edf53b5392c81ef7cbf6a3eb.camel@linux.intel.com> Date: Thu, 23 Jan 2020 14:08:54 +0100 Message-ID: <87muaetj4p.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-rt-users-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rt-users@vger.kernel.org Sean, Sean V Kelley writes: > I looked into it Thomas. The issue is as you suggested early in the > thread. If an IRQ arrives at line N of a non-primary IO-APIC and that > line is masked, a new IRQ is generated on the primary IO-APIC/PIC. > > The BIOS setting to address this forwarding is as above Disable INTx > Route to PCH/ICH/SouthBridge. When this bit is set, local INTx messages > received from the PCI-E ports are not routed to legacy PCH - they are > either converted into MSI via the integrated I/OxAPIC (if the I/OxAPIC > mask bit is clear in the appropriate entries) or cause no further > action (when mask bit is set). > > This capability is tested and supported fully on Intel platforms. Thanks for the confirmation. > Once you get to SKX/CLX things change and integrated IOxAPICs in the > IIO module convert legacy PCI Express interrupt messages into MSI > interrupts directly. Beyond SKX/CLX there are no longer IOxAPICs in > IIO. IOxAPIC is only in the PCH. Devices connected to the > IIO will use native MSI/MSI-x mechanisms. > > The problem is with the absolute lack of useful documentation. That’s > not acceptable. Yeah. > You recall the work Olaf and Stefan did at SuSE ten years ago (?) on > boot irq quirks and the amount of research they had to do it learn > about the behavior.[4] Oh yes. > From a Real-Time Linux perspective this is really important to me. As > we get closer to fully mainlined we need to have this information > readily available with greater usage of threaded irqs in combination > with legacy interrupts on the older platforms. > > So I will ensure we actually create useful information pointing to this > behavior either in kernel docs or online as in a white paper or both. Great. >> As we have already quirks in drivers/pci/quirks.c which handle the >> same issue on older chipsets, we really should add one for these kind >> of systems to avoid fiddling with the BIOS (which you can, but most >> people cannot). > Agreed, and I will follow-up with Kar Hin Ong to get them added. Much appreciated. Thanks, tglx