[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Xen 4 TSC problems
- To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
- From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
- Date: Mon, 19 Sep 2011 11:39:49 +0100
- Cc: Keir Fraser <keir@xxxxxxx>, jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Philippe Simonet <philippe.simonet@xxxxxxxxxx>, Konrad Wilk <konrad.wilk@xxxxxxxxxx>
- Delivery-date: Mon, 19 Sep 2011 03:40:46 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f6W7yAYAwESPBRu+TLyHRvsi2zMrWgF45jF8oh5oYMY=; b=fhmViw7BK4Qs9DQEEOJUliGZP9K5X4eEPT1W/lsRnsHz/Dqbi6wslbXuAdsDvtX4YG MbIxVt8amzqUE5cgLKvei31OGS2BYeAI69i342Uy5mqrW9FJNk9TXvL/+Gd6Bf1RIazk J9KtATqigwsLf1jgLOM3WkN/HKqYoaSstZhJg=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
On Thu, Sep 15, 2011 at 7:38 PM, Dan Magenheimer
>> I haven't been following this conversation, so I don't know if this is
>> relevant, but I've just discovered this morning that the TSC warp
>> check in Xen is done at the wrong time (before any secondary cpus are
>> brought up), and thus always returns warp=0. I've submitted a patch
>> to do the check after secondary CPUs are brought up; that should cause
>> Xen to do periodic synchronization of TSCs when there is drift.
> Wow, nice catch, George! I wonder if this is the underlying bug
> for many of the mysterious time problems that have been reported
> for a year or two now... at least on certain AMD boxes.
> Any idea when this was introduced? Or has it always been wrong?
Well the comment in 20823:89907dab1aef seems to indicate that's where
the "assume it's reliable on AMD until proven otherwise" started; that
would be January 2010.
I looked as far back as 20705:a74aca4b9386, and there the TSC
reliability checks were again in init_xen_time(). Figuring out where
things were before then is getting into archeology. :-)
The comment at the top of init_xen_time() is correct now, but from the
time it was first written through 4.1 is was just plain wrong -- it
said init_xen_time() happened after all cpus were up, which has never
Xen-devel mailing list