WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] clocksource=tsc

To: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] clocksource=tsc
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 16 Jul 2008 13:49:59 +0100
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Wed, 16 Jul 2008 05:50:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080716064349109.00000080236@djm-pc>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjkZ5sqwfzsRK8bRLOogZ+uDOy+agBK8Gg8AAvqplAALhkLxQADB+XQAAFG8VoAATgKoAAAlQPwABMp4zAABk1eMAARsq0wAAB8cZg=
Thread-topic: [PATCH] clocksource=tsc
User-agent: Microsoft-Entourage/11.4.0.080122
That's a weird set of symptoms. Perhaps dom0's sense of system time is
diverging from Xen's? I don't see that CPUs can diverge, if their TSCs are
in sync, since we shouldn't be dynamically modifying the per-CPU timestamps
or scale factors.

 -- Keir

On 16/7/08 13:43, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> Well now I have to take that back.  It DOESN'T work yet.
> I think I am experiencing "Weirdness can happen..."
> when booting with clocksource=tsc... I was away from
> the machine overnight but the symptoms I've seen before
> are that the system becomes less snappy and eventually
> grinds to a near-halt.
> 
> Oddly, I can login most of the way on the console
> and launch new xterm's in my VNC display, but I never
> get a prompt, and I can't interrupt a process I left
> running overnight in another xterm.  The time display
> in gnome seems to have frozen about an hour after
> I booted.  Pinging the machine works but ssh'ing to
> it doesn't ("Connection closed")
> 
>> -----Original Message-----
>> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
>> Sent: Tuesday, July 15, 2008 10:12 PM
>> To: 'dan.magenheimer@xxxxxxxxxx'; 'Keir Fraser'; 'Xen-Devel (E-mail)'
>> Cc: 'Dave Winchell'
>> Subject: RE: [PATCH] clocksource=tsc
>> 
>> 
>> OK, ignore that.  It looks like you have it all fixed
>> in 18060.  I tried it and it now boots.  Thanks!
>> 
>>> -----Original Message-----
>>> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
>>> Sent: Tuesday, July 15, 2008 7:16 PM
>>> To: 'dan.magenheimer@xxxxxxxxxx'; 'Keir Fraser'; 'Xen-Devel
>> (E-mail)'
>>> Cc: 'Dave Winchell'
>>> Subject: RE: [PATCH] clocksource=tsc
>>> 
>>> 
>>>>>> Returning to 32-bit read_counter(), and having NULL
>>>>> read_counter when
>>>>>> clocksource=tsc would be another possibility...
>>> 
>>> Well I hacked on 18055 for awhile and just couldn't get it
>>> to boot.  I think local_time_calibration() (and thus
>>> init_percpu_time()) is necessary for boot, though I'm not really
>>> sure why.  Possibly the "Weirdness can happen..." comment in
>>> that routine?
>>> 
>>> Anyway, this patch (on top of 18055) DOES work, returns to the
>>> 32-bit read_counter, and re-enables local_time_calibration().
>>> I'd suggest putting off more major surgery for another day.
>>> 
>>> Thanks,
>>> Dan
>>> 
>>>> -----Original Message-----
>>>> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
>>>> Sent: Tuesday, July 15, 2008 10:04 AM
>>>> To: dan.magenheimer@xxxxxxxxxx; Keir Fraser; Xen-Devel (E-mail)
>>>> Cc: Dave Winchell
>>>> Subject: RE: [PATCH] clocksource=tsc
>>>> 
>>>> 
>>>> Hmmm... 18055 also fails to boot on my machine.
>>>> 
>>>> Could we perhaps fall back to my original patch and do
>>>> cleanup later/separately?  I also want to try implementing
>>>> an hpet64-based get_s_time() so will be working more
>>>> in this code later... but want to get clocksource=tsc
>>>> working now with minimal code impact given the freeze.
>>>> 
>>>>> -----Original Message-----
>>>>> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
>>>>> Sent: Tuesday, July 15, 2008 9:46 AM
>>>>> To: 'Keir Fraser'; 'Xen-Devel (E-mail)'
>>>>> Cc: 'Dave Winchell'
>>>>> Subject: RE: [PATCH] clocksource=tsc
>>>>> 
>>>>>> Actually in this mode of operation we hardly need a platform
>>>>>> timer *at all*.
>>>>>> The idea is that we let the TSCs free-run, because we know
>>>>>> they will behave.
>>>>>> Returning to 32-bit read_counter(), and having NULL
>>>>> read_counter when
>>>>>> clocksource=tsc would be another possibility...
>>>>> 
>>>>> That's essentially what the original tscstable.patch did, though
>>>>> I was perhaps much uglier in the miscellaneous parts.
>>>>> 
>>>>> Thanks,
>>>>> Dan
>>>>> 
>>>> 
>>>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel