Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754577AbdLOAes (ORCPT ); Thu, 14 Dec 2017 19:34:48 -0500 Received: from mail-ot0-f177.google.com ([74.125.82.177]:33976 "EHLO mail-ot0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754431AbdLOAeo (ORCPT ); Thu, 14 Dec 2017 19:34:44 -0500 X-Google-Smtp-Source: ACJfBotIF9qXD6EH5Bs++DjaFWH+GTbDgFXki1mvKL+Jug4Ga9Sqknwx4iBzZOUxd7Uwn2DGCByYeYpuyyl8m4XeNaQ= MIME-Version: 1.0 In-Reply-To: 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> From: "Rafael J. Wysocki" Date: Fri, 15 Dec 2017 01:34:42 +0100 X-Google-Sender-Auth: AUK9aiWVU475w_-cnNbSIV6XiwM Message-ID: Subject: Re: Linux 4.15-rc2: Regression in resume from ACPI S3 To: Thomas Gleixner Cc: Linus Torvalds , Bjorn Helgaas , Maarten Lankhorst , Michal Hocko , "Rafael J. Wysocki" , Andy Lutomirski , Linux Kernel Mailing List , "the arch/x86 maintainers" , Daniel Vetter , Bjorn Helgaas , "Rafael J. Wysocki" , Linux PCI , Linux PM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1776 Lines: 40 On Thu, Dec 14, 2017 at 11:36 PM, Thomas Gleixner wrote: > On Thu, 14 Dec 2017, Linus Torvalds wrote: >> On Thu, Dec 14, 2017 at 3:54 AM, Thomas Gleixner wrote: >> I just wanted to pipe up about that "irq7", because judging from your >> email it seems like you think it's a real irq: >> >> > Now there is a race >> > whether the kernel resume path manages to mask the PIC again early enough >> > before something triggers IRQ7 or not. >> >> ..and that's not how the PIC works. >> >> In fact, "legacy irq 7" is the _normal_ and very traditional spurious >> interrupt, and it's documented. If the PIC gets an interrupt from >> _any_ source, but the interrupt goes away before the PIC gets an >> acknowledge from the CPU (and by "acknowledge", I'm not talking about >> the explicit software IRQ ACK, I'm talking about the hardware >> protocol, between the PIC and the CPU), the PIC will then report irq 7 >> as the interrupt - regardless of what the original was. >> >> The reason is almost always something like >> >> - CPU interrupts are disabled or masked >> >> - driver does a write to the external hardware that causes an >> interrupt to be raised > > Which should be a non issue because _ALL_ PIC irq lines are masked at the > PIC itself. All interrupts are routed through IOAPIC. So unless the IOAPIC > sports similar behaviour the PIC should not ever observe that scenario. > > But, because the silly firmware comes out of suspend with all PIC lines > unmasked for whatever reason, the PIC can observe that IRQ being raised and > the CPU not handling it. So yes, I forgot about 7 being magic, but I still > think it's the firmware which causes it by unmasking the PIC irqs. That's my understanding too. Thanks, Rafael