similar to: centos-virt CPU microcode updates?

Not sure about CentOS 6, but this was covered previously (at least for 7...not sure how much they differ)...not that I can find the message now, but here's what I recall/pieced together from bash history that works on CentOS 7: If the microcode you want is in the microcode_ctl package: mkdir -p /etc/microcode_ctl/ucode_with_caveats/ touch /etc/microcode_ctl/ucode_with_caveats/force yum

On 5/16/19 2:12 AM, Karel Hendrych wrote: > Hi, > > is there any guide for CPU microcode updates on CentOS6, Xen 4.10, kernel 4.9 ? I'm not sure off the top of my head. You can add ucode=scan to the xen command line, add a file /path/to/microcode_file as the last item in your boot list, and generate that microcode file using something like: iucode_tool --write-earlyfw

Hi can someone say me how to update the ?code of the cpu with xen? I have added the ucode=scan parameter to xen but it does not seem to work... the ?code version of my xeon is really old :/ model name : Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz microcode : 0x10 -- ------ Greetz

it is working thx a lot... but it has included the GenuineIntel.bin only in actually used kernel... do I need to reinstall microcode_ctl every time I update the kernel? And second question, I quess I still need the ucode = scan as xen parameter right? Am 2018-09-19 20:08, schrieb Kevin Stange: > On 9/19/18 1:55 AM, Christoph wrote: >> >> Hi >> >> can someone say me

> > according to the documentation the option ucode=scan should tell XEN to > > look for a microcode update in an uncompressed initrd. > > > > While I don?t use the Debian kernel the tools to generate the initrd are > > part of Debian. The command ?cpio -i < /boot/initrd.img-4.0.2-Dom0? > > creates the directory structure

On 01/18/18 09:01, Johnny Hughes wrote: > On 01/18/2018 07:51 AM, Phelps, Matthew wrote: >> On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes <johnny at centos.org> wrote: >> >> So, if we applied the previous microcode update, and all our machines >> rebooted OK, then we don't need to fallback? >> >> Also, do we know if the updated CentOS microcode RPM

Once upon a time, Chris Murphy <lists at colorremedies.com> said: > "We recommend that OEMs, cloud service providers, system > manufacturers, software vendors and end users stop deployment of > current versions." Current versions of what? Microcode? Well, that's the only thing Intel provides for CPUs, so that's all it can be. > What these means for people who

Dear All, An update just brought on my CenOS 6 boxes updated microcode.dat files: /lib/firmware/microcode.dat Does anybody know off hand what (how critical) is that, as, if it is related to most famous these days trouble with CPU hardware, I will need to reboot relevant boxes to have new microcode loaded. But if it is not that critical, it can wait till next reboot. Thanks a lot and

On Thu, 2015-05-14 at 22:45 +0200, Stephan Seitz wrote: > On Wed, May 13, 2015 at 11:57:55AM -0400, Konrad Rzeszutek Wilk wrote: > >> > according to the documentation the option ucode=scan should tell XEN to > >> > look for a microcode update in an uncompressed initrd. > >> > > >> > While I don?t use the Debian kernel the tools to generate the

On 01/18/18 11:31, Matthew Miller wrote: > On Thu, Jan 18, 2018 at 11:01:18AM -0500, Pete Geenhuizen wrote: >> Do we update the microcode now or do we wait until the latest >> microcode_ctl rpm is available and then tackle this issue? > Check with your hardware vendor for BIOS/EFI firmware updates. Apply > those. > > > Thanks for the reply, but you missed what I was

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, This series adds a new microcode driver for Xen. The Xen hypervisor can deal with all the low-level details of doing a microcode update (Intel vs AMD, doing all the physical CPUs present on the system, current and future, etc), so all the driver has to do is make a hypercall to upload the microcode into Xen. This only

Hi! System: Debian/testing with selfcompiled kernel 3.5.5 (same error with 3.4 or 3.6) XEN: 4.1.3 After booting the Dom0 I notice the following errors: [ 2.939078] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa07 [ 2.991998] microcode: CPU0 update to revision 0xa0b failed [ 2.992035] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa07 [ 2.995882] microcode: CPU1 update to

On 9/19/18 1:55 AM, Christoph wrote: > > Hi > > can someone say me how to update the ?code of the cpu with xen? > > I have added the ucode=scan parameter to xen but it does not seem to > work... > > the ?code version of my xeon is really old :/ > > model name??? : Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz > microcode??? : 0x10 > There is a

/etc/init.d/microcode_ctl start /etc/init.d/microcode_ctl: microcode device /dev/cpu/microcode doesn't exist? This is on a clean install from the 4.1 x86 ISO. This is the 2nd box that is reporting this error. Adam Breaux Sr. Network Administrator Domain Bank, Inc. 23 W 4th St. Bethlehem, PA 18015 Phone: 610.317.9606 Fax: 610.317.9570 abreaux at domainbank.com

On Mon, Sep 07, 2015 at 05:47:39PM +0200, Karel Hendrych wrote: > ... > > changing from: <driver name='file'/> to: <driver name='tap2'/> makes > the domain start without QEMU. > > However I see much better performance with QEMU (close to dom0, > tested using simple dd writes) than with tap2 driver. Is that > expected? > How did you measure

Hi, spot on! On 6.9.2015 12:56, Pasi K?rkk?inen wrote: > On Sun, Sep 06, 2015 at 09:08:50AM +0200, Karel Hendrych wrote: >> Hi, after migrating to libvirt/libxl according to: >> > > Hi, > >> https://wiki.centos.org/HowTos/Xen/Xen4QuickStart/Xen4Libvirt >> >> I've noticed that my Xen PV domains are being launched by >> qemu-system-i386 running

On Sat, Sep 12, 2015 at 01:35:48AM +0200, Karel Hendrych wrote: > Comparing simple dd bs=1M count=10000 on dom0 vs domU. Qemu driver > is achieving pretty much the same like dom0. > So you're measuring buffered speed. Try measuring non-buffered (iflag=direct or oflag=direct, depending if you're reading or writing). -- Pasi > Thanks > -- > Karel > > On 7.9.2015

On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes <johnny at centos.org> wrote: > On 01/18/2018 03:41 AM, Pete Biggs wrote: > > > >> Look at: > >> > >> https://t.co/6fT61xgtGH > >> > >> Get the latest microcode.dat file from here: > >> > >> https://t.co/zPwagbeJFY > >> > >> See how to update the microcode

Hi, after migrating to libvirt/libxl according to: https://wiki.centos.org/HowTos/Xen/Xen4QuickStart/Xen4Libvirt I've noticed that my Xen PV domains are being launched by qemu-system-i386 running under root privileges. I am wondering why is this? Previously no qemu process was used. If qemu is needed for some reason, are there any guidelines for non-root operation? Thanks -- Karel

Add a simple function to ease the usage of Mkdtemp.mkdtemp. --- mllib/mkdtemp.ml | 5 +++++ mllib/mkdtemp.mli | 7 +++++++ 2 files changed, 12 insertions(+) diff --git a/mllib/mkdtemp.ml b/mllib/mkdtemp.ml index 2e64862..353b04b 100644 --- a/mllib/mkdtemp.ml +++ b/mllib/mkdtemp.ml @@ -16,4 +16,9 @@ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. *) +open Common_utils +