Re: [Qemu-devel] [Bug 1058225] [NEW] When setting hardware clock on linux guest, hwclock shows crazy date (in the year 2043)

[Paolo Bonzini <pbonzini@redhat.com>]

Il 28/09/2012 19:21, Lucas Meneghel Rodrigues ha scritto:
> Public bug reported:
> 
> 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'")

I can reproduce this with qtest.

The test is bogus.  Linux (drivers/rtc/rtc-cmos.c) doesn't set the
century byte, so it may fail if you set a date that is before 2000.
Setting a date in 2011 works.

However, there is of course a bug, which was latent so far and made
visible by the recent algorithmic changes for the RTC.  The strange date
arises because you actually set the date to 2080.  mktimegm (in
cutils.c) has an year-2038 overflow.  I'll send a patchset to fix this
and implement the century byte correctly.

Paolo