Messages in this thread | | | Date | Tue, 17 Apr 2012 16:11:32 -0400 | From | Mark Lord <> | Subject | Re: [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
| |