[CentOS] Panic / EL6 / KVM / kernel-2.6.32-754.2.1.el6.x86_64

Simon Matter simon.matter at invoca.ch
Thu Aug 30 10:05:46 UTC 2018


>
> Am 30.08.2018 um 10:54 schrieb isdtor <isdtor at gmail.com>:
>
>>
>> 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




More information about the CentOS mailing list