| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Test results on Unisys ES7000 64x 256gb using unstablec/
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.
Bill
> -- Keir
>
>
--- xen/arch/x86/genapic/es7000plat.c.orig 2007-12-06 12:48:38.000000000
-0500
+++ 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
es7000_sw_apic()
{
+ /* 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home