From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulanit Subject: Re: Time Skewing on Windows XP Date: Thu, 14 Mar 2013 11:21:35 -0500 Message-ID: <5141F90F.6060408@amd.com> References: <513EB1BC.9050803@amd.com> <513EEF5102000078000C4C89@nat28.tlf.novell.com> <5141E9CB.9020608@amd.com> <514203A502000078000C59E2@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <514203A502000078000C59E2@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George.Dunlap@eu.citrix.com, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 3/14/2013 11:06 AM, Jan Beulich wrote: >>>> On 14.03.13 at 16:16, Suravee Suthikulanit wrote: >> I finally traced the issue back to the patch that this first happened. This >> bug started in the patch : >> >> H86/HVM: assorted RTC emulation adjustment (w/ git commit id >> 620d5dad54008e40798c4a0c4322aef274c36fa3) >> >> I believe there are some issues with the changes in rtc_ioport_read in the >> arch/x86/hvm/rtc.c and in the pt_update_irq(). > One thing you may want to try is remove the call from REG_C > read to rtc_timer_update() again - on a second thought it may > be wrong to do it here, as (other than check_update_timer() > and alarm_timer_update()) the function doesn't change with > RTC_PF getting cleared (i.e. I may have wrongly added the call > in analogy to the other two). If I do the followings, things start working again: 1. remove the rtc_timer_update() in the rtc_ioport_read() 2. Revert back the "rtc_periodic_cb()" and remove the "rtc_periodic_interrupt()" What was the purpose of changing the "rtc_periodic_cb()" to "rtc_periodic_interrupt()" ? Suravee > I would expect the issue to be that create_periodic_time() > pointlessly destroys and then recreates an identical rate timer. > > I'm puzzled though that some Windows versions depend on > the RTC to maintain their wall clock time... > > Jan > >