Comment 2 for bug 571977

Ugh... this is what I get for writing kernel bugs late in the evening... :( Please see the following changes to my original narrative below:

"I'm working on a test script that sets a time in the future in /sys/class/rtc/rtc0/wakealarm and then uses pm-suspend to hibernate a system. I believe I've found a race condition that's causing my tests to fail."

That should have said that I am using pm-hibernate to put the system into S4. I use pm-suspend to put the system into S3.

"The test, when putting the system into an S3 state, does not suffer from this issue. It DOES when I'm using S4. I think the reason is that S3 wakes quickly enough that the kernel can register that the alarm fired and reset /proc/driver/rtc accordingly, however, when waking from suspend, the kernel takes far longer to wake, causing it to think that even though the rtc's alarm_IRQ fired the IRQ didn't fire, so the kernel does not reset /proc/driver/rtc."

That should have said ". . . however, when waking from HIBERNATE, the kernel takes far longer to wake, causing it to think that the rtc's alarm IRQ never fired (even though it did), so the kernel never updates /proc/driver/rtc to reflect this in the alarm_IRQ entry."

And additionally, "because of this, subsequent setting of /sys/class/rtc/rtc0/wakealarm will fail without first clearing it with a '0' and if a piece of software is actually looking to see if the RTC fired it's alarm_IRQ, that software will believe that the IRQ has not been fired due to /driver/proc/rtc incorrectly reporting the event."

should have said /proc/driver/rtc, NOT /driver/proc/rtc. SIgh... yesterday was a long and draining day :(