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

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

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