[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: [PATCH] clocksource=tsc
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |