public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Mark Lord <kernel@teksavvy.com>
Cc: richard -rw- weinberger <richard.weinberger@gmail.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	rtc-linux@googlegroups.com,
	Alessandro Zummo <a.zummo@towertech.it>,
	Greg Kroah-Hartman <greg@kroah.com>,
	stable@vger.kernel.org,
	Rabin Vincent <rabin.vincent@stericsson.com>
Subject: Re: [REGRESSION] rtc/interface.c: kills suspend-to-ram
Date: Mon, 16 Apr 2012 22:13:54 -0700	[thread overview]
Message-ID: <4F8CFC12.6050700@linaro.org> (raw)
In-Reply-To: <4F8CD5D3.8060006@teksavvy.com>

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)


  reply	other threads:[~2012-04-17  5:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-16  4:36 [REGRESSION] rtc/interface.c: kills suspend-to-ram Mark Lord
2012-04-16 13:55 ` Mark Lord
2012-04-16 14:23   ` richard -rw- weinberger
2012-04-16 15:42     ` Mark Lord
2012-04-16 15:49       ` richard -rw- weinberger
2012-04-16 15:57         ` Mark Lord
2012-04-16 19:45           ` John Stultz
2012-04-16 21:43             ` John Stultz
2012-04-17  2:30               ` Mark Lord
2012-04-17  5:13                 ` John Stultz [this message]
2012-04-17 12:51                   ` Mark Lord
2012-04-17 20:11                   ` Mark Lord
2012-04-17 20:12                     ` Mark Lord
2012-04-17 23:02                     ` John Stultz
2012-04-18  1:29                       ` Mark Lord
2012-04-18 18:29                         ` John Stultz
2012-04-27 14:33                           ` Mark Lord
2012-04-27 19:22                             ` John Stultz
2012-04-16 19:44     ` John Stultz
2012-04-17  2:27       ` Mark Lord
2012-04-16 14:26   ` [rtc-linux] " Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F8CFC12.6050700@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=a.zummo@towertech.it \
    --cc=greg@kroah.com \
    --cc=kernel@teksavvy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rabin.vincent@stericsson.com \
    --cc=richard.weinberger@gmail.com \
    --cc=rtc-linux@googlegroups.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox