Distribution: Debian Hardware Environment: HP Compaq nx7300 Problem Description: As summary suggests, after using the rtc as a periodic timer once and then suspending to ram, the periodic timer ceases to work -- mplayer just hangs waiting for data on the rtc fd. aireplay-ng has the same behvaiour. Steps to reproduce: 1. mplayer -rtc -rtc-device /dev/rtc0 file.avi 2. s2ram 3. mplayer -rtc -rtc-device /dev/rtc0 file.avi /proc/driver/rtc looks like this regardless of whether mplayer is running or not: rtc_time : 13:34:36 rtc_date : 2008-07-07 alrm_time : 15:02:56 alrm_date : ****-**-** alarm_IRQ : no alrm_pending : no 24hr : yes periodic_IRQ : no update_IRQ : no HPET_emulated : yes DST_enable : no periodic_freq : 1024 batt_status : okay Having it as a module and doing rmmod/modprobe makes it work again, so that's a workaround. I'm attaching a dmesg with a few suspends and rmmod/modprobes, but there are no messages about the breakage -- just for the details of my machine and configuration. This did work with 2.6.25 and the old RTC code which is now removed. For details, see the attached .configs.
Created attachment 16761 [details] dmesg
Created attachment 16762 [details] nonworking .config
Created attachment 16763 [details] working .config
Hmm, using "rtctest" (from Documentation/rtc.txt) on a machine which also has the HPET emulation going on, I was unable to reproduce this. Could you try reproducing it using that test program? Looking at the dmesg outputs, nothing looked particularly odd except the "rtc: lost 1 interrupts" message. That came from arch/x86/kernel/hpet.c (hence the text is misleading: it should maybe say "hpet: lost 1 rtc interrupt") where hpet_rtc_timer_reinit() got called ... it looks like the problem is coupled to the HPET emulation having goofed up the state of the IRQ flags. Someone who knows the HPET stuff should look at this. I observe that neither the cmos_irq_set_state() nor cmos_suspend()/cmos_resume() methods were ever taught anything about HPET; maybe that's the root cause here. The fact that cmos_procfs() wasn't taught about it explains why the /proc/driver/rtc file never reports the right value for the periodic_IRQ or update_IRQ fields; easily observed while runing "rtctest". The HPET glue seems to be missing a way to query the emulated IRQ flags. Another HPET-unaware routine is cmos_do_shutdown().
Created attachment 16800 [details] update rtc-cmos to use HPET glue more consistently I'll be trying this patch in a while; as its description says, it basically tightens up the handling of the emulated RTC stuff. There were several small holes in that handling, some of which might have caused problems like this.
Well, this patch fixed the problem for me, thanks. Btw, as it corrected the output of /proc/driver/rtc, I noticed that after running mplayer once, the periodic_IRQ stays up forever (even after resume). Maybe that's the reason for those lost interrupts?
Created attachment 16829 [details] updated hpet-glue patch this version passed sanity testing on one machine with hpet
Yeah, this new patch works as well. I digged into the problem I mentioned in comment #6 a bit and found that the old rtc driver did turn off all irqs in the rtc_release function, but neither rtc-cmos nor rtc-dev does so. The UIE emulation in rtc-dev does turn off UIE in the release function and so other drivers like rtc-sh or rtc-bfin also turn off their interrupts. So, I guess we should add a release op to rtc-cmos and clear the interrupts there. Now, if the application does not explicitly set PIE off, the interrupts keep firing (verified with powertop) forever, even after resume.
Thanks for the testing, I'll probably submit this today. The "leave IRQs enabled" bug is a separate issue, which I think should be addressed within the RTC framework ... drivers shouldn't need to work around that stuff.
Ok, fine. I'll open a bug for that and possibly try to code some patches.
patch sent to lkml and merged into MM for 2.6.27 ... it's not quite either version attached to this bugreport. Candidate for stable series.