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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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