I have some i7-4700EQ based embedded server systems that require hyperthreading. All is good except that, on rare occasions, the hyperthreading flag in CMOS gets set to disabled. While the hardware is still in my possession, I can simply reboot, go into CMOS and fix the setting. (All other settings in CMOS stay good including the time/date so I'm thinking it isn't the battery.)

However, once deployed, there is no console access. If the CMOS setting is lost, the equipment could be "repaired" but that seems like a great deal of work for a very simple problem.

My understanding is that the Linux kernel reads the BIOS only to initialize kernel variables. Is that correct?

If that is correct, is there a way to tell the Linux kernel to ignore what the BIOS reports and simply enable hyperthreading in the kernel?

If possible, is there an easy way (eg grub command line setting) to do this? Else if possible but difficult, can ignoring what the BIOS says and enabling hyperthreading be accomplished by modifying kernel source and recompiling?

While I didn't think it would work, I already tried in /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash maxcpus=8 nr_cpus=8"

followed with using update-grub and rebooting. (I also tried setting maxcpus and nr_cpus individually.)

I have found numerous examples of disabling hyperthreading on a running system and then re-enabling it. But not examples of enabling if the kernel incorrectly thinks a human intentionally disabled hyperthreading.

Finally, I could claim "broken hardware" but that isn't going to win any "wars" on its own. If it is not possible to force hyperthreading to be enabled despite the BIOS, that is a valid answer - and the answer will be useful to me if it includes evidence / explanations why.


This is not entirely true as a general rule.

Example 1: SMI firmware (aka BIOS) interrupt handlers still run after the kernel is booted, at a higher level of privilege than the kernel. You are welcome to try and fight SMM; don't expect Linux to be particularly interested in helping you.

Example 2: "Secure boot" firmware may be self-upgradable, but it's not generally considered a great idea to let the OS overwrite the firmware with an arbitrary image. So, before booting the OS / bootloader, the firmware should set a hardware flag to prevent writes to the firmware chip. Once set, it should not be possible to un-set the flag without rebooting. Or something like that. It comes up because of course some firmwares neglected to do so properly... one example is here.

I do not know whether allowing SMT is another example or not.

It is undesirable to fight the firmware. It is especially undesirable to fight the firmware if your OS (Linux) is not trying to supporting you. (E.g. as it fights the firmware about ACPI ATA commands. Or more constructively, Linux ignores C state information from the ACPI BIOS, if it is running on an Intel CPU that it already knows accurate C state information for).

(Also, your aim still might not follow if the general rule applied. You might need the BIOS to tell you the layout, for example. And there might be reasons why you would not want to assume that the layout is static. I.e. reasons why it is not a good idea to patch the kernel to ignore BIOS provided ACPI tables, and instead use ACPI tables that you captured when booting with all the desired BIOS settings).

Even if your aim is possible, I would think you would be getting into hardware-specific details. It would be very impressive if you found a way to enable SMT in the kernel, that was not hardware-specific. I would not entirely trust an answer for this question as being canonical, if it did not specify that it had been tested on a matching motherboard and firmware version, and you have not specified what those are.

On that basis, I do not think that Linux developers will be trying to support you here. It is not a very common problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.