[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |