RE: [Xen-devel] Xen 4 TSC problems

[<Philippe.Simonet@xxxxxxxxxxxx>]

Hi Xen developpers

i need some good tips to go forward with my TSC problem : 

first fast the problem : 

- clock jump 50 minutes forward : (xm dmesg)
        (XEN) TSC is reliable, synchronization unnecessary
        (XEN) Platform timer is 14.318MHz HPET
        (XEN)  Platform timer appears to have unexpectedly wrapped 10 or more 
times

        (syslog)
        Sep 28 17:45:06 dnsit11 kernel: [1970548.356130] Clocksource tsc 
unstable (delta = -2999660112689 ns)
        Sep 11 13:56:50 dnsit22 kernel: [571603.359863] Clocksource tsc 
unstable (delta = -2999662111513 ns)

- I can't reproduce or force the problem

- on 2 different HP DL 385 G7,  with debian squeeze : 
        xen-hypervisor-4.0-amd64                4.0.1-2
        dom0 : linux-image-2.6.32-5-xen-amd64          2.6.32-35
        domus : 5 -> 15 debian machines
        2 * 12-cores AMD Opteron(tm) Processor 6174

- i have this problem since begin of september, before, the machine were 
running since 3 month without problem
        begin of September,  I have done an upgrade (dom0 and domus:)
        linux-image-2.6.32-5-xen-amd64:amd64 (2.6.32-31, automatic)  -> 
linux-image-2.6.32-5-xen-amd64:amd64 (2.6.32-31, 2.6.32-35)

- what is strange : (don't know if there is a link with the problem)
        /proc/cpuinfo in dom0 gives me : 

        cpu MHz         : 3249880.888
  --or --
        cpu MHz         : 2300454.255
....            (different after each reboot)
        
        in domu thi value is ok(cpu MHz         : 2200.112), the bogomips is 
also ok (bogomips        : 4400.21)
        if I start the machine with a non-xen environment, the values are also 
ok
        
I have now exact the same machine where I can make some tests.

Could you give me some tips that I could test or implement ?
        - hardware problem ? hypervisor problem ? dom0 problem ?
        - try other hypervisor version ? 
        - try linux-image-3.0.0-1-amd64 3.0.0-3
        - try reproducing problem ? (how ?, log it ? ....)

all your help is welcomed !

many thanks

Philippe





> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of George Dunlap
> Sent: Monday, September 19, 2011 12:40 PM
> To: Dan Magenheimer
> Cc: Keir Fraser; jeremy@xxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx; Philippe
> Simonet; Konrad Wilk
> Subject: Re: [Xen-devel] Xen 4 TSC problems
> 
> On Thu, Sep 15, 2011 at 7:38 PM, Dan Magenheimer
> <dan.magenheimer@xxxxxxxxxx> wrote:
> >> 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 been true.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

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