Microcode pushes and pulls

Every time I start my laptop, I get a firmware request from the kernel for /lib/firmware/intel-ucode/06-0f-0b for a microcode update. This fails, and no package provides it, but I would like to know why the kernel is requesting this. As far as I knew, all microcode is located in microcode.dat, and pushed from userspace to kernel using microcode_ctl, rather than the kernel requesting it itself. If I can’t find any explanation, I’ll just block all microcode requests in the client to avoid PackageKit users having searches automatically done for files that aren’t going to exist.

Help appreciated. Thanks.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

7 thoughts on “Microcode pushes and pulls”

  1. sprintf(name, “intel-ucode/%02x-%02x-%02x”,
    c->x86, c->x86_model, c->x86_mask);
    ret = request_firmware(&firmware, name, device);

    Looks like it’s trying to find a microcode file that exactly matches your CPU revision. That it then gives up and doesn’t try to load the generic microcode is kind of failing, I suppose.

  2. Something is calling request_microcode_fw from
    arch/x86/kernel/microcode_intel.c. I don’t know enough about the Linux kernel to find out what though.

  3. Given we always ship the latest firmware in the microcode_ctl package, it shouldn’t be a big deal to have pk ignore it. Though I realise, it’s more code on your part, and special cases suck.

    the /lib/firmware/microcode.dat is supposedly the ‘deprecated’ old-style firmware blob. Intel updated the driver to also handle the new-style one-file-per-cpuid firmware, and to date, hasn’t issued a single update in that format, but has done several updates continuing to use the old-style.

  4. What a pain. I have eeepc and I don’t know whether I should be using the userspace microcode update or not – it’s hard to tell whether it already has the most recent revision that can be applied…

  5. If the kernal is requesting the file, have you considered creating a virtual file to re-route the request? If you put a linear dynamic in the virtual file it should create a process which will satisfy the request.

  6. Creating a virtual file with a linear dynamic could leave the kernal open to a cyclical process which would reduce performance overall. Have you considered using a hexadec code in place of the usual? This might divert any erroneous requests and stop the request denial.

Comments are closed.