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.
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.
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.
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.
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…
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.
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.
The new intel-ucode firmware based updates are very poorly documented. To get it working you need to have the microcode.dat file split up into CPU specific updates. This may be of some help : http://www.bencastricum.nl/linux/