Re: [Qemu-devel] [Bug 1334397] [NEW] cmos RTC alarms no longer wake system from suspend

[Paolo Bonzini]

Il 25/06/2014 20:39, John Stultz ha scritto:
> Public bug reported:
>
> Running QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1),
> booting Linux kernels with qemu-system-x86_64 and qemu-system-i386, I no
> longer see the system resume from suspend when an RTC alarm is set.
>
> My simple test application can be found here:
> https://github.com/johnstultz-work/timetests/blob/master/alarmtimer-suspend.c
>
> Previously this worked w/ QEMU 1.5  (bascially up until I upgraded from
> Ubuntu 13.10 to Ubuntu 14.04, which came with 2.0).

Hi John,

I tried instrumenting QEMU and it looks like the RTC emulation is working:

cmos: write index=0x0b val=0x02
 cur 19:53:10 alarm 0:0:0
 next  alarm 14810
 cur 19:53:10 alarm 0:0:0
 next  alarm 14810
cmos: write index=0x05 val=0x19
 cur 19:53:10 alarm 19:0:0
 next  alarm 83210
cmos: write index=0x03 val=0x53
 cur 19:53:10 alarm 19:53:0
 next  alarm 86390
cmos: write index=0x01 val=0x24
 cur 19:53:10 alarm 19:53:24
 next  alarm 14
cmos: write index=0x0b val=0x22
 cur 19:53:10 alarm 19:53:24
 next  alarm 14
cmos: write index=0x0b val=0x22
 cur 19:53:10 alarm 19:53:24
 next  alarm 14
 cur 19:53:11 alarm 19:53:24
 next  alarm 13
alarm 22
 cur 19:53:24 alarm 19:53:24
 next  alarm 86400
RTC wakeup!
cmos: write index=0x0f val=0x00
cmos: write index=0x0b val=0x22
 cur 19:53:24 alarm 19:53:24
 next  alarm 86400
cmos: write index=0x0b val=0x02
 cur 19:53:24 alarm 19:53:24
 next  alarm 86400
cmos: write index=0x0b val=0x02
 cur 19:53:24 alarm 19:53:24
 next  alarm 86400
 cur 19:53:25 alarm 19:53:24
 next  alarm 86399
cmos: write index=0x0b val=0x02
 cur 19:53:25 alarm 19:53:24
 next  alarm 86399
 cur 19:53:25 alarm 19:53:24
 next  alarm 86399
cmos: write index=0x05 val=0x19
 cur 19:53:25 alarm 19:53:24
 next  alarm 86399
cmos: write index=0x03 val=0x53
 cur 19:53:25 alarm 19:53:24
 next  alarm 86399
cmos: write index=0x01 val=0x39
 cur 19:53:25 alarm 19:53:39
 next  alarm 14
cmos: write index=0x0b val=0x22
 cur 19:53:25 alarm 19:53:39
 next  alarm 14
cmos: write index=0x0b val=0x22
 cur 19:53:25 alarm 19:53:39
 next  alarm 14
 cur 19:53:26 alarm 19:53:39
 next  alarm 13
alarm 22
 cur 19:53:39 alarm 19:53:39
 next  alarm 86400
RTC wakeup!
cmos: write index=0x0f val=0x00
cmos: write index=0x0b val=0x22
 cur 19:53:39 alarm 19:53:39
 next  alarm 86400
cmos: write index=0x0b val=0x02
 cur 19:53:39 alarm 19:53:39
 next  alarm 86400
cmos: write index=0x0b val=0x02
 cur 19:53:39 alarm 19:53:39
 next  alarm 86400
 cur 19:53:40 alarm 19:53:39
 next  alarm 86399
cmos: write index=0x0b val=0x02
 cur 19:53:40 alarm 19:53:39
 next  alarm 86399
 cur 19:53:40 alarm 19:53:39
 next  alarm 86399
cmos: write index=0x05 val=0x19
 cur 19:53:40 alarm 19:53:39
 next  alarm 86399
cmos: write index=0x03 val=0x53
 cur 19:53:40 alarm 19:53:39
 next  alarm 86399
cmos: write index=0x01 val=0x54
 cur 19:53:40 alarm 19:53:54
 next  alarm 14
cmos: write index=0x0b val=0x22
 cur 19:53:40 alarm 19:53:54
 next  alarm 14

The only way to have the CMOS updated is from the guest, so the guest is 
resumed.  The "RTC wakeup!" also is just before setting the 
RT_CLOCK_STATUS field in the ACPI PM1A event status register.

However, I can reproduce that the system looks indeed like it's crashed 
and I don't see neither the resumption nor the printf from the 
sigalarm() function.  This is on kernel 3.11.10.

Also, I see that register C (the current interrupt) is always read as zero.

Right now I don't have an older QEMU, but I'll look at it tomorrow.

Paolo