Slimbook Titan 長期レビュー(第7回):2年経っても満たされない期待

Slimbook Titan レポート 第7回 ― 残念ながら、またしても満足できません

更新日:2025年11月5日

今回は、私が「Linux専用機」として購入したノートPC、Slimbook Titanについて語らせてください。このマシンを使い始めてから2年余りが経ちました。購入の目的は明確で、Windowsからの完全な移行です。Kubuntu 22.04 LTS + Proエディション(現行)を搭載したこのマシンには、ゲームからWindows向けソフトウェアの実行まで、あらゆるタスクをこなせることが求められます。これまでのところ概ね良好に動作していますが、完全に不要でありながら突発的に発生するソフトウェアのバグに足を引っ張られています。

実際のところ、このノートPCを手にして以来の最大の悩みは、体験の一貫性の欠如でした。完全にダメなら見限ることもできますし、完全に優秀なら安心して使い続けられるでしょう。しかし現実はそうではありません。いかにもLinuxらしい、QAへの無関心とデスクトップ利用という思想の軽視ぶりにより、アップデートのたびに問題が出たり消えたりし、何かが壊れ、そして誰も本気で気にかけません。私にとってこのシステムを受け入れ、重要な作業を任せるためには、信頼性と一貫性が必要不可欠です。安定性と予測可能性は絶対条件です。過去6回にわたる長期レポートで記録してきたように、Titanはこの一見シンプルな目標を達成できていません。さて、7回目の試練が何を見せてくれるのか、見ていきましょう。

新たな問題

今回は2つの新しい問題に遭遇しました。1つ目は、ノートPCのファンの片方が深刻な異音を立て始めたことです。この現象自体は、このマシンの初期のレビューでも何度か言及してきましたが、今ではかなり顕著になっています。具体的には、電源を入れてから約1時間ほど、プラスチックや金属がすべて温まり安定した動作温度に達するまでの間、ファンが不規則にうなり、キーキーと鳴きます。

音には予測可能なパターンがなく、シーソーのような激しいチャープ音として現れます。一定のガタガタ音なら脳内でフィルタリングするのも簡単ですが、この鳴き方は非常に厄介です。数秒の静寂の後、突然1〜3秒、あるいは7秒ほど騒音が続き、また静かに戻る――これを繰り返します。

前述の通り、この問題は使用中には収まります。しかし、ノートPCが「冷えている」状態では毎回発生します。経験上、これは時間とともに良くなることはありません。ファンは使えば静かになるどころか、むしろ逆です。使用による摩耗は部品をより騒々しくしていきます。覚えておくべきポイントです。

2つ目の問題は、キーボードが入力に正しく反応しないことがあることです。以前にも述べた通り、このキーボードは良く言っても並程度ですが、今では強く叩くように力を込めないと入力が登録されません。普段のスピードでタイピングしていると、かなりの文字が抜け落ちるのに気づきます。もっと意識的に打たなければなりません。これはソフトウェアの問題とは思えません。完全に機械的な問題のようで、マシンの寿命のごく早い段階で現れたのは非常に残念です。このキーボードで10万語すら打っていないのに。

昔からの問題

Titanの過去のレポートを読んだ方なら、このマシンがファームウェアとカーネルの安定性に苦労してきたことをご存じでしょう。当初はサスペンドに問題があり、それらは最終的に解決されました。その後、新しいファームウェアとカーネルをもたらすアップデートによって、極めて厄介なシステムフリーズが発生しました。新しいパッチのラウンドでそれらは修正されたように見えたのですが……。

今回もまた、テスト不足のコードが降ってわたり、再びシステムがフリーズするようになりました。全体が5〜6秒間応答しなくなるのです。この問題はセッション中ずっと発生し、システムログには大量のメッセージが流れます。以前も書きましたが、今度はさらに多くのログが出力されています:

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

pm_runtimeのエラーは以前からのものでしたが、acpi_系は新顔です。そこでインターネットを漁り、各種フォーラムやBugzillaのチケットが何と言っているのか調べてみました。すると、これがもう大量にあるのです。

• ウェブはこの種の報告で溢れかえっています。
• ほぼすべてのディストリビューションとハードウェアプラットフォームに影響しているようです。
• 原因は「バグだらけのファームウェア」とされることが多いのですが、本当にすべてのファームウェアがバグっているのでしょうか?それとも、これはカーネル側の問題ではないのでしょうか?
• 実際、カーネルのアップデートとともに問題が出たり消えたりすることから考えると、これはLinuxデスクトップにおけるハードウェア互換性問題の別の現れだと私は考えています。カーネルは本来ホームユース向けに設計されておらず、家庭でのLinuxは意図的な設計の結果ではなく偶然の産物です。Linuxはエンタープライズ向けの存在であり、その分野のソリューションが実際のユーザビリティをほとんど考慮せずに家庭用システムへ押し付けられています。そこにほぼゼロのQAを掛け算すれば、今の状況になるわけです。
• Linuxディストロがシステムアップデートと一緒にファームウェアを「押し込む」のは本当に嫌いです。別々に扱うべきです。私の経験では、ハードウェアに問題がないなら、(盲目的に)ファームウェアを更新し続ける必要はなく、むしろトラブルの元になりがちです。あまりに脆く、悲しくも滑稽な有様です。
• 救済はカーネル6.10で提供されるということです。面白いことに、私のシステムはAMDプロセッサ搭載です!Phoronixの記事は2024年半ば、つまり1年以上前のものです。私は2025年10月に新たな問題を経験しました。このパッチがどうであったにせよ、私のシステムが使うUbuntuカーネルにバックポートされていないか、あるいはその後のアップデートで壊れてしまったか(後者らしい)のどちらかです。いずれにせよUbuntu 22.04は6.8までしか走らないため、バックポートなしの6.10は選択肢になりません。

新しい回避策

幸い、上述の報告群のおかげで、ある程度この問題を回避することができます。不調な割り込みを特定し、それを無効化(disable/ブロック)またはマスク(mask)するのです。ただし、ACPI呼び出し(マシン固有)を実際のハードウェアに対応付けるのは簡単ではないため、未知の副作用があるかもしれない点には注意してください。私のマシンの場合:

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
...

犯人はgpe03で、これをブロックまたはマスクできます。効果があるかどうか手っ取り早く確認するには、root権限でコマンドラインから一時的に無効化してみましょう。変更は再起動で失われるため、何かおかしくなってもマシンを再起動すれば元に戻ります。

echo "disable" > /sys/firmware/acpi/interrupts/gpe03

ブロックの代わりに、マスクを試すこともできます:

echo "mask" > /sys/firmware/acpi/interrupts/gpe03

うまくいったら、GRUB経由でカーネルコマンドラインにブートパラメータを追加し、変更を恒久的にできます。手順の詳細はブートローダーのチュートリアルを参照してください。自信がなければ実行しないでください。acpi_block_gpeまたはacpi_mask_gpeパラメータを使用できます。

acpi_mask_gpe=0x03

systemdサービスを作成して対応する方法もあります。まずサービスユニットファイルを作成し、startup.serviceなど任意の名前を付けます。名前は何でも構いません。

[Unit]
Description=Script to disable gpe

[Service]
ExecStart=/root/startup.sh

[Install]
WantedBy=multi-user.target

このファイルを/etc/systemd/systemに保存します。次に、startup.shという名前のスクリプトを作成し、システム上の任意の場所に置きます。私はrootのホームフォルダを選びました。スクリプトの中身は以下の通りです:

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

disableの代わりにmaskを使っても構いません。必ず正しいgpeを指定してください。スクリプトに実行権限を付与しないと動作しません。chmod +xコマンドでスクリプトファイルに実行権限を与えてください。これに不安があるなら、そもそもいじらない方が賢明でしょう。

最後に、systemdサービスを有効化します:

sudo systemctl enable [先ほど決めたサービス名]

再起動し、割り込みの状態を確認して、マスクまたは無効化されているかチェックしましょう。サービスが不要になったら無効化してください。サービスユニットファイルやスクリプトを削除することもできますが、それは美しくなく、システムログに謎のエラーを残す可能性があります。

私はgpeをマスクしました。効果はあり、フリーズはなくなりました。ただ、どんなシステム機能が損なわれているのか(あればの話ですが)は正直わかりません。この変更で目に見える唯一の変化は、充電器を接続しても通知音が鳴らなくなったことです。

ゲーミング

特に新しいニュースはありません。相変わらずAssetto CorsaをProton経由ではプレイできません。互換ツールのカスタム版をインストールしたり、手動ハックを試したりはしていません。Steamが提供するものだけを使い、さまざまなバージョンのProtonで強制的に起動を試みる方針です。今のところ成功していませんが、諦めるつもりはありません。

ここまでにしておきましょう。

結論

Linuxデスクトップの悲劇的な輝き。一方で、Titanは立派に頑張っています。まずまずのハイブリッドグラフィックス構成、ブート暗号化、Steam Protonによるゲーム、WINEで快調に動く十数個のWindowsアプリ、Plasma環境のあらゆる恩恵。オフィス作業用の仮想マシンもあり、「Windowsなしの未来」に立ち向かう準備は整っています。しかし、ほとんどテストされていないファームウェアとカーネルのパッチ適用がその至福を打ち砕き、積み上げてきた素晴らしい成果をすべて台無しにしてしまうのです。

「大したことない、少し弄れば終わりだよ」と言う人もいるでしょう。余ったシステムで自発的にやる分には楽しいものですし、20歳で何の心配もない若者ならなおさらです。しかし現実の目標と締め切りを抱える私にとって、OSでの「ごめんなさい」の瞬間は許容できません。さらに悪いことに、ノートPCを購入して以来、エコシステム全体の安定性は悪化(WORSE)しています。初期リリースがイマイチだったとしても、時間とともに安定性と品質は向上していくはずでしょう。しかし現実は違います。これは将来への外挿が暗淡であることを意味します。選択肢は、「敗北」モードでWindowsを使うか、Macを買ってその価格帯がもたらす金銭的PTSDに耐えながら、密結合されたハードウェア・ソフトウェア統合という真のメリットを味わうかのどちらかです。

それでも私はLinuxを使い続けます。何年も本気で向き合ってきたように。唯一の疑問は、Linuxがいつか私に必要な安らぎと安定性を与えてくれるのかどうかです。その答えは、8回目、9回目、そしてn回目のTitanレポートを待つしかありません。余談ですが、はい、Titanは依然としてPro有効化済みの22.04で稼働しており、Executiveアップグレードプロセスのバグだらけぶりを目の当たりにした今、24.04への移行には躊躇しています。真のメリットの約束もないまま、物事がさらにランダムに壊れるのを心待ちにする人はいません。これもまた、別のレポートでお話しする話です。今のところ、私はかなり落胆しています。人生とはそんなもの。それでは、ごきげんよう。

それではまた。