Thinkpad x13 gen3 amd を Linux で使っているとフリーズする

2022年からずっとArch Linux で使用してきたが、この4月ぐらいから急にフリーズするようになった。

ウェブブラウザを使っているときにフリーズしたり、ターミナル呼び出してしばらくしてからフリーズしたりと、全く原因がつかめん。

フリーズするとキーボードの入力を受け付けず、capslock が切り替えられない時点でお察しだが、tty も切り替えられず、REISUB も効かない。電源ボタン長押ししかない。ここまで深刻なら、カーネルが原因だと思い、カーネルをダウングレードしても、LTS にしても、効果がない。う〜ん……わかんねぇ。

ええ機会やし、環境ファイルがなにか悪いことをしていることにし、デュアルブートしている Windows もそろそろ入れ替えるか。Arch で Xfce という異端児?だったが、ついでにWaylandにしてしまおう。

心機一転、Windows11 25H2 から全部入れ直してみたが、意味がなかった。やはり特定できないタイミングでフリーズしてしまう。なんでや。そんなところの再現性は求めてないんや。でもそうだよな。Linux は残酷なまでに正直なんだ……環境ファイルもテキストベースで書いたとおりにしか動かないんだ……。

ディストリビューション変えてみるか……?試しに CachyOS は……あかん。そりゃそうだよな、一緒やもん。

う〜ん……ど定番すぎる Ubuntsu は避けて、MX Linux の LXQt で入れてみる……あかん、フリーズする。これが再現性のある方法でフリーズするならまだ緒もつかめる気がするのだけれど、しばらく端末から手を話したときに発動したり、ブラウザでページスクロール中に発動したりと、トリガーが全くわからん……なんだろう。

もしかしなくてもハードウェアがぶっ壊れたか?メモリとか終わった?今の時期、パソコンなんて買えないよ。でも、Windows は何も問題ないんだよなぁ……memtest もパスして、BIOSからのテストもパスする。腑に落ちん。

MX Linux で Xfce で入れてみよう……あれ?フリーズしない?わけがわからないよ。なんで?全ては己のトラブルシュート能力がゴミの可能性が。無能と言われているみたいで、これはきっつい。

MX Linux で様子を見ていると、気のせいかもしれんが、特に処理を走らせた覚えがないのに、なんか排熱が熱くないか?MX Linux にある Hardinfo2 を見てみると、何も作業をしていないのに、CPU 温度が 78℃ 超えてる。んん?おかしくない?グリスアップ時期にしても早くねぇ?

Windows11 に戻って、HWinfo で確認すると、45℃くらいまで下がっていった。良かった良かった……じゃねーよ、そうはならんやろ。

これで確定してしまった。ハードウェアがぶっ壊れているのではない。原因は Linux 側……さぁ地獄の始まりだ。Linux を使いたければ、原因を特定しなければならない。

とは言っても、カーネルドライバで確定なんだよなぁ……初めての遭遇だよ。

MX Linux 側に戻り、ターミナルを立ち上げて htop をみてみると、CPU 3 の占拠率のみが50%-80%の間を行き来している。起動したばかりで、ブラウザしか起動していないのに、やっぱり変だ。

プロセスで CPU 占拠を特定する。

$ ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head

    PID    PPID CMD                         %CPU

    767       2 [irq/91-nxp-nci_i2c]        30.7

   4136    4135 /app/lib/floorp/floorp --na 12.4

   4467    4240 /app/lib/floorp/floorp -con  4.1

   2897    2747 /usr/lib/xorg/Xorg -dpi $DP  3.9

   4001    3406 hardinfo2                    3.2

   4114    4108 htop                         2.4

   4311    4240 /app/lib/floorp/floorp -con  1.6

……なんか変なやつが居る。

Google 先生に聞いてみると

https://bbs.archlinux.org/viewtopic.php?id=312733

これ当たりじゃね?ハードウェアも同一臭いぞ? dmesg みてみると、

 $ sudo dmesg | grep -i nxp-nci

[    4.820828] nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121

[  289.509086] nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121

あー……嫌な匂いがプンプンするぜ。

とりあえず、その場で外してみてCPU占拠率に影響があるかどうか見てみる。

$ sudo modprobe -r nxp-nci_i2c nxp-nci

$ ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head

    PID    PPID CMD                         %CPU

   4136    4135 /app/lib/floorp/floorp --na 24.1

   4638    4240 /app/lib/floorp/floorp -con  5.0

   2897    2747 /usr/lib/xorg/Xorg -dpi $DP  3.9

   4001    3406 hardinfo2                    2.8

   4114    4108 htop                         2.5

   4467    4240 /app/lib/floorp/floorp -con  2.4

   3369    3117 xfwm4                        1.3

下がった。マジか。

ハードウェアを正常に読み込めないと、こんなこと起こるのか。Linux 側で使わないからと、放置してたんだが……駄目なんかい。

再起動のたびにコマンドを入れられないので、ブラックリストに追加しよう。

sudo vi /etc/modprobe.d/blacklist-nfc.conf

追記する内容は、

blacklist nxp-nci_i2c
blacklist nxp-nci

初期RAMディスクを更新して

sudo update-initramfs -u

再起動後、

sudo dmesg | grep -i nxp-nci 

でロードされていないことを確認、CPU占拠率も確認。

Windows よりカウンタが減った。やっと以前の快適環境が戻ってきた、か?原因が特定できたのは曲がりなりにもトラブルシュートの間に動いてくれていた MX Linuxのおかげだ。Arch は tty に切り替えることもできなかったから突破口すら開けなかった。あーよかった。最悪、WSL まで覚悟していたところだった。

せっかくだし、このまま MX Linux を使うことに……したいが、pacman に慣れてしまうと、あれがない、これがないになってしまう。

それと。
言ってはならんことだが、最初の段階でプロセス確認してりゃなぁ……。視野狭窄って怖いね。

コメント

このブログの人気の投稿

ナンバープレートのボルト交換

Arch Linux - linux-firmware を分割したから