Slimbook Titan report 7 - Nope, I’m not happy (again)

Updated: November 5, 2025

We must talk about my for-Linux-only laptop, one Slimbook Titan. I’ve had this machine for about two years and change. I bought it with the explicit mission of migrating away from Windows for good. The machine and its operating system, Kubuntu with its 22.04 LTS + pro edition (currently), needs to be able to do all sorts of wonders, including gaming, Windows software and whatnot. So far, it’s doing well, but it’s hobbled by completely unnecessary and randomly introduced software bugs.

Indeed, since I got the laptop, my big problem was the lack of consistency in the experience. If it were totally bad, I could ditch it. If it were totally good, I could enjoy it and forget about it. But no. In a typical Linux fashion of casual disregard to QA and the fullness of the desktop usage philosophy, issues come and go with every update, things break, and no one really cares. But for me, to be able to embrace this system, to rely on it for important activities, I need that reliability, I need that consistency. Stability and predictability are a must. And as I documented over the past six long-term reports, the Titan has not met these seemingly simple goals. Okay, let’s see what the seventh endeavor shall reveal before us. After me.

Fresh problems

I have encountered two new issues. First, one of the laptop’s fans has decided to start making serious noise. I’ve remarked on this early on in this machine’s history, across a number of my reviews, but now, the issue has become more noticeable. Namely, when you turn on the machine, for about an hour, until every piece of plastic and metal warms up and reaches a nice steady work temperature, the fan will warble and whistle erratically.

There’s no predictable pattern to the sound, except it manifests in these wild seesaw-like chirps. Quite annoying, because a steady rattle would be easier to filter out of one’s head. The way the fan behaves, you have a few seconds of quiet before a sudden burst of noise, which can then last a second or three or maybe seven, followed by another bout of peace. And repeat.

As I said, the issue goes away with use. But, every time the laptop is “cold”, it happens. And from my experience, with time, it will not get better. Fans rarely decide to become quiet with use. Quite the opposite. Usage wear makes components louder over time. So this is something to consider.

The second issue is, the keyboard doesn’t always nicely respond to presses. It’s a mediocre keyboard at best, as I mentioned before, but now, I really need to be forceful and hammer the keys for the strokes to register. I noticed quite a few letters missing when I’m typing casually (and fast). I need to be more deliberate. This does not feel like a software problem. It seems to be an entirely mechanical issue, and it’s quite disappointing to manifest so early in the machine’s life. I’ve not even typed 100K words on this keyboard yet.

Old problems

If you’ve read my old Titan reports, you know the machine has had a tough firmware-kernel stability life. Early on, there were problems with suspend. Those issue eventually got resolved. Then, the machine “experienced” an update that introduced new firmware and kernel, which resulted in super-annoying system freezes. A fresh round of patches seemed to have fixed those. Except.

This time, I got another round of badly tested code, and once again, the system undergoes those freezes, whereby the whole thing is unresponsive for 5-6 seconds. The issue manifests throughout the session, and it is accompanied by a torrent of messages in the system log. I even wrote about this, but now there’s even more noise:

acpi_os_execute_deferred hogged CPU for >10000us 8 times, consider switching to WQ_UNBOUND

acpi_ec_event_processor hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND

pm_runtime_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND

The pm_runtime errors are an old thing, but the acpi_ ones are new. This led me on some Internet hunting, to see what various forums and bugzilla ticket systems have to say. And man, do they have to say a lot.

• The Web is flooded with reports of this nature.
• It seems to affect almost every distro and hardware platform.
• The issue is “blamed” on buggy firmware, but can every firmware truly be buggy? Or is this perhaps a kernel issue?
• Indeed, since the problem comes and goes with kernel updates, I’d say it’s another manifestation of the Linux desktop hardware compatibility problem. The kernel isn’t truly designed for home use, and Linux at home is a happenstance of the situation rather than deliberate design. Linux is an enterprise thing, and solutions from that space are pushed onto the home systems with almost no regard whatsoever to actual usability. Add almost zero QA to the equation, and here we are.
• I absolutely hate that Linux distros “push” firmware along with system updates. They should be handled separately, because in my experience, if you have no hardware problems, there’s no need to keep upgrading your firmware (blindly), as it often leads to issues. The whole thing is so brittle it’s sad and ridiculous at the same time.
• Supposedly, salvation comes in kernel 6.10. The funny thing is, my system has an AMD processor! Now, the Phoronix report is from mid-2024, which means more than a year ago. I’ve experienced fresh problems in October 2025. Whatever this patch was supposed to be, it either hasn’t been backported to Ubuntu kernels that my system uses, or it has since been broken with new updates (which seems to be the case). Either way, Ubuntu 22.04 runs 6.8 only, so 6.10 without backports is not an option here.

A new workaround

Well, the “good” thing about all these reports above is that you can sort of work around the issue. You need to identify misbehaving interrupts, and then either disable (block) or mask them, with potentially unknown consequences mind, as it’s not trivial mapping ACPI calls (machine specific) to your hardware. Indeed, for my machine:

grep . /sys/firmware/acpi/interrupts/*

... /sys/firmware/acpi/interrupts/gpe00: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe01: 0 STS invalid unmasked /sys/firmware/acpi/interrupts/gpe02: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe03: 6071 EN enabled unmasked /sys/firmware/acpi/interrupts/gpe04: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe05: 0 invalid unmasked ...

The offending interrupt is gpe03, which you can block or mask. A quick way to see whether it makes any difference is to temporarily disable it, manually, via the command line, as root. The change won’t survive the reboot, so if something goes wonky, you can simply restart your machine.

echo “disable” > /sys/firmware/acpi/interrupts/gpe03

Instead of blocking, you can also try masking:

echo “mask” > /sys/firmware/acpi/interrupts/gpe03

If you’re happy, you can make the change more permanent, via GRUB, by adding new boot parameters to the kernel command line. Please consult the bootloader tutorial above for details on how to achieve this, and if you’re not comfortable with the procedure, then don’t do it. You can either use acpi_block_gpe or acpi_mask_gpe parameters.

acpi_mask_gpe=0x03

You could also create a systemd service that does the job. First, create a service unit file, and call it something like startup.service. Any name will work.

[Unit] Description=Script to disable gpe

[Service] ExecStart=/root/startup.sh

[Install] WantedBy=multi-user.target

Save this file to /etc/systemd/system. Then, create a script titled startup.sh, which needs to be placed somewhere on your system. I chose the root home folder. The contents of this script are:

#!/bin/bash echo “disable” > /sys/firmware/acpi/interrupts/gpe03 exit 0

You can also use mask instead of disable. Make sure you specify the correct gpe. Make sure the script is executable, otherwise it won’t run. You can do this with the chmod +x command against the script file. If you’re not comfortable doing this, you probably shouldn’t tinker to begin with.

Lastly, enable the systemd service:

sudo systemctl enable [service name you chose earlier]

Restart, and check the interrupts to see whether it shows as masked or disabled. If you don’t want to use the service anymore, disable it. You can also delete the service unit file, or remove the script, but that’s not elegant, and may result in spurious errors in your system log.

I did mask the gpe, and it helps. The freezes go away. But I really don’t know what system functionality is now impaired, if any. The one visible outcome from the change is that when I plug the battery charger in, there’s no longer the notification sound.

Gaming

No new news, so to speak. I still can’t play Assetto Corsa via Proton. I didn’t install any custom versions of the compatibility tool, or tried any manual hacks. I decided to only use whatever Steam offers, and force the game to run with different versions of Proton. No luck so far, but that does not mean I’ll stop trying.

And we shall stop here, I think.

Conclusion

The tragic brilliance of the Linux desktop. On one hand, the Titan does admirably. Pretty decent hybrid graphics setup, boot encryption, gaming via Steam Proton, a dozen Windows programs running superbly with WINE, all the perks of the Plasma environment. With a virtual machine for office stuff, I’m really ready to face the future sans Windows, so to speak. But then, it all gets shattered with barely tested firmware and kernel patching, ruining the bliss, undoing all the fine, sweet achievements.

Someone could say, no big deal, you tinker a little, job done. That’s fun when you do it voluntarily, on a spare system, or when you’re 20 and without a care in the world. For me, with real-life objectives and deadlines, I cannot afford “mi scusi” moments in the operating system. What makes it worse is that the overall stability of the ecosystem has gotten WORSE since I purchased the laptop. You would expect more stability, more quality over time, even if initial releases were meh. But no. This means extrapolating into the future is a grim prospect. The alternative is either using Windows in a “defeat” mode, or buying a Mac and savoring the financial PTSD that such a purchase would bring, with the true added benefit of tight hardware-software integration.

I shall keep on using Linux, as I’ve done seriously for many many years. The only question is, will Linux ever give me the peace and the stability that I need. For that, we shall have to wait to the eighth and the ninth and the nth report about the Titan. On a side note, yes, the Titan still runs pro-enabled 22.04, and I’m hesitant to move to 24.04 given how buggy the Executive upgrade process was. I’m totally not looking forward to things randomly breaking yet more, without any promise of true benefits. Again, that’s a story for another report. For now, I feel rather dejected. C’est la vie. Take care.

Cheers.