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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 6EC89C432C0 for ; Mon, 25 Nov 2019 16:21:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4DAA720740 for ; Mon, 25 Nov 2019 16:21:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728737AbfKYQV5 (ORCPT ); Mon, 25 Nov 2019 11:21:57 -0500 Received: from mailbackend.panix.com ([166.84.1.89]:55632 "EHLO mailbackend.panix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728683AbfKYQV5 (ORCPT ); Mon, 25 Nov 2019 11:21:57 -0500 Received: from hp-x360n (c-73-241-154-233.hsd1.ca.comcast.net [73.241.154.233]) by mailbackend.panix.com (Postfix) with ESMTPSA id 47MC3Q6f4fznl0; Mon, 25 Nov 2019 11:21:54 -0500 (EST) Date: Mon, 25 Nov 2019 08:21:53 -0800 (PST) From: "Kenneth R. Crudup" Reply-To: "Kenneth R. Crudup" To: "Rafael J. Wysocki" cc: Rafael Wysocki , Linux PM Subject: Re: Help me fix a regression caused by 56b9918490 (PM: sleep: Simplify suspend-to-idle control flow) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Mon, 25 Nov 2019, Rafael J. Wysocki wrote: > OK, but with sleep_no_lps0, does it also hang during resume or not? It never goes to sleep, is what I'm saying. Screen goes dark, but the machine seems to never go into sleep states. > In that case whatever happens in acpi_s2idle_wake() can be ruled out, > because on your system that function effectively is a NOP with > ec_no_wakeup. I don't expect the test below to add anything new to > what we know already. > > > acpi_os_wait_events_complete(); /* synchronize EC GPE processing */ > > > acpi_ec_flush_work(); > > > acpi_os_wait_events_complete(); /* synchronize Notify handling */ > So, as stated above, this test is not likely to be conclusive. I dunno ... did you see my other E-mail? Other than power-charge events waking up my laptop (and not going to sleep while plugged in), it hasn't hung up in several resume attempts, and doing power changes while asleep just wakes it up (be it charger being plugged in, or charger removed). Maybe this is expected behavor with those lines commented out, but at least I know now that it's possible to suspend and successfully resume under my standard workflow on a later-model kernel. > I'll send you a patch to try for that. I see that's in your next E-mail. I'll try it out shortly. -Kenny -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Silicon Valley