According to that bug, rtc gets borked if the system hibernated. So the sequence of events that may cause this is:
- Due to whitelist ordering, the system hibernates before running rtc.
- Tests are run twice. Thus, the hibernate test from the first test run borks rtc, and the second rtc run will fail.
I'll try to reproduce this a bit more, but we can try to ensure that this rtc test comes early in the whitelist and be aware that due to a kernel bug, it can't work if the system has hibernated in the past.
This problem in itself is not that bad, the main issue is that the suspend tests depend on this, so they often get blocked.
This problem is intermittent; I haven't seen any reports recently but I was reviewing some old submissions and they do have it.
We could remove the suspend test dependency on this,
Looks like a dupe of: https:/ /bugs.launchpad .net/fwts/ +bug/1333569
According to that bug, rtc gets borked if the system hibernated. So the sequence of events that may cause this is:
- Due to whitelist ordering, the system hibernates before running rtc.
- Tests are run twice. Thus, the hibernate test from the first test run borks rtc, and the second rtc run will fail.
I'll try to reproduce this a bit more, but we can try to ensure that this rtc test comes early in the whitelist and be aware that due to a kernel bug, it can't work if the system has hibernated in the past.