>
> Am 30.08.2018 um 10:54 schrieb isdtor <isdtor@xxxxxxxxx>:
>
>>
>> Leon Fauster via CentOS writes:
>>> Since the update from kernel-2.6.32-754.2.1.el6.x86_64
>>> to kernel-2.6.32-754.3.5.el6.x86_64 I can not boot my
>>> KVM guests anymore!? The workstation panics immediately!
>>>
>>> I would not have expected this behavior now (last phase of OS).
>>> It was very robust until now (Optiplex Workstation). I see some KVM
>>> related lines in the changelog.diff. Before swimming upstream:
>>>
>>> Does some one have problems related to KVM with
>>> kernel-2.6.32-754.3.5.el6.x86_64 ??
>>
>> Yes, the exact same thing happened here, and I suspect it is related to
>> older cpus that don't get any Spectre/Meltdown updates.
>
>
> Thanks for the feedback. I' was assuming that some kind of
> Spectre/Meltdown fixes are causing this.
>
Doesn downgrading qemu as I proposed in the other mail fix it in your case?
I'm interested because in my case I'm having the issue on two older AMD
CPUs, not Intel.
>
>
>> IBM x3250
>> Intel(R) Xeon(R) CPU E3110 @ 3.00GHz
>>
>> This is a dual-core cpu of similar vintage to yours (can we have a model
>> #?), pre-2010.
>
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
> stepping : 11
> microcode : 186
> cpu MHz : 2000.000
> cache size : 4096 KB
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
> apicid : 1
> initial apicid : 1
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> 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 lm
> constant_tsc arch_perfmon pebs bts rep_good aperfmperf eagerfpu pni dtes64
> monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm pti
> retpoline tpr_shadow vnmi flexpriority
> bogomips : 5984.84
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
>
>
>
>
>> There goes a cheap and reliable VM dev machine :-/
>
>
> No way. Should all IT departments trash a big percentage of there hardware
> now?
I second that, I really hope this will be fixed.
Regards,
Simon
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
