lkml.org 
[lkml]   [2012]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [REGRESSION] rtc/interface.c: kills suspend-to-ram
On 12-04-17 01:13 AM, John Stultz wrote:
..
> - rtc->ops->alarm_irq_enable(rtc->dev.parent, false);
> + //rtc->ops->alarm_irq_enable(rtc->dev.parent, false);
> + dump_stack();
..

Okay, the call into here is coming from a "hwclock -w -u" line
in the system suspend script.

Since that command isn't touching the hardware Alarm,
then neither should the Linux kernel. Yet it is touching it.

> 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);
...

The problem still occurs (lockup on suspend)
with both lines above commented out.

Note that it's not 100% in any case, more like 8/10,
indicating a possible strong race condition somewhere.

I think all that should be done here, is to change the kernel
to NOT enable/disable the Alarm unless told to do so by
an explicit userspace action. Eg. writing to /sys/../wakealarm
and/or /proc/acpi/alarm.

If userspace leaves the alarm alone, then so should the kernel when possible.
That's the old behaviour before the new alarm_irq_enable() stuff.

Cheers


\
 
 \ /
  Last update: 2012-04-18 22:37    [W:0.080 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site