WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Test results on Unisys ES7000 64x 256gb using unstablec/

To: Bill Burns <bburns@xxxxxxxxxx>
Subject: Re: [Xen-devel] Test results on Unisys ES7000 64x 256gb using unstablec/s 16693 on 3.2.0 Release Candidate
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 30 Jan 2008 16:45:46 +0000
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Carb, Brian A" <Brian.Carb@xxxxxxxxxx>
Delivery-date: Wed, 30 Jan 2008 08:46:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47A0A3D8.4080103@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchjX492zkZ6/c9SEdyG4gAX8io7RQ==
Thread-topic: [Xen-devel] Test results on Unisys ES7000 64x 256gb using unstablec/s 16693 on 3.2.0 Release Candidate
User-agent: Microsoft-Entourage/11.3.6.070618
On 30/1/08 16:20, "Bill Burns" <bburns@xxxxxxxxxx> wrote:

> Until we get to scrubing free ram:
> 
> (XEN) Initrd len 0x894600, start at 0xffffffff80702000
> (XEN) Scrubbing Free RAM: ---0: 80000000 498c0b61 -2
> (XEN) .done.

That error factor (0x80000000) is as bad as it possibly can be. This means
that local_stime is running at least one second ahead of master_stime.
Probably the platform timer (which is used to compute master_stime) has gone
mad. In this case of course the platform timer is the ACPI PM timer.

I suggest instrumenting read_pmtimer_count() to see what value is getting
returned from there, to ensure it is monotonically increasing at about the
right rate. And also that it *is* actually getting invoked!

 -- Keir



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

<Prev in Thread] Current Thread [Next in Thread>