Paolo fixed the problem with upstream commit:
commit b6db4aca20e9af4f62c9c9e08b9b9672a6ed3390
Author: Paolo Bonzini <pbonz...@redhat.com>
Date: Mon Oct 1 14:22:06 2012 +0200
rtc: fix overflow in mktimegm
When setting a date in 1980, Linux is actually disregarding the century
byte and setting the year to 2080. This causes a year-2038 overflow
in mktimegm. Fix this by doing the days-to-seconds computation in
64-bit math.
Reported-by: Lucas Meneghel Rodrigues <look...@gmail.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Anthony Liguori <aligu...@us.ibm.com>
Confirmed that problem is solved. Closing bug.
** Changed in: qemu
Status: New => Confirmed
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1058225
Title:
When setting hardware clock on linux guest, hwclock shows crazy date
(in the year 2043)
Status in QEMU:
Fix Committed
Bug description:
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'")
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1058225/+subscriptions
