Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753517AbdLMP6E (ORCPT ); Wed, 13 Dec 2017 10:58:04 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:35940 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753475AbdLMP57 (ORCPT ); Wed, 13 Dec 2017 10:57:59 -0500 Date: Wed, 13 Dec 2017 16:57:56 +0100 (CET) From: Thomas Gleixner To: Maarten Lankhorst cc: Michal Hocko , Linus Torvalds , "Rafael J. Wysocki" , Andy Lutomirski , Linux Kernel Mailing List , the arch/x86 maintainers , Daniel Vetter , Bjorn Helgaas , "Rafael J. Wysocki" Subject: Re: Linux 4.15-rc2: Regression in resume from ACPI S3 In-Reply-To: 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> 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: 1290 Lines: 46 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. Resume: [ 139.670446] ACPI: Low-level resume complete [ 139.670541] PM: Restoring platform NVS memory [ 139.672462] do_IRQ: 0.55 No irq handler for vector [ 139.672475] Enabling non-boot CPUs ... So the spurious interrupt happens early and way before the device resume code writes the new MSI message. I checked the behaviour on 4.14. The MSI write is delayed there in the same way, but there is no spurious interrupt. There is no interrupt coming in at all _BEFORE_ the device is put out of PCI_D0. And this has certainly nothing to do with the vector management changes, but I can't figure yet what makes that spurious interrupt to be sent. Any ideas welcome. Thanks, tglx