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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0EDD0C636CC for ; Tue, 7 Feb 2023 19:49:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=I7i7wxC+n8ZxKTjK8LN6i7ntKXx3mTpn9k1BI1XT2R4=; b=GyjFkIk2R3CiJH WqP5gQHPt+5GXxQZJ+V9c9QaqXCQMo399OsXM7SnCluB2Z405cDHVNkcHA6AiWVhQVxlsDwbqgbVI suiURt6EpWDXC944JjIns4f5PhgHLTitB5aPc9WuUELi5tcdkPc8qCvjCx2hQb9mWMx97uFVqUVr1 1mrJ+fQB7t2vKY6fYWszGRrZWX+2EpfrMOtzyXn4IPY0/83YhfuTX2MnfPa+lfRxpXIUDSviPh6Jw w4QslpbhmVRZzk3XUiE2WDKwT63epw1XfFIeWzMETADrRAPi5rUFWVGSUv4OkP29c496il82DaNV4 DdzD/9nGrQB3ex5yxCXg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPTxA-00DFTP-CV; Tue, 07 Feb 2023 19:48:32 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPTx5-00DFSy-Io for linux-arm-kernel@lists.infradead.org; Tue, 07 Feb 2023 19:48:28 +0000 Received: by mail-pj1-x1029.google.com with SMTP id e10-20020a17090a630a00b0022bedd66e6dso19742771pjj.1 for ; Tue, 07 Feb 2023 11:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=LiWVu1jgFnS1+P8PNhmhOYa+Kepk/2Rz7b7N9cflsAA=; b=ZYf0UmPAx9R+uq1Zz9jXf1Rm5fhptrN1VmgDJrPBlkbVz4ov63OJ8KC2cftVZ2MU2I y34Q5nwMxEkq0GGgkjFEt9mKVSwAZSFe+6oTRzPS7KC3aImEOAAAUV+TTB6SM4dJSCnD LhPNJr/YtDH7uhNRhDpt+WL7S9oZ1uduBF5cYCqGznaiYFqCzAm7VU9lNaNGkc1RRMdZ OW75NfLDzx+r5Llzz4HxwQObaOKrjb41+NemtsfIRqT+c/4ZJJBp3n4vo84tC4nAG2BQ MyOg/ab71HJPyNAFzUF9cjZsgJ+6zTabX1dG2ZA/VsFSxgLaJu8eQ0zoaCQdVJeCd3lr PS1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LiWVu1jgFnS1+P8PNhmhOYa+Kepk/2Rz7b7N9cflsAA=; b=6876BizY7Kkrwirzd9nYvU/40TVFnT5J10RLFapXRFdf6BE7hA5U58uWtnOZUB+SQ7 9Zs/9SyjkcCyJ7sBzBRM7S6Kc/bVbB7zaEaxok4doTBGG3cLi3DCenmf3efz+4oe2Gis 9MJY7PXOW1U0zZ4WaqS3iMSYEpPsLRa5ntMtfMSc5qAYQ4xJcmECgxsjEg41rB/NsTOV O1cJznh085ZUjRmdFbF8yYkDnzUTe7y54DTv+IFf/FJbbIp/4vf2Ll04i7chgEbTihUM Y4f1lc0jzRbKCNOMjxadOKgGZN98vg/LNpRcQv/FfleRlBgj0vaytma1yk4MoLia6b37 c5NA== X-Gm-Message-State: AO0yUKUMyAUHH7t238UcTeo63kGErWi9VLzp520KH1SCC1RtvKbJm8TE V0QfVk7pI34CG3ZvH80YGS4= X-Google-Smtp-Source: AK7set+NvM8i3lT33CXtGrDWJAwfckpQzCOBvgqnvLW0qeIC5ORnJqLpqvc4+Sdb01dWUyPk2Yi6fQ== X-Received: by 2002:a17:90b:4b4a:b0:22c:9782:e718 with SMTP id mi10-20020a17090b4b4a00b0022c9782e718mr5619830pjb.0.1675799304047; Tue, 07 Feb 2023 11:48:24 -0800 (PST) Received: from kazuki-mac ([2400:4051:ea3:5910::19a]) by smtp.gmail.com with ESMTPSA id z21-20020a17090a8b9500b00226156cf039sm11897519pjn.44.2023.02.07.11.48.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Feb 2023 11:48:23 -0800 (PST) From: Kazuki X-Google-Original-From: Kazuki Date: Wed, 8 Feb 2023 04:48:18 +0900 To: Sudeep Holla Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sudeep Holla , "Rafael J. Wysocki" , Daniel Lezcano , Lorenzo Pieralisi , Hector Martin , Sven Peter , Len Brown , Pavel Machek Subject: Re: s2idle breaks on machines without cpuidle support Message-ID: <20230207194818.exskn3dhyzqwr32v@kazuki-mac> References: <20230204152747.drte4uitljzngdt6@kazuki-mac> <20230206101239.dret3fv65cnzpken@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230206101239.dret3fv65cnzpken@bogus> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230207_114827_661683_335A105A X-CRM114-Status: GOOD ( 27.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 06, 2023 at 10:12:39AM +0000, Sudeep Holla wrote: > Hi Kazaki, > > On Sun, Feb 05, 2023 at 12:27:47AM +0900, Kazuki wrote: > > > > Hi everyone, > > > > s2idle is blocked on machines without proper cpuidle support here > > in kernel/sched/idle.c: > > > > > if (cpuidle_not_available(drv, dev)) { > > > tick_nohz_idle_stop_tick(); > > > > > default_idle_call(); > > > goto exit_idle; > > > } > > > > > /* > > > * Suspend-to-idle ("s2idle") is a system state in which all user space > > > * has been frozen, all I/O devices have been suspended and the only > > > > However, there are 2 problems with this approach: > > > > 1. The suspend framework does not expect this, and continues to suspend the > > machine, which causes machines without proper cpuidle support to break when > > suspending > > What do you mean by break ? More details on the observation would be helpful. For example, CLOCK_MONOTONIC doesn't stop even after suspend since these chain of commands don't get called. call_cpuidle_s2idle->cpuidle_enter_s2idle->enter_s2idle_proper->tick_freeze->sched_clock_suspend (Function that pauses CLOCK_MONOTONIC) Which in turn causes programs like systemd to crash since it doesn't expect this. > > > 2. Suspend actually works on ARM64 machines even without proper > > cpuidle (PSCI cpuidle) since they support wfi, so the assumption here is wrong > > on such machines > > > > Sorry I am bit confused here. Your point (2) contradicts the $subject. drivers/cpuidle/cpuidle.c: bool cpuidle_not_available(struct cpuidle_driver *drv, struct cpuidle_device *dev) { return off || !initialized || !drv || !dev || !dev->enabled; } The cpuidle framework reports ARM64 devices without PSCI cpuidle as "cpuidle not available" even when they support wfi, which causes suspend to fail, which shouldn't be happening since they do support idling. > > > I'm not exactly sure how to figure this out, and my attempts have all led to an > > unbootable kernel, so I've cc'ed the relevant people and hopefully we can find a > > solution to this problem. > > > > Again, since s2idle is userspace driven, I don't understand what do you > mean by unbootable kernel in the context of s2idle. Sorry, I meant "attempts to fix this bug have all led to an unbootable kernel." > > -- > Regards, > Sudeep Thanks, Kazuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel