Linux Meltdown/Spectre patch destroys mining hashrates, here is the fix

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!

15 Responses to Linux Meltdown/Spectre patch destroys mining hashrates, here is the fix

  1. Chris Gooch says:

    One thing to add is to disable unattended updates to stop it happening again in the future.


  2. Ray says:

    Thank you!!!

  3. Barry says:

    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.

  4. Ed says:

    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!

  5. Whitehotburn says:

    Does this mean i never want to update my rig again? Or will I still be able to update at a later date?

  6. Paul says:

    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.

  7. Ben says:

    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

  8. SJK says:

    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!

    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.


    • CryptoBadger says:

      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!

  9. Ben says:

    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)?

    • CryptoBadger says:

      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.

Leave a Reply

Your email address will not be published.