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.3 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 EE065C3A5A6 for ; Thu, 19 Sep 2019 16:09:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C7A0F21BE5 for ; Thu, 19 Sep 2019 16:09:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391679AbfISQJo (ORCPT ); Thu, 19 Sep 2019 12:09:44 -0400 Received: from mailbackend.panix.com ([166.84.1.89]:45600 "EHLO mailbackend.panix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391682AbfISQJo (ORCPT ); Thu, 19 Sep 2019 12:09:44 -0400 Received: from hp-x360n (unknown [12.245.190.214]) by mailbackend.panix.com (Postfix) with ESMTPSA id 46Z1yF4L5KzmfW; Thu, 19 Sep 2019 12:09:41 -0400 (EDT) Date: Thu, 19 Sep 2019 09:09:39 -0700 (PDT) From: "Kenneth R. Crudup" Reply-To: "Kenneth R. Crudup" To: "Rafael J. Wysocki" cc: Rafael Wysocki , Linux PM Subject: Re: Help me help you debug what seems to be an EC resume issue 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 Thu, 19 Sep 2019, Rafael J. Wysocki wrote: > If so, you can try writing 1 into > /sys/module/acpi/parameters/sleep_no_lps0 and see if that makes any > difference (without using ec_no_wakeup). I'll try that soon; in a classic case of "it never makes that sound at the mechanic's shop" I've done some 6+ sleep cycles since E-mailing you (and with "ec_no_wakeup" off), and all have come back OK. Increased power drain during random suspend cycles is still an issue, though, but that may be unrelated. (I did remove the MEI driver from the kernel, as I was seeing error returns during probing on the resume end with "no_console_suspend/initcall_debug" on, but I'd be surprised if that were an issue here. I have no need for the MEI at all, but it's been my experience that loading drivers for devices seem to reduce the power consumption in s2idle even if I don't (directly) use them (i.e., I see higher s2idle power drain if I don't enable the "skl_uncore" driver).) -Kenny -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Silicon Valley