From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753547AbeDZGsP (ORCPT ); Thu, 26 Apr 2018 02:48:15 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:61084 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751465AbeDZGsM (ORCPT ); Thu, 26 Apr 2018 02:48:12 -0400 From: "Rafael J. Wysocki" To: Steven Rostedt Cc: Linus Torvalds , Thomas Gleixner , Mark Salyzyn , Ingo Molnar , Peter Zijlstra , John Stultz , Peter Anvin , Michael Kerrisk , Prarit Bhargava , Pavel Machek , Kevin Easton , Dmitry Torokhov , Petr Mladek , Linux Kernel Mailing List , SergeySenozhatsky , Jonathan Corbet , linux-tip-commits@vger.kernel.org Subject: Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME Date: Thu, 26 Apr 2018 08:48:00 +0200 Message-ID: <1818264.9sG3yaIMPm@aspire.rjw.lan> In-Reply-To: <20180425184140.6b6e524d@vmware.local.home> References: <5695751.Ycq0WTIcbj@aspire.rjw.lan> <20180425184140.6b6e524d@vmware.local.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, April 26, 2018 12:41:40 AM CEST Steven Rostedt wrote: > On Wed, 25 Apr 2018 22:57:12 +0200 > "Rafael J. Wysocki" wrote: > > > FWIW, I run (64-bit) OpenSUSE 42.3 on the failing machine (Acer Aspire S5) with > > my own kernel (custom config based on the distro one). > > > > The problem here is that the machine doesn't resume from S2R. It appears to > > just hang somewhere around where we return to user space. However, to trigger > > the issue it needs to stay in suspend for several minutes (not sure how many > > exactly). If it is just back-to-back suspend/resume, it will resume correctly. > > I guess the question that needs to be asked is, have you tried a kernel > with this commit reverted and it works? Yes, I have. > I'd play a bit going back and > forth between two kernels, one with the commit and one without and no > other differences, to make sure that is indeed the problem commit. I've done that. It is the problem commit. Thanks, Rafael