Computers are complex. However, most of that complexity has been abstracted and hidden away from users eye. But from time to time, bizarre errors happens. This article is going to help you solve one of them : "TSC_DEADLINE disabled due to Errata" error.
What does "TSC_DEADLINE disabled due to Errata" means?
If you've landed in this article, there's a high chance you already had a bit technical understanding. So we will explain the error message in technical terms.
Usually, "TSC_DEADLINE disabled due to Errata" comes with additional information, such as the full error message below :
[Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x52 (or later)
The "microcode" part indicates that the problem might be related to the CPU and its instruction set.
TSC deadline is an efficient implementation of event handling, which is nice to have, but not essential.
Fixing "TSC_DEADLINE disabled due to Errata"
Solution 1 : Upgrade BIOS of the motherboard
Most of the time, the OS you're trying to install or update is newer than the CPU and motherboard, the OS will updates CPU microcode automatically. But for some reasons, your updated firmware is no longer upgrading your CPU’s microcode, whereas the previous firmware you had, did.
You need to search through your motherboard manufacturer website, then download the latest BIOS and update utility. A fresh BIOS update might solve "TSC_DEADLINE disabled due to Errata".
Solution 2 : Boot up using previous kernels
If a BIOS update does not do the trick, try force booting the OS with lower kernel version.
Immediately after the BIOS/UEFI splash screen during boot, quickly press and hold the Shift key, which will bring up the GNU GRUB menu. With UEFI press (perhaps several times) the Esc key to get to the GRUB menu. Sometimes the manufacturer's splash screen is a part of the Windows bootloader, so when you power up the machine it goes straight to the GRUB screen, and then pressing Shift is unnecessary.
The timing when to press the left Shift key can be tricky, so sometimes if you miss it you need to try it again.
Once you see the GRUB screen, select Advanced options and try booting with lower versions of the kernel.
Solution 3 : Reinstall microcode package
If you are able to get into a terminal, you can install the microcode update packages and hopefully re-enable TSC deadline support.
On Debian/Ubuntu, the packages are distributed in
non-free repositories. To do so, edit your
/etc/apt/sources.list to ensure that it include
non-free. Once you've made sure
sources.list contains all the necessary lines, run the following commands :
# For Intel processors sudo apt install intel-microcode # For AMD processors sudo apt install amd64-microcode
Once that’s done, reboot, and your microcode should be updated by now.
Solution 4 : Check system consistency using fsck
If it is a /dev/sd** error like the image above, you can do a system consistency check and repair with fsck.
The reason could be the system wrote corrupted data to the disk in the last shut down, which causes bizarre errors.
Running this command in the terminal to get the check running :
fsck -y /dev/sdaX
Remember to replace sdaX with a suitable number depending on your setup. In my case, it would look like
fsck -y /dev/sda1
Once the check is done, run
exit to reboot.
Solution 5 : Re-sync system time and date
I don't know whether system time and the error are related or not, but since I've found somebody successfully solve the error with this method, you could try it anyway.
If you can get into a terminal, run this :
sudo timedatectl set-local-rtc true
Then reboot to see if the above command does the trick.