> Very easy to reproduce:
>
> 1) Build the latest qemu.git (we've captured this on internal automated
> testing, verified manually), the commit for reference is:
>
> 14:07:02 INFO | git commit ID is
> 6f8fd2530e9a530f237240daf1c981fa5df7f978 (tag v1.2.0-461-g6f8fd25)
>
> 2) Install a linux guest in it (caught with RHEL 6.2, verified with
> Fedora 17)
>
> 3) In the linux guest, set the hardware clock with hwclock:
>
> /sbin/hwclock --set --date "2/2/80 03:04:00"
>
> 4) Verify if hardware clock was set back to the eighties:
>
> LC_ALL=C /sbin/hwclock
>
> 5) Observe amazed that hwclock reports a date in the year 2043:
>
> 14:09:34 INFO | ('hwclock', 'FAIL', 2, "Failed to set hwclock
> back to the eighties. Output of hwclock is 'Sun Dec 27 20:35:46 2043
> -0.489664 seconds'")
The testcase of patch 1 exposes the bug on an unpatched QEMU.
Paolo
Paolo Bonzini (3):
rtc: fix overflow in mktimegm
rtc: map CMOS index 0x37 to 0x32 on read and writes
rtc: implement century byte
cutils.c | 2 +-
hw/mc146818rtc.c | 40 ++++++++++++++++++----------
hw/mc146818rtc_regs.h | 4 +++
tests/rtc-test.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++
4 file modificati, 104 inserzioni(+), 15 rimozioni(-)
--
1.7.12
