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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
