[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, 2015-06-10 at 12:48 +0100, Jan Beulich wrote:
> >>> On 10.06.15 at 13:01, <ian.campbell@xxxxxxxxxx> 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.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.