Received: by 10.192.165.148 with SMTP id m20csp475702imm; Wed, 2 May 2018 03:42:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZofDijySKuwCfDdfXyO/JAQyJ03ah9Om9AYPIdxv21FDRYw4dxNxrzJlOUjh4ghInpFhru8 X-Received: by 2002:a17:902:59ce:: with SMTP id d14-v6mr19980751plj.253.1525257776382; Wed, 02 May 2018 03:42:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525257776; cv=none; d=google.com; s=arc-20160816; b=wxK5viXq/NG4cwMiKk3eG32J3D6Wi4JeMUdBZefjelH6Jq/XYm41eVlj25/crpp0XH +Jyuz/tR+lWbx5W+LVIUQLoHrWGhxJaOG3e4xyxe6zEiKV6A2/63gPgool0XdkH9Eif9 sLHpwaS1jCkvS+n572aEMHe4rBxVgvDrbH9BwAOFEkBitjRkP7Xd1orwBRaMLJ7yKY6l P1CkZfR9wkz82b9JSlvUPu+IBqphUntHbDVdkLXlRdwIXnWHsa1tMUFVatXMff2gAkvF 4FXsmvCWIEpKlEWHodOHmJkkMsFWhsJNgvS/E7wNWP4tgLcKiPsnrHJ4TYMp66G9YsvA RUNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=kAnZNnkl++KZIsFIhX+k033AWhS/y13bfSSNO76AI2k=; b=WTC4ESISsn2MZfVGVe1BDcqaKsfICp1Qi0RnPNI0msVPm9IKeagzFJ97dFlqCYD8Ja vsCAq0mrVvk7dkFAlxDU6Je8D4YMTsM2tQ3489G51/1G47CCn82AWRPcuRVbNOYLvmpc emlnNeouumPwTV9e9+D7O2CN4M9wdjW2dkJHchStRYFGc2nBeYvdBJaAU+Mt7pUCl2X8 JrDHdXFVt5ieuUlZR/EVZyDLSvNU8jjRYRpPDEjUeiDDKvjSlZXITbaO/WQJkkbUFfIg w9MImtXj6yp3UXuVjRXbdX7REwa1aXcwj8S/0/9tdt9bKHtVn7N1sK7pjgvtZcCCavm0 eIkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=JYAdDT0g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m140si2470801pfd.16.2018.05.02.03.42.42; Wed, 02 May 2018 03:42:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=JYAdDT0g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751236AbeEBKlH (ORCPT + 99 others); Wed, 2 May 2018 06:41:07 -0400 Received: from mail-ot0-f177.google.com ([74.125.82.177]:38185 "EHLO mail-ot0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750936AbeEBKlE (ORCPT ); Wed, 2 May 2018 06:41:04 -0400 Received: by mail-ot0-f177.google.com with SMTP id j27-v6so16004920ota.5; Wed, 02 May 2018 03:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kAnZNnkl++KZIsFIhX+k033AWhS/y13bfSSNO76AI2k=; b=JYAdDT0g0/fDqkBtVa23Enan9/EAc45lSb7yxuGVbHfZnoCvE/YT1CvrqmapuB/N+k 4T/4Dz1ce1+vrzXCHwsgUictx2E8YQz7PVDWtd2+N1jfpzlA+mWntlm8Ia0iNnPutsK9 ssjYG9fqbbYoKjas/FGHTi6wVflwv/0ErLnOauFA4PsR5n/pM7QiiVDdYbWdMZTR5wk0 NTi+j6FuNTXmj+TVyaZt/u0fVgQnLrNCi2ZOHhNhOeDeJa6xQ9S/6Afw7rUm44E55gCb TPHGWtziPg8s5n4tCCB56LOGlpmjOABSXVjsXFV78XHKGr656jLr0Q841+2vSeK7vkCh RtEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kAnZNnkl++KZIsFIhX+k033AWhS/y13bfSSNO76AI2k=; b=BaG4Cz848y6HKcbNMQD6iE1UfvR5PrO+PtGkon43qXVDfBsL1ipgh0FmYr6cp/X76O 3mDiLBhl1UmXysRHjTp/sg8ts79OIbpKF0k7V8LmM+P/IqLJQ5thEDTs9mXXWDzqN/OI FT2mDvCFGvlhxkQsrrftun7M+DUTSWP5jJoo+58QJUAK2S1BzhzRxB/ydtMtQ28vJ1gI 27q48kPZQX/UFntJa1wABnCiyzMt1OKhN52+VbKIGThoANKwXysN2UiB1ShRi8rtz5/k BLVFnLd/mYZ4SGH/17pw+kCPu6zWhlP7WWVj1IZ6xDs5Yx/oLqghL/OaA/5KqyGL581e pSpA== X-Gm-Message-State: ALQs6tB4JlZGiLQt9OCfb8zKS76gbK4YRVe6mHl9z2hpOM5H+bTUMIL2 hrFlSMoivbKg+GhiTPT2Aa+vPC4/xMkQCBCvjZ4= X-Received: by 2002:a9d:721d:: with SMTP id u29-v6mr12760816otj.305.1525257664050; Wed, 02 May 2018 03:41:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1468:0:0:0:0:0 with HTTP; Wed, 2 May 2018 03:41:03 -0700 (PDT) In-Reply-To: <20180501195501.GB11698@bhelgaas-glaptop.roam.corp.google.com> References: <56a8953c-d833-837c-57d5-fe758d4db02a@canonical.com> <1f67f00a-8141-f9af-2120-c78f7cfecb1d@canonical.com> <20180501195501.GB11698@bhelgaas-glaptop.roam.corp.google.com> From: "Rafael J. Wysocki" Date: Wed, 2 May 2018 12:41:03 +0200 X-Google-Sender-Auth: yj7Btk2bLWv9vXUm6mFPSmt_468 Message-ID: Subject: Re: [Regression] PCI / PM: Simplify device wakeup settings code To: Bjorn Helgaas , Joseph Salisbury Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Len Brown , Bjorn Helgaas , ACPI Devel Maling List , Linux PCI , "linux-kernel@vger.kernel.org" , 1745646@bugs.launchpad.net, Mika Westerberg Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas wrote: > On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote: >> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury >> wrote: >> > On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote: >> >> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury >> >> wrote: >> >>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote: >> >>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury >> >>>> wrote: >> >>>>> Hi Rafael, >> >>>>> >> >>>>> A kernel bug report was opened against Ubuntu [0]. After a kernel >> >>>>> bisect, it was found that reverting the following two commits resolved >> >>>>> this bug: >> >>>>> >> >>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration") >> >>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code") >> >>>>> >> >>>>> This is a regression introduced in v4.13-rc1 and still exists in >> >>>>> mainline. The bug causes the battery to drain when the system is >> >>>>> powered down and unplugged, which does not happed prior to these two >> >>>>> commits. >> >>>> What system and what do you mean by "powered down"? How much time >> >>>> does it take for the battery to drain now? >> >>> By powered down, the bug reporter is saying physically powered off and >> >>> unplugged. The system is a HP laptop: >> >>> >> >>> dmi.chassis.vendor: HP >> >>> dmi.product.family: 103C_5335KV HP Notebook >> >>> dmi.product.name: HP Notebook >> >>> vendor_id : GenuineIntel >> >>> cpu family : 6 >> >>> >> >>> >> >>>>> The bisect actually pointed to commit de3ef1e, but reverting >> >>>>> these two commits fixes the issue. >> >>>>> >> >>>>> I was hoping to get your feedback, since you are the patch author. Do >> >>>>> you think gathering any additional data will help diagnose this issue, >> >>>>> or would it be best to submit a revert request? >> >>>> First, reverting these is not an option or you will break systems >> >>>> relying on them now. 4.13 is three releases back at this point. >> >>>> >> >>>> Second, your issue appears to be related to the suspend/shutdown path >> >>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the >> >>>> change in pci_enable_wake() causes the problem to happen. Can you try >> >>>> to revert this one alone and see if that helps? >> >>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was >> >>> tested. However, the test kernel still exhibited the bug. >> >> So essentially the bisection result cannot be trusted. >> > >> > We performed some more testing and confirmed just a revert of the >> > following commit resolves the bug: >> > >> > 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code") >> >> Thanks for confirming this! >> >> > Can you think of any suggestions to help debug further? >> >> The root cause of the regression is likely the change in >> pci_enable_wake() removing the device_may_wakeup() check from it. >> >> Probably, one of the drivers in the platform calls pci_enable_wake() >> directly from its ->shutdown() callback and that causes the device to >> be set up for system wakeup which in turn causes the power draw while >> the system is off to increase. >> >> I would look at the PCI drivers used on that platform to find which of >> them call pci_enable_wake() directly from ->shutdown() and I would >> make these calls conditional on device_may_wakeup(). > > I took a quick look with > > git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup" > > and didn't notice any pci_enable_wake() callers that called > device_may_wakeup() first. I've just look at a bunch of network drivers doing that. It looks like I may need to restore __pci_enable_wake() with an extra "runtime" argument for internal use. Joseph, can you ask the reporter to test the Bjorn's patch, please?