Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.10.12 at 11:17, Mauro <mrsanna1@xxxxxxxxx> wrote:
> On 22 October 2012 08:54, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 21.10.12 at 22:52, Mauro <mrsanna1@xxxxxxxxx> wrote:
>>> On 15 October 2012 14:49, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> So what's the contents of /proc/cpuinfo (any one CPU suffices)
>> under a native recent kernel on that system? The most likely
>> issue here is that we're mis-identifying the CPU as having an
>> always running APIC timer (ARAT)...
> 
> uname -a
> 
> Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
> x86_64 GNU/Linux

I had specifically asked to do this under a _native_ kernel.

> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
> stepping        : 11
> cpu MHz         : 2400.176
> cache size      : 3072 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov
> pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc
> rep_good aperfmperf pni est ssse3 cx16 hypervisor lahf_lm
> bogomips        : 4800.35
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> 
>>
>> For a second, less intrusive try: Could you replace "cpuidle=0"
>> with "max_cstate=1" (assuming the former didn't meanwhile
>> turn out not to cure the problem)? If that works too (expected),
>> try "max_cstate=2" followed eventually by
>> "max_cstate=2 local_apic_timer_c2_ok".
> 
> I'll try but to say that it works I've to wait at least two weeks.

I understand that this takes quite a bit of time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel