Comments on: Microcode pushes and pulls

By: Ben Castricum

Ben Castricum — Mon, 19 Jan 2009 06:35:56 +0000

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/

By: Vagisl

Vagisl — Sat, 17 Jan 2009 18:00:53 +0000

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.

By: Matt

Matt — Sat, 17 Jan 2009 17:43:35 +0000

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.

By: Anon

Anon — Tue, 13 Jan 2009 22:16:27 +0000

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…

By: davej

davej — Tue, 13 Jan 2009 17:20:27 +0000

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.

By: foo

foo — Tue, 13 Jan 2009 17:09:27 +0000

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.

By: ajax

ajax — Tue, 13 Jan 2009 16:57:20 +0000

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.