Slimbook Titan レビュー:2 年経っても満たされなかった期待

Slimbook Titan レポート 7 - いいえ、満足していません (またもや)

更新日:2025 年 11 月 5 日

私の Linux 専用ラップトップ、Slimbook Titan について話さなければなりません。私はこのマシンを約2年間使用していましたが、変更しました。私は Windows から永久に移行するという明確な使命を持ってこれを購入しました。マシンとそのオペレーティング システムである Kubuntu (22.04 LTS + プロ エディション (現時点)) は、ゲーム、Windows ソフトウェアなどを含むあらゆる種類の驚異的なことを実行できる必要があります。これまでのところ順調に進んでいますが、まったく不必要でランダムに導入されたソフトウェアのバグによって妨げられています。

実際、ラップトップを購入して以来、私の大きな問題は、エクスペリエンスに一貫性がないことでした。完全にダメだったら、捨ててもいいのに。それが完全に良かったなら、楽しんで忘れることができます。しかし、そうではありません。 QA やデスクトップ使用哲学の充実を無造作に無視する典型的な Linux のやり方では、更新のたびに問題が発生したり消えたりし、問題が発生し、誰も気にしません。しかし、私にとって、このシステムを受け入れ、重要な活動を行うためには、その信頼性と一貫性が必要です。安定性と予測可能性は必須です。そして、過去6回の長期レポートで私が文書化したように、タイタンはこれらの一見単純な目標を達成していません。さて、7 番目の試みが私たちの前に何を明らかにするか見てみましょう。私の後です。

新たな問題

2 つの新しい問題に遭遇しました。まず、ラップトップのファンの 1 つが重大な騒音を発し始めました。私はこのマシンの歴史の早い段階で、多くのレビューでこの点について言及してきましたが、現在、この問題はより顕著になってきています。つまり、プラスチックや金属のすべての部分が温まり、適切な安定した作業温度に達するまで、約 1 時間機械の電源を入れると、ファンが不規則にうなり声を上げたり、笛を吹いたりします。

この音には、シーソーのようなワイルドな鳴き声で現れることを除いて、予測可能なパターンはありません。安定したガタガタ音は頭から追い出されやすいため、非常に迷惑です。ファンの動作では、数秒間静かな状態が続いた後、突然騒音が発生し、その後 1 秒か 3 秒、場合によっては 7 秒ほど続き、その後再び平穏な状態が続きます。そして繰り返します。

先ほども言いましたが、問題は使用するにつれて解消されます。しかし、ラップトップが「冷えている」ときは必ずこのようなことが起こります。私の経験から言えば、時間が経っても症状は改善されません。ファンが使用中に静かになることを決めることはほとんどありません。まったく逆です。使用による磨耗により、時間の経過とともにコンポーネントの音が大きくなります。したがって、これは考慮すべき点です。

2 番目の問題は、キーボードが押してもうまく反応しないことです。前にも述べたように、よく言っても平凡なキーボードですが、ストロークを記録するには、非常に力を入れてキーをハンマーで叩く必要があります。何気なく（そして速く）入力していると、かなりの数の文字が欠けていることに気づきました。もっと慎重になる必要がある。これはソフトウェアの問題とは思えません。これは完全に機械的な問題のようで、マシンの寿命の早い段階でこれが現れるのは非常に残念です。このキーボードではまだ 10 万語も入力していません。

古い問題

私の古い Titan レポートを読んだことがある方なら、このマシンのファームウェアとカーネルの安定性の寿命が厳しいことをご存知でしょう。初期段階ではサスペンドに問題がありました。それらの問題は最終的に解決されました。その後、マシンは新しいファームウェアとカーネルを導入するアップデートを「経験」し、その結果非常に迷惑なシステム フリーズが発生しました。新たなパッチによりそれらが修正されたようです。ただし。

今度は、もう一度テストが不十分なコードを入手したため、再びシステムがフリーズし、全体が 5 ～ 6 秒間応答しなくなりました。この問題はセッション全体で発生し、システム ログに大量のメッセージが記録されます。このことについても書きましたが、今ではさらにノイズが増えています:

acpi_os_execute_deferred が 10000us を超える CPU を 8 回占有しました。WQ_UNBOUND への切り替えを検討してください

acpi_ec_event_processor が 10000us を超える CPU を 4 回占有しました。WQ_UNBOUND への切り替えを検討してください

pm_runtime_work が 10000us を超える CPU を 4 回占有しました。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 はここでは選択肢になりません。

新しい回避策

さて、上記のすべてのレポートの「良い」点は、この問題をある程度回避できることです。 ACPI 呼び出し (マシン固有) をハードウェアにマッピングするのは簡単ではないため、未知の結果が生じる可能性を考慮して、不正な動作をしている割り込みを特定し、無効 (ブロック) またはマスクする必要があります。実際、私のマシンでは次のようになります。

grep 。 /sys/ファームウェア/acpi/割り込み/*

...
/sys/firmware/acpi/interrupts/gpe00:0 無効 マスク解除
/sys/firmware/acpi/interrupts/gpe01:0 STS 無効 マスク解除
/sys/firmware/acpi/interrupts/gpe02:0 無効 マスク解除
/sys/firmware/acpi/interrupts/gpe03:6071 JA 有効 マスク解除
/sys/firmware/acpi/interrupts/gpe04:0 無効 マスク解除
/sys/firmware/acpi/interrupts/gpe05:0 無効 マスク解除
...

問題のある割り込みは gpe03 で、これをブロックまたはマスクできます。違いがあるかどうかを確認する簡単な方法は、コマンド ラインを介して root として手動で一時的に無効にすることです。変更は再起動後は反映されないため、何か問題が発生した場合は、マシンを再起動するだけで済みます。

echo "無効"> /sys/firmware/acpi/interrupts/gpe03

ブロックする代わりに、マスキングを試すこともできます。

echo "マスク"> /sys/firmware/acpi/interrupts/gpe03

問題がなければ、GRUB を介してカーネル コマンド ラインに新しいブート パラメータを追加することで、変更をより永続的にすることができます。これを実現する方法の詳細については、上記のブートローダー チュートリアルを参照してください。手順に慣れていない場合は、実行しないでください。 acpi_block_gpe パラメータまたは acpi_mask_gpe パラメータのいずれかを使用できます。

acpi_mask_gpe=0x03

このジョブを実行する systemd サービスを作成することもできます。まず、サービス ユニット ファイルを作成し、startup.service などの名前を付けます。任意の名前を使用できます。

【単位】
説明=GPE を無効にするスクリプト

【サービス】
ExecStart=/root/startup.sh

[インストール]
WantedBy=マルチユーザー.ターゲット

このファイルを /etc/systemd/system に保存します。次に、startup.sh という名前のスクリプトを作成します。これはシステム上のどこかに配置する必要があります。私はルートホームフォルダーを選択しました。このスクリプトの内容は次のとおりです。

#!/bin/bash
echo "無効"> /sys/firmware/acpi/interrupts/gpe03
0番出口

無効にする代わりにマスクを使用することもできます。正しい gpe を指定していることを確認してください。スクリプトが実行可能であることを確認してください。そうでない場合、スクリプトは実行されません。これは、スクリプト ファイルに対して chmod +x コマンドを使用して行うことができます。これを行うことに慣れていない場合は、最初からいじくり回すべきではないでしょう。

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

sudo systemctl Enable [前に選択したサービス名]

再起動し、割り込みをチェックして、マスクされているか無効になっているかを確認します。サービスをもう使用したくない場合は、無効にしてください。サービス ユニット ファイルやスクリプトを削除することもできますが、これは洗練された方法ではなく、システム ログに偽のエラーが記録される可能性があります。

gpe をマスクしましたが、役に立ちました。フリーズは解消されます。しかし、実際には、どのシステム機能が損なわれているのか、もしあれば、わかりません。この変更による目に見える成果の 1 つは、バッテリー充電器を接続したときに通知音が鳴らなくなったことです。

ゲーム

いわば新しいニュースはありません。 Proton経由でAssetto Corsaをプレイすることはまだできません。互換性ツールのカスタム バージョンをインストールしたり、手動によるハッキングを試みたりはしていません。 Steam が提供するもののみを使用し、異なるバージョンの Proton でゲームを強制的に実行することにしました。今のところ運は良くありませんが、だからといって努力をやめるわけではありません。

そして、ここでやめておこうと思います。

結論

Linux デスクトップの悲劇的な輝き。一方で、タイタンは見事にやっています。かなりまともなハイブリッド グラフィックス セットアップ、ブート暗号化、Steam Proton 経由のゲーム、WINE で見事に動作する 12 個の Windows プログラム、Plasma 環境のすべての特典。オフィス用の仮想マシンがあれば、言わば Windows のない未来に直面する準備ができています。しかしその後、ほとんどテストされていないファームウェアとカーネルのパッチ適用によってすべてが打ち砕かれ、至福の時間が台無しになり、素晴らしい素晴らしい成果がすべて台無しになってしまいます。

誰かが、大したことはない、少しいじって、仕事は終わった、と言うかもしれません。それは自発的に、予備のシステムで、または20歳で世間を気にせずにやっているときは楽しいです。現実的な目標と期限がある私にとって、オペレーティング システムで「ミス」をする余裕はありません。さらに悪いことに、ラップトップを購入して以来、エコシステムの全体的な安定性が悪化していることです。たとえ初期リリースがまあまあだったとしても、時間の経過とともに安定性と品質が向上することを期待するでしょう。しかし、そうではありません。これは、将来を推定することは厳しい見通しであることを意味します。代替案は、Windows を「敗北」モードで使用するか、Mac を購入して、その購入によってもたらされる経済的 PTSD を味わいながら、ハードウェアとソフトウェアの緊密な統合による真のさらなる利点を味わうことです。

私は長年真剣にやってきたことと同じように、これからも Linux を使い続けるつもりです。唯一の問題は、Linux が私に必要な平和と安定性を与えてくれるだろうかということです。そのためには、タイタンに関する第 8 回、第 9 回、第 n 回の報告を待たなければなりません。余談ですが、Titan はまだ Pro 対応の 22.04 で動作しており、Executive のアップグレード プロセスにバグが多かったことを考えると、24.04 に移行するのは躊躇しています。私は、真の利益が約束されずに、物事がランダムに壊れることをまったく期待していません。これはまた別のレポートでお話します。今のところ、私はかなり憂鬱な気分です。セ・ラ・ヴィ。気をつけて。

乾杯。