Re: [REGRESSION] rtc/interface.c: kills suspend-to-ram

From: Mark Lord
Date: Tue Apr 17 2012 - 16:11:33 EST

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at