Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753606AbdLMQmL (ORCPT ); Wed, 13 Dec 2017 11:42:11 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:36015 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753336AbdLMQmH (ORCPT ); Wed, 13 Dec 2017 11:42:07 -0500 Date: Wed, 13 Dec 2017 17:41:55 +0100 (CET) From: Thomas Gleixner To: Bjorn Helgaas cc: Maarten Lankhorst , Michal Hocko , Linus Torvalds , "Rafael J. Wysocki" , Andy Lutomirski , Linux Kernel Mailing List , the arch/x86 maintainers , Daniel Vetter , Bjorn Helgaas , "Rafael J. Wysocki" , linux-pci@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: Linux 4.15-rc2: Regression in resume from ACPI S3 In-Reply-To: <20171213162336.GG53955@bhelgaas-glaptop.roam.corp.google.com> Message-ID: References: <168050887.sZlTFXWCmO@aspire.rjw.lan> <20171206121452.GA6320@dhcp22.suse.cz> <0f1d3d63-fa10-5cef-8014-81753dc60243@mblankhorst.nl> <57c8679e-1b88-c9ad-2299-2bea7560b28f@mblankhorst.nl> <20171213162336.GG53955@bhelgaas-glaptop.roam.corp.google.com> 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 Content-Length: 1462 Lines: 44 On Wed, 13 Dec 2017, Bjorn Helgaas wrote: > [+cc linux-pci, linux-pm] > > On Wed, Dec 13, 2017 at 04:57:56PM +0100, Thomas Gleixner wrote: > > So I was finally able to figure out what the hell is going on: > > > > Suspend: > > > > - The device suspend code puts the graphics card into a power > > state != PCI_D0. > > > > - Offline non boot CPUs > > > > - Break interrupt affinity. Allocate new vector on CPU 0, compose and > > write MSI message which ends up in: > > > > __pci_write_msi_msg(entry, msg) > > { > > if (dev->current_state != PCI_D0 || pci_dev_is_disconnected(dev)) { > > /* Don't touch the hardware now */ > > } else { > > .... > > } > > entry->msg = *msg; > > } > > > > So because the device is not in PCI_D0 the message is not written. It's > > written in the device resume path. > > I'm not a PM guru, but this ordering seems fragile. If we offline > CPUs before re-targeting interrupts directed at those CPUs, aren't we > always going to be at risk of sending interrupts to an offline CPU? > > Even if the device is now asleep and therefore should not generate an > interrupt, it seems like there's a window when the device returns to > PCI_D0 where it could generate an interrupt before we have a chance to > update the MSI message. Definitely. That was fragile forever but puzzles me is that I can't figure out what now causes that spurious interrupt to surface out of the blue. Thanks, tglx