From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751303AbeAYUMb (ORCPT ); Thu, 25 Jan 2018 15:12:31 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:36030 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751108AbeAYUMa (ORCPT ); Thu, 25 Jan 2018 15:12:30 -0500 Date: Thu, 25 Jan 2018 21:12:13 +0100 (CET) From: Thomas Gleixner To: Lyude Paul cc: "Ghannam, Yazen" , "hpa@zytor.com" , "keith.busch@intel.com" , "mingo@kernel.org" , "linux-kernel@vger.kernel.org" , Borislav Petkov Subject: Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel In-Reply-To: <1516908343.5161.4.camel@redhat.com> Message-ID: References: <1516744873.29151.3.camel@redhat.com> <1516757219.29151.7.camel@redhat.com> <1516816150.4109.2.camel@redhat.com> <1516823810.4109.26.camel@redhat.com> <1516904638.5161.1.camel@redhat.com> <1516908343.5161.4.camel@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 25 Jan 2018, Lyude Paul wrote: > On Thu, 2018-01-25 at 19:46 +0100, Thomas Gleixner wrote: > > On Thu, 25 Jan 2018, Lyude Paul wrote: > > > > > I think you are right, apologies. Glad to know this isn't a regression in > > > the > > > IRQ handling code :). It looks like our nouveau problems are probably coming > > > from the fact that we don't just leave IRQs setup through suspend/resume > > > which > > > as far as I can tell, is probably not the correct thing to do. > > > > If you tear down the interrupt, then you have to make sure that it's > > completely masked and disabled on the device side (including MSI). > Does this only need to be done if we handle irq_request()/irq_free() ourselves, > or can we skip some of these steps if we let the kernel handle > disabling/enabling IRQs during s/r? If you do not free the interrupt on suspend, then the core does the right thing. Though you should not inflict an interrupt storm in that case either :) Thanks, tglx