summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2012-01-04 07:57:22 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2012-01-04 07:57:22 -0800
commitf423fc627b05f47bc9305f9661630fce30f208f9 (patch)
treef2d9589bc443e99c8843a8ca18c44956d61fcf28 /fs
parent157e8bf8b4823bfcdefa6c1548002374b61f61df (diff)
downloadop-kernel-dev-f423fc627b05f47bc9305f9661630fce30f208f9.zip
op-kernel-dev-f423fc627b05f47bc9305f9661630fce30f208f9.tar.gz
Revert "rtc: Expire alarms after the time is set."
This reverts commit 93b2ec0128c431148b216b8f7337c1a52131ef03. The call to "schedule_work()" in rtc_initialize_alarm() happens too early, and can cause oopses at bootup Neil Brown explains why we do it: "If you set an alarm in the future, then shutdown and boot again after that time, then you will end up with a timer_queue node which is in the past. When this happens the queue gets stuck. That entry-in-the-past won't get removed until and interrupt happens and an interrupt won't happen because the RTC only triggers an interrupt when the alarm is "now". So you'll find that e.g. "hwclock" will always tell you that 'select' timed out. So we force the interrupt work to happen at the start just in case." and has a patch that convert it to do things in-process rather than with the worker thread, but right now it's too late to play around with this, so we just revert the patch that caused problems for now. Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Requested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Requested-by: John Stultz <john.stultz@linaro.org> Cc: Neil Brown <neilb@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud