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=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 6AA42C63798 for ; Tue, 17 Nov 2020 21:00:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1198B241A5 for ; Tue, 17 Nov 2020 21:00:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="dHLYV9cs"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="CN7sn13d" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727426AbgKQU7g (ORCPT ); Tue, 17 Nov 2020 15:59:36 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:50702 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726571AbgKQU7f (ORCPT ); Tue, 17 Nov 2020 15:59:35 -0500 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1605646772; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z9/68O94wj/uDMlx/3jfQcpnTqyYonc5KOR75ihqBhE=; b=dHLYV9csZYO0Nlow8cBTxwXadbbE2IY0AR9mjiSCG4iby6PGCMVh3sNRK4tIsSRsRaLuAA 6dc7Jiq6lGYGqekwsNpS1OV2msONGxq2/W1690eaqhihmkmFZ1IoQOm/tSUP3OLUn//Isv GUrklLkisPstw42sfoPt38Z2a2hgvXSP9ofSMU7uvAzTnwbAuwsjlD+Cq+tRAcFuRDYNSr s4VmCjVzcPX9TjC37huDMuoWMmH6VeuRE3opii4p7Hhr+7GtHQrGvprbmMCGeW9XMkgE0c a5zuyp4awzPiWQXWB5UjPdDiVO6Xhp1EP1ep4rg3jS11/YNvx9Y+ZeXQsUpR0Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1605646772; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z9/68O94wj/uDMlx/3jfQcpnTqyYonc5KOR75ihqBhE=; b=CN7sn13d6TRk8DdzKSVcd1hW/7r6NMLcRt8RoLpimnvgT+6UsbFrvMMgkVsO8Y/vei8FUP L3ZQF9epGIy5gtBA== To: wi nk , Thomas Krause Cc: Kalle Valo , Govind Singh , linux-pci@vger.kernel.org, Stefani Seibold , linux-wireless@vger.kernel.org, Devin Bayer , Christoph Hellwig , Bjorn Helgaas , ath11k@lists.infradead.org, David Woodhouse Subject: Re: pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310 In-Reply-To: References: <20201103160838.GA246433@bjorn-Precision-5520> <874km61732.fsf@nanos.tec.linutronix.de> <87mtzxkus5.fsf@nanos.tec.linutronix.de> <87wnz0hr9k.fsf@codeaurora.org> <87ft5hehlb.fsf@codeaurora.org> <6b60c8f1-ec37-d601-92c2-97a485b73431@posteo.de> <87v9ec9rk3.fsf@codeaurora.org> <87imab4slq.fsf@codeaurora.org> <0b58872b4f27dbf5aad2a39f5ec4a066e080d806.camel@seibold.net> <875z6b3v22.fsf@codeaurora.org> <87pn4j2bna.fsf@codeaurora.org> Date: Tue, 17 Nov 2020 21:59:32 +0100 Message-ID: <87sg97wvgr.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Tue, Nov 17 2020 at 16:49, wi nk wrote: > On Sun, Nov 15, 2020 at 8:55 PM wi nk wrote: > So up until this point, everything is working without issues. > Everything seems to spiral out of control a couple of seconds later > when my system attempts to actually bring up the adapter. In most of > the crash states I will see this: > > [ 31.286725] wlp85s0: send auth to ec:08:6b:27:01:ea (try 1/3) > [ 31.390187] wlp85s0: send auth to ec:08:6b:27:01:ea (try 2/3) > [ 31.391928] wlp85s0: authenticated > [ 31.394196] wlp85s0: associate with ec:08:6b:27:01:ea (try 1/3) > [ 31.396513] wlp85s0: RX AssocResp from ec:08:6b:27:01:ea > (capab=0x411 status=0 aid=6) > [ 31.407730] wlp85s0: associated > [ 31.434354] IPv6: ADDRCONF(NETDEV_CHANGE): wlp85s0: link becomes ready > > And then either somewhere in that pile of messages, or a second or two > after this my machine will start to stutter as I mentioned before, and > then it either hangs, or I see this message (I'm truncating the > timestamp): > > [ 35.xxxx ] sched: RT throttling activated As this driver uses threaded interrupts, this looks like an interrupt storm and the interrupt thread consumes the CPU fully. The RT throttler limits the RT runtime of it which allows other tasks make some progress. That's what you observe as stutter. You can apply the hack below so the irq thread(s) run in the SCHED_OTHER class which prevents them from monopolizing the CPU. That might make the problem simpler to debug. Thanks, tglx --- diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index c460e0496006..8473ecacac7a 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1320,7 +1320,7 @@ setup_irq_thread(struct irqaction *new, unsigned int irq, bool secondary) if (IS_ERR(t)) return PTR_ERR(t); - sched_set_fifo(t); + //sched_set_fifo(t); /* * We keep the reference to the task struct even if From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from galois.linutronix.de ([193.142.43.55]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kf84e-0004zR-Vd for ath11k@lists.infradead.org; Tue, 17 Nov 2020 20:59:37 +0000 From: Thomas Gleixner Subject: Re: pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310 In-Reply-To: References: <20201103160838.GA246433@bjorn-Precision-5520> <874km61732.fsf@nanos.tec.linutronix.de> <87mtzxkus5.fsf@nanos.tec.linutronix.de> <87wnz0hr9k.fsf@codeaurora.org> <87ft5hehlb.fsf@codeaurora.org> <6b60c8f1-ec37-d601-92c2-97a485b73431@posteo.de> <87v9ec9rk3.fsf@codeaurora.org> <87imab4slq.fsf@codeaurora.org> <0b58872b4f27dbf5aad2a39f5ec4a066e080d806.camel@seibold.net> <875z6b3v22.fsf@codeaurora.org> <87pn4j2bna.fsf@codeaurora.org> Date: Tue, 17 Nov 2020 21:59:32 +0100 Message-ID: <87sg97wvgr.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath11k" Errors-To: ath11k-bounces+kvalo=adurom.com@lists.infradead.org To: wi nk , Thomas Krause Cc: Govind Singh , linux-pci@vger.kernel.org, Stefani Seibold , linux-wireless@vger.kernel.org, Devin Bayer , ath11k@lists.infradead.org, Bjorn Helgaas , David Woodhouse , Christoph Hellwig , Kalle Valo On Tue, Nov 17 2020 at 16:49, wi nk wrote: > On Sun, Nov 15, 2020 at 8:55 PM wi nk wrote: > So up until this point, everything is working without issues. > Everything seems to spiral out of control a couple of seconds later > when my system attempts to actually bring up the adapter. In most of > the crash states I will see this: > > [ 31.286725] wlp85s0: send auth to ec:08:6b:27:01:ea (try 1/3) > [ 31.390187] wlp85s0: send auth to ec:08:6b:27:01:ea (try 2/3) > [ 31.391928] wlp85s0: authenticated > [ 31.394196] wlp85s0: associate with ec:08:6b:27:01:ea (try 1/3) > [ 31.396513] wlp85s0: RX AssocResp from ec:08:6b:27:01:ea > (capab=0x411 status=0 aid=6) > [ 31.407730] wlp85s0: associated > [ 31.434354] IPv6: ADDRCONF(NETDEV_CHANGE): wlp85s0: link becomes ready > > And then either somewhere in that pile of messages, or a second or two > after this my machine will start to stutter as I mentioned before, and > then it either hangs, or I see this message (I'm truncating the > timestamp): > > [ 35.xxxx ] sched: RT throttling activated As this driver uses threaded interrupts, this looks like an interrupt storm and the interrupt thread consumes the CPU fully. The RT throttler limits the RT runtime of it which allows other tasks make some progress. That's what you observe as stutter. You can apply the hack below so the irq thread(s) run in the SCHED_OTHER class which prevents them from monopolizing the CPU. That might make the problem simpler to debug. Thanks, tglx --- diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index c460e0496006..8473ecacac7a 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1320,7 +1320,7 @@ setup_irq_thread(struct irqaction *new, unsigned int irq, bool secondary) if (IS_ERR(t)) return PTR_ERR(t); - sched_set_fifo(t); + //sched_set_fifo(t); /* * We keep the reference to the task struct even if -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k