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 C3F54C4724C for ; Fri, 8 May 2020 16:49:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A52DC21655 for ; Fri, 8 May 2020 16:49:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727071AbgEHQtZ (ORCPT ); Fri, 8 May 2020 12:49:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726750AbgEHQtY (ORCPT ); Fri, 8 May 2020 12:49:24 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E748C061A0C; Fri, 8 May 2020 09:49:24 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] 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 1jX6BX-0005gy-W0; Fri, 08 May 2020 18:49:16 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 4DCC9101175; Fri, 8 May 2020 18:49:15 +0200 (CEST) From: Thomas Gleixner To: "Raj\, Ashok" Cc: "Raj\, Ashok" , Evan Green , Mathias Nyman , x86@kernel.org, linux-pci , LKML , Bjorn Helgaas , "Ghorai\, Sukumar" , "Amara\, Madhusudanarao" , "Nandamuri\, Srikanth" , Ashok Raj Subject: Re: MSI interrupt for xhci still lost on 5.6-rc6 after cpu hotplug In-Reply-To: <20200508160958.GA19631@otc-nc-03> References: <20200508005528.GB61703@otc-nc-03> <87368almbm.fsf@nanos.tec.linutronix.de> <20200508160958.GA19631@otc-nc-03> Date: Fri, 08 May 2020 18:49:15 +0200 Message-ID: <87h7wqjrsk.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ashok, "Raj, Ashok" writes: > On Fri, May 08, 2020 at 01:04:29PM +0200, Thomas Gleixner wrote: >> TBH, I can't see anything what's wrong here from the kernel side and as >> this is new silicon and you're the only ones reporting this it seems >> that this is something which is specific to that particular >> hardware. Have you talked to the hardware people about this? >> > > After chasing it, I'm also trending to think that way. We had a question > about the moderation timer and how its affecting this behavior. > Mathias tried to turn off the moderation timer, and we are still able to > see this hang. We are reaching out to the HW folks to get a handle on this. > > With legacy MSI we can have these races and kernel is trying to do the > song and dance, but we see this happening even when IR is turned on. > Which is perplexing. I think when we have IR, once we do the change vector > and flush the interrupt entry cache, if there was an outstandng one in > flight it should be in IRR. Possibly should be clearned up by the > send_cleanup_vector() i suppose. Ouch. With IR this really should never happen and yes the old vector will catch one which was raised just before the migration disabled the IR entry. During the change nothing can go wrong because the entry is disabled and only reenabled after it's flushed which will send a pending one to the new vector. But if you see the issue with IR as well, then there is something wrong with the local APICs in that CPU. Thanks, tglx