Updated: October 4, 2024
The problem you're facing is as follows. You've updated your Linux machine, there was a kernel update, and now, your machine is experiencing weird behavior. The symptoms include random desktop freezes that last for a few seconds, during which your machine is not usable, but recovers every single time. Reconnecting to Wi-Fi access points takes a long time. And in your kernel log (via dmesg), you see the following line: workqueue: pm_runtime_work hogged CPU for 10000us 4 times, consider switching to WQ_UNBOUND.
I encountered this issue on my Slimbook Titan in my last report. My machine is behaving erratically, and it's hard to use it. The error above points to a kernel bug, as outlined in the following bug report, and was supposed to have been solved. But as of early September 2024, my fully patched Kubuntu 22.04 machine still exhibits the freezes. Well, let's work around this nonsense. Follow me.
Workaround: Disable IPv6 network connectivity
It took me a little while to pinpoint the source of the issues. If you search for the error message, you will land on Askubuntu, where they discuss Kubuntu-related issues after a kernel update. That thread points to the Ubuntu bug report above. The core idea is to wait for a firmware fix. But I want an immediate solution. And it's readily available. You can disable IPv6 on your box, and the issues will go away.
Back in the day, to disable IPv6, you could easily add new directives to /etc/sysctl.conf. Not anymore. Today, in the "modern" world, you can either pass a boot parameter to the GRUB bootloader, or you can disable the IPv6 kernel module. Or both. I will show you both methods here, but for me, on my Titan system, the problem only went away after I used the GRUB boot parameter and blacklisted the IPv6 kernel module from loading. Since then, it's been smooth sailing.
Note: as the issue occurred on my Kubuntu 22.04 system, all of the commands below apply to Debian- and Ubuntu-based machines. For Fedora or openSUSE, the GRUB update sequence will be slightly different, so please refer to my tutorial above for more details.
GRUB method
Back up and then open the following file as root or sudo:
/etc/default/grub
Edit the kernel command line to read:
GRUB_CMDLINE_LINUX="ipv6.disable=1 [other parameters already there]"
Save and close the file. Update the bootloader as root or sudo:
update-grub
Reboot and test. After your session launches, you can check whether your running kernel has the parameter enabled. You can do that with:
cat /proc/cmdline
The ipv6.disable=1 entry ought to be there.
Kernel module blacklist method
For me, this was not sufficient. I also had to completely block the module from loading. Back up and then open the following file as root or sudo:
/etc/modprobe.d/blacklist.conf
Add to the end of this file the following entry:
blacklist ipv6
Save the file, reboot. Now, your freezes ought to be gone.
An aside on IPv6 ...
I happen to have an amazing technical intuition. It's near 100% accurate. Whenever I "experience" any new piece of technology, if my internal sensors fire off right away, I know it's a pointless and ugly solution. That's how I felt when I started dabbling in networking and encountered IPv6 some 20 years ago, and the sentiment remains. It's a nerdy, over-complicated implementation that's 0% relevant to any home user, and somewhat relevant to business, and even then, only the mega-big ones. From a simple, pragmatic, practical perspective, IPv6 brings nothing of value to the home user.
It brings complications. If you ask even a solid, diehard nerd what the IP address (IPv4 of course) of their system is, they will be able to tell you, easily. If you ask them to give you their IPv6 address, they won't be able to do that, because the notation is stupid, pointless, not designed for humans to remember, and therefore, ill-suited for purpose. You don't need anything else. I don't care about IoT, I don't need IPSEC, I don't want my machines exposed to the Internet and individually routable, I don't care about the shortage of IPv4 addresses as the problem can be easily solved with existing means. Furthermore, I've been hearing about this shortage, and "we're running out of addresses any day now" for more than 15 years. At some point, the boy who cried wolf story gets boring.
NAT is perfectly fine for home use, CG-NAT is okay for most people. IPv6 doesn't help. And, all of my ugly networking problems have always been IPv6-related. Never the old and crusty IPv4. On top of that, I don't know of a single PC game that has a multiplayer mode and direct-server connection functionality that uses IPv6. Not a single one. I haven't tried every computer game title out there, but of the dozens and hundreds that I did, I don't recall a single one that has implemented IPv6 anywhere. And why should they? The ugly notation is an affront to end users. Imagine your telephone number being 32 hexadecimal characters. Would you use your phone then? You wouldn't.
Data centers and ultra-corporations can play their games all they like. I don't care. IPv6 does not belong in the home environment. Period.
Conclusion
There we go. A neat, beautiful workaround for a pointless, unnecessary problem. Kernel bugs can happen, that's fine. The problem is, when someone is trying to create a beautiful Linux productivity setup as an alternative to Windows, and then they get held back by meaningless issues and annoying hardware-related snags, that journey becomes a hassle. And in this case, it's caused by something that 1) should have already been fixed 2) should never have happened in a home environment.
Well, my fix is to simply blacklist the ipv6 kernel module. Disabling the protocol ain't enough. However, once you prevent the module from loading, the freezes go away. My desktop is back to being fast, elegant and stable, which is what I expect and demand if I'm ever to use Linux seriously. Hopefully, this tutorial plus a mini rant will have helped you, both on the hardware level and emotional level. See you around.
Cheers.