Re: [xen-unstable test] 57852: regressions - FAIL

[Ian Campbell <ian.campbell@citrix.com>]

On Wed, 2015-06-10 at 12:48 +0100, Jan Beulich wrote:
> >>> On 10.06.15 at 13:01, <ian.campbell@citrix.com> wrote:
> > On Wed, 2015-06-10 at 10:36 +0100, Jan Beulich wrote:
> >> Indeed. Leaving us with the slight hope that there is a microcode
> >> update available that's newer than what the BIOS of those boxes
> >> loads. Could we perhaps afford un-blessing the two systems for
> >> the time being? And maybe get Intel involved if there's no ucode
> >> update available that helps?
> > 
> > Arranging to do microcode updates looks like it is going to be a bit
> > non-trivial from the osstest side. Is there any reason to think it would
> > help other than just hoping it will?
> 
> It's really hope, not much more.

OK. I think this is something which is worth doing but I'm going to
treat it more like a feature request than a bug fix in terms of
prioritising it.

>  But I guess you could at least check
> what microcode the box has in use - if there's nothing newer available,
> then trying to get the microcode updating working isn't of immediate
> importance anymore (but of course it would still be nice to have in
> place).

I logged into fiano1 while it was running under Xen:

cpuinfo contains (just the first processor for brevity):

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 62
model name	: Intel(R) Xeon(R) CPU E5-2403 v2 @ 1.80GHz
stepping	: 4
microcode	: 0x416
cpu MHz		: 1800.041
cache size	: 10240 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht nx constant_tsc nonstop_tsc eagerfpu pni pclmulqdq monitor est ssse3 sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor arat epb xsaveopt pln pts dtherm fsgsbase erms
bogomips	: 3600.08
clflush size	: 64
cache_alignment	: 64
address sizes	: 46 bits physical, 48 bits virtual
power management:

I'll hold onto the machine for another hour (until 1500 BST) if you want
to know anything else (otherwise I'll have to relock it which will imply
waiting for a test to finish)

> > Can't we get Intel involved right away?
> 
> Sure we can; I just generally prefer not to bother people with
> problems they already solved, but maybe that's the wrong approach
> a case like this.

Is the list of errata fixed by a given ucode update public? If not then
I think we've done sufficient due diligence that we should feel ok to
ask, even if the answer turns out to be fixed in microcode.

Ian.