From patchwork Sat Jul 22 21:58:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Belloni X-Patchwork-Id: 792482 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-rtc-owner@vger.kernel.org; receiver=) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3xFM3L5J5wz9sPt for ; Sun, 23 Jul 2017 07:58:54 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751957AbdGVV6y (ORCPT ); Sat, 22 Jul 2017 17:58:54 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:42588 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdGVV6x (ORCPT ); Sat, 22 Jul 2017 17:58:53 -0400 Received: by mail.free-electrons.com (Postfix, from userid 110) id 9E33D21DDA; Sat, 22 Jul 2017 23:58:50 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.free-electrons.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from localhost (unknown [88.191.26.124]) by mail.free-electrons.com (Postfix) with ESMTPSA id 6FFA521DC6; Sat, 22 Jul 2017 23:58:50 +0200 (CEST) Date: Sat, 22 Jul 2017 23:58:51 +0200 From: Alexandre Belloni To: elseifthen@gmx.com Cc: rtc Subject: Re: Hardware specific rtc regression in v4.4.76 Message-ID: <20170722215851.ezxptqxetju44hgo@piout.net> References: <5c2ebf93-e45b-bc2d-e13b-618fdc12b3f3@gmx.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5c2ebf93-e45b-bc2d-e13b-618fdc12b3f3@gmx.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-rtc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org Hi, Thanks for the report. On 06/07/2017 at 15:16:11 -0400, elseifthen@gmx.com wrote: > There appears to be a hardware specific rtc regression in v4.4.76. > > Introduced in v4.4.52 by: > > commit f0414c1f8bb7a4e69064296f460773170c5435ac > Author: Colin Ian King > Date: Mon May 16 17:22:54 2016 +0100 > > rtc: interface: ignore expired timers when enqueuing new timers > > commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 upstream. > > 8< --- > > The problem does not appear to be in v4.9.x kernels. > > Maybe v4.4.76 is missing one of these? > http://marc.info/?l=linux-rtc&m=149489307123605&w=2 > Which also includes the commit in question. > > See this thread for more details: > https://www.linuxquestions.org/questions/slackware-14/slow-hwclock-systohc-on-reboot-shutdown-4175609040/ > > Note: I am not the one having this issue. I'm only reporting it, so any > questions would need to be asked in the above thread. Or perhaps the > person with the problem will follow this email thread. I will post a > link to it for them. > I can see a small issue with f0414c1f8bb7a4e69064296f460773170c5435ac but I'm not sure why it would be hit on v4.4 and not v4.9. Maybe one has CONFIG_RTC_INTF_DEV_UIE_EMUL and not the other one. Could you try with the following on top of v4.4.57 (or any other v4.4.x): alarm.time = rtc_ktime_to_tm(timer->node.expires); --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -764,7 +764,7 @@ static int rtc_timer_enqueue(struct rtc_device *rtc, struct rtc_timer *timer) } timerqueue_add(&rtc->timerqueue, &timer->node); - if (!next) { + if (!next || ktime_before(timer->node.expires, next->expires)) { struct rtc_wkalrm alarm; int err;