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=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 34829C282C4 for ; Thu, 7 Feb 2019 15:18:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0377520821 for ; Thu, 7 Feb 2019 15:18:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549552732; bh=DuxHL/F+BBHP9/xiWbJSfhTZBZBCyV/N4Tupn173Tcs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=bf++qTObSi8S5KvhHbrvZ4vT/PnR1n3EtwlSyqUgCxOdhrHbYjCRpguffMnCvTdzy t9JVluUS5E5PfOGvb9yLF9CWqWR8WzTisjd6ObRefVGKYKf2TsaolYMZHxRIH+XbCf Kjq0BDsuk3yi84BAYaCnG40B7u17xDdTpQPIJ0A0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726484AbfBGPSu (ORCPT ); Thu, 7 Feb 2019 10:18:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:49652 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726196AbfBGPSs (ORCPT ); Thu, 7 Feb 2019 10:18:48 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8CB9F20821; Thu, 7 Feb 2019 15:18:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549552728; bh=DuxHL/F+BBHP9/xiWbJSfhTZBZBCyV/N4Tupn173Tcs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cwBX+Y+ra7H+kFrwgCBMueD4peQMkndyEzQ64tfsRFyL5dAUYYgWLe6PCXZAURqlg b/mQIGu6juXLueiEy+b3BScwhyh/xmx5LDPIWwsdg5tXGjuBO6V2WuklMZnhut8WyS SBJGiXGSHx0sUuX7SgnwjaVkoDzcilKNopKlQ4GM= Date: Thu, 7 Feb 2019 16:18:45 +0100 From: "gregkh@linuxfoundation.org" To: "Derrick, Jonathan" Cc: "Kalakota, SushmaX" , "scott.bauer@intel.com" , "Busch, Keith" , "stable@vger.kernel.org" , "bhelgaas@google.com" Subject: Re: [PATCH] PCI: vmd: Free up IRQs on suspend path Message-ID: <20190207151845.GA11823@kroah.com> References: <20190206213616.15136-1-sushmax.kalakota@intel.com> <20190207110752.GA16944@kroah.com> <1549552167.19557.3.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1549552167.19557.3.camel@intel.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Feb 07, 2019 at 03:10:09PM +0000, Derrick, Jonathan wrote: > On Thu, 2019-02-07 at 12:07 +0100, Greg KH wrote: > > On Wed, Feb 06, 2019 at 02:36:16PM -0700, Sushma Kalakota wrote: > > > commit e2b1820bd5d09 upstream > > > > > > Free up the IRQs we request on the suspend path and reallocate them > > > on the > > > resume path. > > > > > > Fixes this error: > > > > > > CPU 111 disable failed: CPU has 9 vectors assigned and there are > > > only 0 available. > > > Error taking CPU111 down: -34 > > > Non-boot CPUs are not disabled > > > Enabling non-boot CPUs ... > > > > > > For consistency, this patch also includes the VMD portion of: > > > 3eefa790c9681: PCI: host: Mark PCIe/PCI (MSI) cascade ISR as > > > IRQF_NO_THREAD > > > > > > CC: Scott Bauer > > > CC: Bjorn Helgaas > > > CC: Keith Busch > > > Reviewed-by: Jon Derrick > > > Signed-off-by: Sushma Kalakota > > > --- > > > drivers/pci/host/vmd.c | 18 +++++++++++++++++- > > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > > > > What stable kernel tree(s) do you want this patch applied to? And > > why? > > > > thanks, > > > > greg k-h > > Hi Greg, > > This is for 4.9.y and intended to increase reliability of > suspend/resume not leading to a failure to suspend or failure to > resume, either of which would be undesireable to users of the feature, > and potentially make the overall feature unusable if suspend/resume > were user requirement. Ok, but who is still using this old kernel on these types of machines? Why haven't they moved to 4.14 or newer by now? The normal systems that use 4.9 or older should not need this, as they are the horrid SoC trees. Who has reported this problem in their systems? thanks, greg k-h