I’ve had an issue with occasional lockups on my Acer Swift 1 laptop. They were infrequent enough to make it difficult to troubleshoot, and there was nothing in the system logs that looked at all unusual. I’d really hoped it was not a hardware issue, as the Swift is out of warranty.
Recently, because of COVID, I had occasion to use Zoom (even though I was 50 miles from home and 50 feet from the individual with whom I was chatting). I’d never used it before, and I’d only heard of it by means of the bad news in the headlines, but nothing that was going to be discussed was private, and I found that I didn’t need to create an account.
I only used it for a few minutes from the Swift, and it managed to trigger a lockup. Fortunately, the discussion was short, and we’d mostly finished (did the rest on the phone). That presented an opportunity… if Zoom had actually triggered the lockup, rather than it just being a random thing, I could use that as a stress tester.
Once home, I tried it, using the preview mode that appears before the actual meeting. Sure enough, in a short time, it froze.
I began to uninstall things and change settings, but after each change, it crashed again. Then I thought to try Windows 10, which was still there on the internal eMMC drive, though it was basically untouched since Acer preinstalled it. It still had all of the bloatware intact, and had never been updated. I’d shrunk its partition to be only slightly larger than the Windows installation itself, so there was no room for that.
I installed the Windows version of the Zoom client, then repeated the test. After a few hours, it had not crashed. I began to think… I knew the Windows build was old, but I didn’t realize how old. It was still on 1604, before the Spectre issues and the microcode updates that came along with them. The system firmware was fairly old too.
Could that have been the cause of the crashing? (Pretending I didn’t already give it away in the title.)
Ubuntu and related distros will automatically install the latest microcode updates if you accept them all, and I had. I verified that the microcode I had installed, 0x38, was the most recent.
I uninstalled the intel-microcodes package, then updated the initramfs, reverting to the microcode within the system firmware. Ubuntu and related distros usually load the microcode before Linux proper boots, and updating initramfs rebuilds the initramfs image and incorporates any changes like the updated microcode.
After a restart, and with the new (er, old) microcode loaded, I repeated the Zoom test, and it went overnight without a freeze. It had not gone longer than 1.5 hours without locking up, and usually well under a half hour.
Now that I knew this, I wanted to see if I could get away with using the second-newest microcode instead of going way back to whatever was the firmware version. I reinstalled intel-microcodes (it’s a dependency of the kernel virtual package, which I had also removed for the test), then replaced the 0x38 microcode with 0x32, which I had managed to extract from one of my backups. The microcode is in /lib/firmware/intel-ucode, so I just went through my backups until I found one with a different file hash, then plugged that one into the intel-ucode directory and again updated the initramfs.
I repeated the test, overnight again, and again, there was no lockup.
Designing the Spectre vulnerability into their CPUs is bad enough, but when the fix for that vulnerability makes the system unstable, that’s worse.
Acer is one of the OEMs that does not permit downgrading the system firmware. If this microcode had been a part of a firmware update, I’d have a real problem. Can the Linux microcode loader be told to overwrite the firmware microcode with an older one? I have no idea. It’s not usually done that way.
It might be possible to hack things to be able to downgrade the firmware, but that can be dangerous, as I know all too well.
That’s why I like doing it with the OS. I had a problem, and now I don’t, other than the microcode I am now using not having the latest “fix” from Intel, whatever that may have been. Maybe they will release another one for my Swift’s N4200 “Pentium” CPU/SOC, and I’ll try it for sure. If it is still broken, I can go back easily enough.
AMI has firmware editing tools that worked very well with my older PCs. Whether the tools work with newer firmware versions, I don’t know… but I do know my Acer uses Insyde (unfortunately), not AMI, so it wouldn’t work anyway. Insyde might have its own tools to do this, but I don’t have to think about that now, since I can do it easily at the OS level.
It’s things like this that are the reason I still keep Windows around. Being able to try things on a completely different OS (to rule out, or in, hardware issues) can be helpful. As long as updates and WaaS are as they are, I won’t be using Windows 10 as an OS, but as a diagnostic tool for the benefit of Linux, it has its uses.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
