From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Galois.linutronix.de ([146.0.238.70]:36411 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751369AbdJEVeA (ORCPT ); Thu, 5 Oct 2017 17:34:00 -0400 Date: Thu, 5 Oct 2017 23:33:55 +0200 (CEST) From: Thomas Gleixner To: Gabriel Beddingfield cc: LKML , Stephen Boyd , John Stultz , Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org, Guy Erb , Howard Harte Subject: Re: Extreme time jitter with suspend/resume cycles In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-rtc-owner@vger.kernel.org List-ID: On Thu, 5 Oct 2017, Thomas Gleixner wrote: > On Thu, 5 Oct 2017, Gabriel Beddingfield wrote: > > > Hi Thomas, > > > > On Thu, Oct 5, 2017 at 11:01 AM, Thomas Gleixner wrote: > > >> > Which SoC/clocksource driver are you talking about? > > >> > > >> NXP i.MX 6SoloX > > >> drivers/clocksource/timer-imx-gpt.c > > > > > > So that clocksource driver looks correct. Do you have an idea in which > > > context this time jump happens? Does it happen when you exercise your high > > > frequency suspend/resume dance or is that happening just when you let the > > > machine run forever as well? > > > > We couldn't devise any reproduction steps. We observed it happening at > > unexpected times in a fleet of devices -- and we couldn't find any > > patterns to clue us in. > > Ok. Did you talk to NXP about that? Or did you try to exercise reads in a > loop to detect the wreckage and maybe a pattern in there? The reason I'm asking is to exclude any weird issue in the timekeeping code, which is still a possibility, despite the fact that I went through it with a fine comb after stumbling over that check in the resume path. Thanks, tglx