Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751641AbeAPKdN (ORCPT + 1 other); Tue, 16 Jan 2018 05:33:13 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:42414 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751214AbeAPKdL (ORCPT ); Tue, 16 Jan 2018 05:33:11 -0500 Date: Tue, 16 Jan 2018 11:33:10 +0100 (CET) From: Thomas Gleixner To: Keith Busch cc: LKML Subject: Re: [BUG 4.15-rc7] IRQ matrix management errors In-Reply-To: <20180116071145.GA5643@localhost.localdomain> Message-ID: References: <20180115025759.GG13580@localhost.localdomain> <20180115030255.GA13921@localhost.localdomain> <20180116061641.GB32639@localhost.localdomain> <20180116071145.GA5643@localhost.localdomain> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, 16 Jan 2018, Keith Busch wrote: > This is all way over my head, but the part that obviously shows > something's gone wrong: > > kworker/u674:3-1421 [028] d... 335.307051: irq_matrix_reserve_managed: bit=56 cpu=0 online=1 avl=86 alloc=116 managed=3 online_maps=112 global_avl=22084, global_rsvd=157, total_alloc=570 > kworker/u674:3-1421 [028] d... 335.307053: irq_matrix_remove_managed: bit=56 cpu=0 online=1 avl=87 alloc=116 managed=2 online_maps=112 global_avl=22085, global_rsvd=157, total_alloc=570 > kworker/u674:3-1421 [028] .... 335.307054: vector_reserve_managed: irq=45 ret=-28 > kworker/u674:3-1421 [028] .... 335.307054: vector_setup: irq=45 is_legacy=0 ret=-28 > kworker/u674:3-1421 [028] d... 335.307055: vector_teardown: irq=45 is_managed=1 has_reserved=0 > > Which leads me to x86_vector_alloc_irqs goto error: > > error: > x86_vector_free_irqs(domain, virq, i + 1); > > The last parameter looks weird. It's the nr_irqs, and since we failed and > bailed, I would think we'd need to subtract 1 rather than add 1. Adding > 1 would doublely remove the failed one, and remove the next one that > was never setup, right? Right. That's fishy. Let me stare at it. > Or maybe irq_matrix_reserve_managed wasn't expected to fail in the > first place? Well, it can faul. I don't know why it fails in that case, but let me look a bit more. Thanks, tglx