[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Test results on Unisys ES7000 64x 256gb using unstablec/s 16693 on 3.2.0 Release Candidate

Keir Fraser wrote:
> 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!

I instrumented read_pmtimer_count and it does get called a couple
of times during startup and it returns an increasing value. I made
no attempt to determine if the rate was correct.

I also tried the 3.1.3 and 3.2.0 Hypervisors and they exhibit
the same problem on the es7000.

It's not clear if is this a platform specific problem
or not. So far the only reports of the problem are on the
es7000. So for now I am running the attached patch to
avoid the pmtimer on es7000 only.


>  -- Keir

--- xen/arch/x86/genapic/es7000plat.c.orig      2007-12-06 12:48:38.000000000 
+++ xen/arch/x86/genapic/es7000plat.c   2008-01-31 11:56:30.000000000 -0500
@@ -296,9 +296,14 @@ es7000_stop_cpu(int cpu)
+extern u32 pmtmr_ioport;
 void __init
+       /* don't use pmtimer on es7000 */
+       pmtmr_ioport = 0;
        if (es7000_plat && (es7000_plat != ES7000_ZORRO)) {
                int mip_status;
                struct mip_reg es7000_mip_reg;
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.