[ovirt-users] 3.5.1 not detecting Haswell CPU

[Francesco Romani]

----- Original Message -----
> From: "Blaster" <Blaster at 556nato.com>
> To: users at ovirt.org
> Sent: Monday, February 23, 2015 5:43:17 AM
> Subject: [ovirt-users] 3.5.1 not detecting Haswell CPU

Hi,
 
> I just upgraded from a working 3.5.0 on F20 to 3.5.1.  After the
> upgrade, 3.5.1 started detecting my i7-4790k as a Sandy Bridge, and not
> the Haswell it properly detected with 3.5.0.  I had to force the CPU
> type to Sandy Bridge in order to bring the node up.
> 
>   vdsClient -s 0 getVdsCaps | grep cpu
>          cpuCores = '4'
>          cpuFlags =
> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,fma,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,abm,ida,arat,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,tsc_adjust,bmi1,hle,avx2,smep,bmi2,erms,invpcid,rtm,xsaveopt,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_Westmere,model_n270,model_SandyBridge'
>          cpuModel = 'Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz'
>          cpuSockets = '1'
>          cpuSpeed = '4300.000'
>          cpuThreads = '8'
>          numaNodes = {'0': {'cpus': [0, 1, 2, 3, 4, 5, 6, 7],
> 'totalMemory': '32022'}}
> 
> # cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 60
> model name      : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
> stepping        : 3
> microcode       : 0x1c
> cpu MHz         : 4299.843
> cache size      : 8192 KB
> physical id     : 0
> siblings        : 8
> core id         : 0
> cpu cores       : 4
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 13
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
> nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64
> monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2
> x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm
> abm ida arat pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
> fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt
> bugs            :
> bogomips        : 7999.90
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 39 bits physical, 48 bits virtual
> power management:

I have vague memories of similar bugs in the past. Can you please share
the libvirt debug logs of one hypervisor host which has this misbehaviour?

Bests,

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani