From patchwork Tue Apr 17 05:13:54 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 153058 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.213.184]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 362A1B702F for ; Tue, 17 Apr 2012 15:14:56 +1000 (EST) Received: by yenl1 with SMTP id l1sf5543506yen.11 for ; Mon, 16 Apr 2012 22:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:x-content-scanned :x-cbid:x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:sender:list-subscribe:list-unsubscribe :content-type; bh=Dv3kGT6Sv47ZMbvvdcFSNbdMFXYrQxYP2OhGWdE+Qw0=; b=N/gLgdRgBQW0YD9lMcaSlF3DAss1t/T+ZxmUHvMqR8F1ypYBJi3quaowz+XsKrHg1z OYLYiTyw3hpLBaqTxW2/VWUsc8WV/ch4NnBLf7y0XCCpdK2sc2Icv2k3WDLOHTFI+NTM lWlGP/nsCmiWYVQVamJ8Wa5en3cA4gbAHaCWs= Received: by 10.50.220.167 with SMTP id px7mr1979596igc.3.1334639692840; Mon, 16 Apr 2012 22:14:52 -0700 (PDT) X-BeenThere: rtc-linux@googlegroups.com Received: by 10.231.76.138 with SMTP id c10ls5947534ibk.7.gmail; Mon, 16 Apr 2012 22:14:52 -0700 (PDT) Received: by 10.42.197.137 with SMTP id ek9mr8961558icb.5.1334639692386; Mon, 16 Apr 2012 22:14:52 -0700 (PDT) Received: by 10.42.197.137 with SMTP id ek9mr8961557icb.5.1334639692368; Mon, 16 Apr 2012 22:14:52 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com. [32.97.110.149]) by gmr-mx.google.com with ESMTPS id md3si5964452igc.1.2012.04.16.22.14.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 22:14:52 -0700 (PDT) Received-SPF: neutral (google.com: 32.97.110.149 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) client-ip=32.97.110.149; Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 16 Apr 2012 23:14:51 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 16 Apr 2012 23:13:58 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 9992E1FF004A for ; Mon, 16 Apr 2012 23:13:56 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3H5DvgY176918 for ; Mon, 16 Apr 2012 23:13:57 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3H5Duwq014344 for ; Mon, 16 Apr 2012 23:13:56 -0600 Received: from [9.48.85.214] (sig-9-48-85-214.mts.ibm.com [9.48.85.214]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3H5DsxH014249; Mon, 16 Apr 2012 23:13:55 -0600 Message-ID: <4F8CFC12.6050700@linaro.org> Date: Mon, 16 Apr 2012 22:13:54 -0700 From: John Stultz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mark Lord CC: richard -rw- weinberger , Linux Kernel , rtc-linux@googlegroups.com, Alessandro Zummo , Greg Kroah-Hartman , stable@vger.kernel.org, Rabin Vincent Subject: [rtc-linux] Re: [REGRESSION] rtc/interface.c: kills suspend-to-ram References: <4F8BA1C1.4030804@teksavvy.com> <4F8C24E5.4020703@teksavvy.com> <4F8C3DDF.8030103@teksavvy.com> <4F8C415C.80806@teksavvy.com> <4F8C76EB.20709@linaro.org> <4F8C926D.2040503@linaro.org> <4F8CD5D3.8060006@teksavvy.com> In-Reply-To: <4F8CD5D3.8060006@teksavvy.com> X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12041705-7282-0000-0000-0000083E879B X-Original-Sender: john.stultz@linaro.org X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 32.97.110.149 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) smtp.mail=john.stultz@linaro.org Reply-To: rtc-linux@googlegroups.com Precedence: list Mailing-list: list rtc-linux@googlegroups.com; contact rtc-linux+owners@googlegroups.com List-ID: X-Google-Group-Id: 712029733259 List-Post: , List-Help: , List-Archive: Sender: rtc-linux@googlegroups.com List-Subscribe: , List-Unsubscribe: , On 04/16/2012 07:30 PM, Mark Lord wrote: > > Thanks for looking into it, John. > > I also spent many more hours digging away at it here today, > and I now understand (mostly) what is happening and why. > > The code above introduces a new access to the RTC that never existed before. > For the case where the Alarm has never been enabled by software, > I believe the code above will still try to "disable" it. > That's the new behaviour we didn't have prior to this patch. > > And.. on some of the systems I'm testing on, the BIOS setup has > the RTC Alarm "enabled", which means "under BIOS control", > as opposed to "disabled" which means "under software control". > > It's the "under BIOS control" systems that the above patch breaks. > > So I think the code may just need to be slightly more clever, > and not disable an Alarm that was never enabled by software in the first place. Thanks for the extra info. Although I'm still a little perplexed why that's causing trouble. When "under BIOS control" is the RTC unusable by the kernel? Will any access cause problems? Or just the extra disable path? On a hunch, I wonder if your tripping over the alarmtimer initialization issue that was recently fixed. Have you also seen this issue w/ 3.4-rc2+ ? I still can't trigger anything similar playing with the BIOS options for my system. If its not too much trouble, could you try the following two changes? thanks -john I guess I'm curious why you're hitting the rtc_alarm_disable if you're not using the alarm. If you use the following diff, can you provide the resulting stack traces? diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index eb415bd..4c98ee5 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -786,7 +786,8 @@ static void rtc_alarm_disable(struct rtc_device *rtc) if (!rtc->ops || !rtc->ops->alarm_irq_enable) return; - rtc->ops->alarm_irq_enable(rtc->dev.parent, false); + //rtc->ops->alarm_irq_enable(rtc->dev.parent, false); + dump_stack(); } /** Then un-comment/re-add the alarm_irq_enable() call above, and try the following, to see if the behavior changes? Then re-add each line one by one to see if you can isolate where things go wrong in the cmos code? diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 7d5f56e..c500bce 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -318,9 +318,9 @@ static void cmos_irq_disable(struct cmos_rtc *cmos, unsigned char mask) rtc_control = CMOS_READ(RTC_CONTROL); rtc_control&= ~mask; CMOS_WRITE(rtc_control, RTC_CONTROL); - hpet_mask_rtc_irq_bit(mask); + //hpet_mask_rtc_irq_bit(mask); - cmos_checkintr(cmos, rtc_control); + //cmos_checkintr(cmos, rtc_control); } static int cmos_set_alarm(struct device *dev, struct rtc_wkalrm *t)