From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e5.ny.us.ibm.com", Issuer "GeoTrust SSL CA" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 873BF2C007E for ; Tue, 21 Aug 2012 05:58:36 +1000 (EST) Received: from /spool/local by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 20 Aug 2012 15:58:33 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 41E3D38C8047 for ; Mon, 20 Aug 2012 15:58:08 -0400 (EDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7KJw7nm171574 for ; Mon, 20 Aug 2012 15:58:08 -0400 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7KJvvdj029074 for ; Mon, 20 Aug 2012 13:57:58 -0600 Message-ID: <503296C1.4070906@linaro.org> Date: Mon, 20 Aug 2012 12:57:53 -0700 From: John Stultz MIME-Version: 1.0 To: Andreas Schwab Subject: Re: [PATCH 4/8] time: Condense timekeeper.xtime into xtime_sec References: <1342156917-25092-1-git-send-email-john.stultz@linaro.org> <1342156917-25092-5-git-send-email-john.stultz@linaro.org> <503288ED.10306@linaro.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Prarit Bhargava , Peter Zijlstra , Richard Cochran , Linux Kernel , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, Ingo Molnar List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 08/20/2012 12:45 PM, Andreas Schwab wrote: > John Stultz writes: > >> I'm not very familiar w/ the iBook hardware, but does it use a >> clocksource, or does it use arch_gettimeoffset()? > clocksource: timebase mult[3640e38e] shift[24] registered > >> I suspect that the casting has avoided clipping some strange values from >> the persistent clock. > That's my guess as well. > >> Could you try with the following patch against Linus' HEAD? I suspect it >> will let the box resume (although it will seem as though no time was >> spent in resume) and then let me know what the JDB lines print out? > JDB: suspend_time: 1345491706:0 resume_time: 1345491737:0 > JDB: Trying to add: 31:0 > > (Looks reasonable.) Huh. Yea, that looks fine. And without the __timekeeping_inject_sleeptime() call, the system resumed ok? Thanks for the testing! I'll keep looking here. -john From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754681Ab2HTT6U (ORCPT ); Mon, 20 Aug 2012 15:58:20 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:54609 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754626Ab2HTT6P (ORCPT ); Mon, 20 Aug 2012 15:58:15 -0400 Message-ID: <503296C1.4070906@linaro.org> Date: Mon, 20 Aug 2012 12:57:53 -0700 From: John Stultz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Andreas Schwab CC: Linux Kernel , Ingo Molnar , Peter Zijlstra , Richard Cochran , Prarit Bhargava , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 4/8] time: Condense timekeeper.xtime into xtime_sec References: <1342156917-25092-1-git-send-email-john.stultz@linaro.org> <1342156917-25092-5-git-send-email-john.stultz@linaro.org> <503288ED.10306@linaro.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12082019-5518-0000-0000-000006FACFDC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/20/2012 12:45 PM, Andreas Schwab wrote: > John Stultz writes: > >> I'm not very familiar w/ the iBook hardware, but does it use a >> clocksource, or does it use arch_gettimeoffset()? > clocksource: timebase mult[3640e38e] shift[24] registered > >> I suspect that the casting has avoided clipping some strange values from >> the persistent clock. > That's my guess as well. > >> Could you try with the following patch against Linus' HEAD? I suspect it >> will let the box resume (although it will seem as though no time was >> spent in resume) and then let me know what the JDB lines print out? > JDB: suspend_time: 1345491706:0 resume_time: 1345491737:0 > JDB: Trying to add: 31:0 > > (Looks reasonable.) Huh. Yea, that looks fine. And without the __timekeeping_inject_sleeptime() call, the system resumed ok? Thanks for the testing! I'll keep looking here. -john