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

[Mauro <mrsanna1@xxxxxxxxx>]

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:
>>>>>> On 15.10.12 at 13:24, Mauro <mrsanna1@xxxxxxxxx> wrote:
>>>> I have the problem on this hardware type:
>>>>
>>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>>> It seem that
>>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>>> put in in /etc/default/grup (I use linux debian)
>>>> solves the problem for me.
>>>
>>> Did you check whether either or both options on their own also
>>> make the problem go away?
>>
>> It seems that with debian squeeze on my HP Proliant Dl 580 G5 servers
>> is sufficient to use
>> GRUB_CMDLINE_XEN="cpuidle=0".
>> Is from about 20 days that I have no clock jumps.
>> Before I had a clock jump every week.
>> Hope this is the final workaround for me.
>
> 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

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.

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