January 12th, 2018 
CryptoBadger If you rebooted your linux-based mining rig at some point in the last couple days, you may have noticed that your mining hashrate was drastically lower after your system restarted. What happened?
Turns out a kernal update designed to patch the Meltdown & Spectre vulnerabilities present in Intel CPUs was deployed on January 9th, and it had the unintended consequence of negatively impacting GPU mining speed.
Thankfully, you can manually remove the update for now. Just follow these instructions and you should be back to normal.
Thanks to the many readers that wrote in and made me aware of the issue!
Posted in 
One thing to add is to disable unattended updates to stop it happening again in the future.
Cheers
Chris
Good point – I added a line at the end of the FAQ entry with a link to some easy methods to accomplish that.
Thank you!!!
I just updated, rebooted, manually removed the update (as listed in the FAQ), rebooted again, and my system bricked. Bunch of stuff on the error screen, including:
[Firmware Bug] TSC_DEADLINE disable due to Errata; please update microcode to version: 0x22 or later
Kernel panic – not syncing: VFS: Unable to mount foot fs on unknown-block(0,0)
#(Bunch of other data)
end Kernel panic – not syncing: VFS: Unable to mount root fs on unkown-block(0,0)
Maybe pebcak, but I’m reinstalling and setting the rig back up as I type this.
Worked without any issues on my other rig, so maybe it was just time for a fresh image. ¯\_(ツ)_/¯
Worked like a champ! I used to be 25 mh/s, then it dropped to 20, with your undo commmands I was back to 25!
Does this mean i never want to update my rig again? Or will I still be able to update at a later date?
You’ll probably want to disable automatic updates for now. Presumably there will be a fix available at some point that allows the vulnerability to be properly patched without negatively impacting mining performance.
Thanks for the reply – yeah I used option 3 on your link there to disable updates for now! Appreciate the guide and the responses, you have no idea how much this has helped me!
I am really glad you mentioned this. I had 3 graphics cards running well for a couple of days and after hooking up a secondary PSU with an add2psu to relay to go to four cards suddenly nothing started working. Thought maybe it was the second PSU, maybe OS, went back to an attempted clean install and couldn’t get half my netbootin usb disks to boot on anything. Thought maybe it was something with usb’s or that I didn’t understand about formatting. Long story short Ubuntu 17.04 doesn’t have any patches issued for it. The work arounds mentioned above didn’t help me, but a clean install with 17.04 and things are working fine.
That worked, thanks! But oddly I went from 195 mhs to 190 mhs. Looks like a minor drop on all the cards. Any idea why that would happen? I reverted back to the ROCm kernal – Linux 4.11.0-kfd-compute-rocm-rel-1.6-180 x86_64
Just wanted to say thank you, whilst the fix in the link didn’t actually work on my rigs for some reason so I reinstalled Ubuntu per the Linux guide but without being connected to the internet, I disabled autoupdates before reconnecting to the internet, and continued with installation per the rest of the guide without doing installing any package updates.
My rigs are now pumping out the same megahshes as they were pre meltdown / spectre patch… so BIG thanks!
NB
Perhaps you might update the Linux guide with new advice around package updates after the SSH section.. otherwise new people doing installs following your guide could end up with the patched version of Ubuntu and end up with lower hashrates than they expected… just a suggestion.
Peace.
Good point – I’ve added a note at the end of the guide so that newcomers will be able to easily find info on removing the patch. Hopefully a fix that makes this unnecessary is available soon!
Is there a security concern with not patching the Kernel? I know Raspberry Pis aren’t susceptible to this because their CPUs are too basic, but do out Celerons leave us vulnerable to someone gaining access to the miner (and I would imagine everyone’s private eth keys)?
Great question. Yes, if your rig has an Intel CPU (AMD processors aren’t vulnerable), then you’re technically leaving yourself open to attack by not patching.
If you’re worried about your leaving your rig unpatched, then the best course of action is to simply backup your private wallet key(s) to a secure offline location, and then delete the keys from your rig. That way, even in the worst-case scenario of an attacker gaining access to your rig, they won’t be able to steal your wallet.
Why would your private keys ever be on a mining rig ?
The fix nearly bricked my miner as well. It was really weird could only boot into the bios and wouldn’t even boot off of a thumb drive with a fresh Linux install. I was fortunately able to boot it off of a spare EthOs copy… but now I have a hard drive I’m not sure what to do with.
Hi,
mine rx480 drop from 27mhz to 20mhz, but from doing this, it still doesnt bring it back up.
Any ideas ?
The AMDGPU drivers through your link don’t seem to work anymore. I had to install the basic driver which clocks in at a much lower MH/s for mining. Any suggestions? Is there somewhere I can get an archived version of the driver?
Cryptobadger,
Thanks for awesome website and info.
you need to update this fix to include another step, as a lot of people are still having problems after the update removal. I found that the next step is to reinstall 16.04.3 and make sure that automatic update is checked off during the install and to make sure that automatic updates are disabled. I know it’s a pita but that was the only thing that worked for me. Still easier than installing and setting up Windows. Also need to make sure to let people know to backup the key files and eth account info prior to updates.
Does this mean i never want to update my rig again? Or will I still be able to update at a later date?
the fix didn’t work for me even after disabling updates, still was at the new slow speeds, but thankfully with the awesome ethereum mining guide found on this site I was able to get it all back and running quickly with a new install with disabled updates plus the new Claymore v.11.0, running faster than ever now, thanks Crypto Badger!
Everyone, if you’d like to easily recompile the kernel without these patches enabled.
You can do so by following the instructions here: https://github.com/Turbine1991/build_ubuntu_kernel_wastedcores
By default, it’ll disable the spectre patchsets, and some other security patches which may hurt performance. You can further cut it down by using the menu.
Neat kernel builder but it doesn’t bother to offer 4.10 which AMDGPU-PRO requires / useless.
The more correct way is disable patches by adding kernel options:
1) open /etc/default/grub in text editor;
2) find these string – GRUB_CMDLINE_LINUX_DEFAULT=”splash quiet”;
3) add these command “nopti noibpb noibrs” so your string would be like that
GRUB_CMDLINE_LINUX_DEFAULT=”splash quiet nopti noibpb noibrs”;
4) make sure you save the file;
5) sudo update-grub;
6) reboot your rig;
7) check if that works –
dmesg| grep iso
dmesg| grep IBRS
Now you may use any kernel without patching them!
Any developments on the patch/miner hashrate issue? Are there any issues with the new Ubuntu releases?
Hi,
Any developments on the patch/miner hashrate conflict? Are there any issues with the new Ubuntu releases?