Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp11550660pxu; Thu, 31 Dec 2020 12:52:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJyJdCDNi+DXthPhZCDTxxqn9wKuEUDZIOxdo83dqJLZ4wvcGsy0/TcICMYN50+KhoflywaN X-Received: by 2002:a17:906:5182:: with SMTP id y2mr55927638ejk.92.1609447929723; Thu, 31 Dec 2020 12:52:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609447929; cv=none; d=google.com; s=arc-20160816; b=ROs3Q8Ygt2xJk9jvhOU3sTGxwfNtebuNtamu7vsLsepaTJqKOGa3FXM2HGerYxzNiO 8kq6nl1cDv94XLEVhcIiWgz1Yn8jP9+S2WdP65C50l04mVhEF1Fbj6GXYb/LQOUYd89C 0ztZufX9mlVXJztYf59FowN3b6XSLcTqfTCbfcL+tJQYRDE16ToKykrVkJicGgYp7VuM q4LRYD+brNwF0yKjT4WpJCMAyjtF2XHN4yFoi8rgx3uKTwD7zxWQwVh/15krIE48uzTu dcOgcMpFskYfyPBUSy10tfcbyqxJBVVVLPiHUCtDn5bauXRKjKElr8+Kb7a7UYnKA+7L rk+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=E/LRHlXj7uavDI3Wyexw7wPoL6hfcTyUjCtWcvdb3Pk=; b=07mDRCj0JcVy0Xnajq7/73hwStmLqoa3UIsSbZmQqlfuPRquV90Mub9Y4844V9e+mD vNBFJOasdOgJZ2MDvmX+1PpzmEzbH8BjGuUaBuVZgp9bBj6F/mxCG9ntveTQqlmuMH/x wwRkS8StoWMl8ngErFq8aXhyaIsfeqHJ3AWROKV5LqKtficmTG3dcPz1F5C/lbOfhVZV jFjMxAVMQperd6//O2mCBFHQn8eSXsQ38TOj+oXEyMKVIlyz+eRCf4Hkcv2rRyR4g7ox F9zFh0fEZr9LmJVbU/yrNK1jmmwo3IPKU36WWFOhaRbF6Wbx5+20WtzAZxXNOXehSwUV cFYA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pw18si23323235ejb.163.2020.12.31.12.51.47; Thu, 31 Dec 2020 12:52:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726795AbgLaUqz (ORCPT + 99 others); Thu, 31 Dec 2020 15:46:55 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:56294 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726210AbgLaUqz (ORCPT ); Thu, 31 Dec 2020 15:46:55 -0500 Received: from 89-77-60-66.dynamic.chello.pl (89.77.60.66) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.537) id adb218dee83d9126; Thu, 31 Dec 2020 21:46:12 +0100 From: "Rafael J. Wysocki" To: Sebastian Andrzej Siewior , Stephen Berman Cc: Zhang Rui , Robert Moore , Erik Kaneda , Len Brown , Thomas Gleixner , Peter Zijlstra , Linux Kernel Mailing List , ACPI Devel Maling List , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , "Rafael J. Wysocki" Subject: Re: power-off delay/hang due to commit 6d25be57 (mainline) Date: Thu, 31 Dec 2020 21:46:11 +0100 Message-ID: <9709109.MH8tSaV5v9@kreacher> In-Reply-To: References: <87blkbx1gt.fsf@gmx.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 2, 2020 8:13:38 PM CET Rafael J. Wysocki wrote: > On Wed, Dec 2, 2020 at 7:31 PM Rafael J. Wysocki wrote: > > > > On Wed, Dec 2, 2020 at 7:03 PM Sebastian Andrzej Siewior > > wrote: > > > > > > On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote: > > > > > > > > Done as Bug 208877. > > > > > > Rafael, do you have any suggestions? > > > > > > > > > > I've lost track of this sorry. > > > > > > > > > > I have ideas, let me get back to this next week. > > > > > > > > :) > > > > > > Rafael, any update? If you outline an idea or so then I may be able to > > > form a patch out of it. Otherwise I have no idea how to fix this - other > > > than telling the driver to not poll in smaller intervals than > > > 30secs. > > > > The idea, roughly speaking, is to limit the number of outstanding work > > items in the queue (basically, if there's a notification occurring > > before the previous one can be handled, there is no need to queue up > > another work item for it). > > That's easier said than done, though, because of the way the work item > queue-up is hooked up into the ACPICA code. So scratch this and it wouldn't work in general anyway AFAICS. ATM, I'm tempted to do something like the patch below (with the rationale that it shouldn't be necessary to read the temperature right after updating the trip points if polling is in use, because the next update through polling will cause it to be read anyway and it will trigger trip point actions as needed). Stephen, can you give it a go, please? --- drivers/acpi/thermal.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) Index: linux-pm/drivers/acpi/thermal.c =================================================================== --- linux-pm.orig/drivers/acpi/thermal.c +++ linux-pm/drivers/acpi/thermal.c @@ -911,24 +911,25 @@ static void acpi_thermal_notify(struct a switch (event) { case ACPI_THERMAL_NOTIFY_TEMPERATURE: acpi_thermal_check(tz); - break; + return; case ACPI_THERMAL_NOTIFY_THRESHOLDS: acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_THRESHOLDS); - acpi_thermal_check(tz); - acpi_bus_generate_netlink_event(device->pnp.device_class, - dev_name(&device->dev), event, 0); break; case ACPI_THERMAL_NOTIFY_DEVICES: acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_DEVICES); - acpi_thermal_check(tz); - acpi_bus_generate_netlink_event(device->pnp.device_class, - dev_name(&device->dev), event, 0); break; default: ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Unsupported event [0x%x]\n", event)); - break; + return; } + + /* Trigger an update of the thermal zone unless polling is in use. */ + if (!tz->polling_frequency) + acpi_thermal_check(tz); + + acpi_bus_generate_netlink_event(device->pnp.device_class, + dev_name(&device->dev), event, 0); } /*