ThinkPad A285
AMD Ryzen Pro と Radeon Vega を積んだ ThinkPad。筐体は X280 と同じものだろうと思う。
あちこちが草臥れてきた ThinkPad X250 の後継として導入。思うところあって、Intel の X280 ではなく AMD 機を選んだ。いつものように Linux で運用する。しかし、 現状では Plamo Linux 7.0 を入れることができていない。おそらく NVMe M.2 SSD であることが災いしているのだろうと思われる。（grub 画面までは出るが、起動してくれない。）
一方、ubuntu 18.04.1 LTS は問題なくインストールでき、動作にもほぼ問題は見当たらない（fingerprint は使えてない）のでひとまずは ubuntu でやり過ごすことにしようかと思案中。（仕事場の ubuntu linux 端末環境のチェックにも使えるし。）手を入れれば Plamo Linux も入れることができるハズだが、手を出す時間がほんとないので、遅々として作業が進まない。。。
X280 もそうだけど、SD Card リーダが無くなったのは大きなマイナスだなぁ。いちいち USB 接続のアダプタを持ち歩かないといけないのが極めて面倒。（micro SD の差し込みはあるけど、micro SD とか使わんよ…）
（2019/03末）職場の端末群（ubuntu 18.04）の環境整備もほぼ片付いたし、Plamo 7.1 テスト版を入れてみる。→ 後日 Plamo-7.1 を入れ直す。
修正点（ubuntu 18.04 で運用時の話）
２つの大きな問題点あり。resumeからの復帰の問題は解決。amdgpu の方は幾つかの問題が内在していて、そのうちの一つは解決。→ もう一つも解決した。要約すると、linux kernel を 4.20.3 以降、linux firmware を 2018/12/17 以降のものにすればよい。（自前で入れる必要あり）
resume 時の復帰失敗
suspend からの復帰時に止まることがあったが、それは kernel を ubuntu 標準の 4.15.x 系から最新の 4.19.x (ukuu) に上げることで解決した
amdgpu 関連のフリーズ
AMD GPU 周りの問題で、しばらく使っているとマウスカーソル以外が動かなくなる問題は、kernel parameter に
iommu=pt amd_iommu=on iommu=pt amdgpu.dc=1
を加えることで解決したかと思ったが、 グラフィックをグリグリ使っているとまだ固まることが。kernel log を見ると
[gfxhub] VMC page fault (src_id:0 ring:24 vmid:6 pasid:0 .......
の後に
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, ...... [drm] GPU recovery disabled.
となっている。SysRq でコンソールに落ちることができるだけマシだけど。ググると、ゲーマーたちが同じ問題を上げているようだ。Vega 特有の問題かも？
(2019.01.18) ubuntu の linux-firmware 更新で安定したかと思いきや、、、また固まった orz... system log を見てみると
Jan 18 10:22:09 a285 kernel: [68363.496035][drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=1840650, emitted seq=1840653 Jan 18 10:22:09 a285 kernel: [68363.496043] [drm] GPU recovery disabled.
となっている。ものは試しということで、linux-firmware を取ってきて amdgpu 周りだけ手で入れ替えてみる。なお kernel は ukuu の 4.20 を使っている。
(2019.01.20) 夜、再び固まった。SysRq で止めて再起動すると gdm が暴走。（なんで？）そもそも gdm は使ってないので、runlevel 3 の multi-user モードに変更。
systemctl set-default multi-user.target systemctl get-default # これはモードの確認
日本語入力がうまくできなくなったので、ひとまず元の gdm ログインに戻す
systemctl set-default graphical.target
(2019.01.21) kernel を最新のものにするために build 環境を突っ込む。結局のところ、自分で build しまくることになるのか... ^-^;;; linux-4.20.3 でテスト運用開始。→ 安定した！！！ amdgpu 周りの error も warning も一切でなくなった！
というわけで整理しておくと
linux kernel を 4.20.3 以上（or 4.19.11 以上）にする linux-firmware も git でとってきて差し替える
ことで、amdgpu 周りのフリーズは解決した。amd な方はお試しあれ。（その後もいろいろ amd の中の人による修正が続いているので、最新 kernel & firmware が良いと思います。）
軽微な問題
libinput では trackpoint の動きが良くなかったので、evdev に入れ替えた
apt-get install xserver-xorg-input-evdev apt-get remove xserver-xorg-input-libinput
battery 駆動時に usb デバイスの自動認識がうまく働かない … laptop mode 関連かなぁ
kernel の自前buildメモ
こちらの記事を参考に
必要な環境の用意
apt-get install fakeroot kernel-package git libssl-dev bison flex
kernel source を取得して展開
tar xf linux-4.20.3.tar.xz
中に入って、現在の kernel config をコピー & make oldconfig
cd linux-4.20.3 cp /boot/config-4.xxxxx .config make oldconfig
fakeroot で kernel の deb を作成
fakeroot make-kpkg --initrd --append-to-version=-mybuild kernel-image kernel-headers -j $(getconf _NPROCESSORS_ONLN)
出来上がった deb ファイルはひとつ上のディレクトリ内にある。インストール等は以下のように
dpkg -i linux-{image,headers}-xxxxx.deb
update-grub # grub の更新
package の自動更新抑制
手動で入れ替えたものがある場合、自動更新されると塩梅が悪い。 例えば linux-firmware package を自動更新しないようにするためには
echo linux-firmware hold | dpkg --set-selections
とすればよい。設定状況を見るには、
dpkg --get-selections
自動更新に戻すのなら、
echo linux-firmware install | dpkg --set-selections
とすればいい。
SSD の載せ替え & Plamo-7.1 テスト
ubuntu desktop は今一つ手になじまないし、（職場で整備している）端末環境の ubuntu-18.04 もほぼ安定して ubuntu のテスト環境も不要になったので、SSD を換装して Plamo-7.1 (2019-03-18版) をテストインストールしてみる。使用した SSD は NVMe じゃなくて SATA な m.2 SSD （Crucial MX500）。SATA の方が発熱量が抑えられるからね。
インストールは難なく終了。だが、X を立ち上げようとすると xfce4 がコケる。twm だと大丈夫。まだろくに検証していないのでわからないが、些細な原因かもしれないし、AMDGPU 関連の問題かもしれない。→ こじまさんからのアドバイス通り、libdrm と mesa を新しいものに入れ替えたら問題解決。（感謝！）
それから ubuntu での経験から、 linux-firmware を最新のものに。kernel はほぼ最新なのでひとまずそのまま。これで X 周りは安心して使えるようになるはずだ。
データを移して、ちまちまチューニング中。いい感じになりそうだ。やはり plamo が手に合うなぁ。
追加インストールメモ
jhead, exiftool, geeqie, powertop、これらは必要なのでただ追加で入れただけ
esecanna + vje delta を uim-canna で使おうとしてみたが freeze してしまう。32bit library は導入済み、vjed は問題なく動作しているし、esecanna server も動いているのだが...。まぁ、vje の変換はあまり賢いとは言えないので、vje を使うのは止めて fcitx+mozc で運用することにする。
fcitx + mozc で運用する場合に、変換入力中の文字背景が黒くて読みにくい問題があったが、 xfce4 の「外観」(xfce4-appearance-settings) でスタイル変更することで解決。
scroll bar
gtk+-3.6 以降はスクロールバーをクリックした際の動きが変わったので、以前と同じようにするためには、gtk+-3.0 の settings.ini （個々のユーザなら ~/.config/gtk-3.0/settings.ini ）に以下のように記述すればよい
[Settings] gtk-primary-button-warps-slider = false
参照：Arch Linux wiki https://wiki.archlinux.jp/index.php/GTK%2B#.E3.82.B9.E3.82.AF.E3.83.AD.E3.83.BC.E3.83.AB.E3.81.AE.E6.97.A7.E5.BC.8F.E3.81.AE.E6.8C.99.E5.8B.95
gimp-2.10.x の exif データ破壊問題
gimp-2.10 にはつまらない（が、かなり困る） bug が存在する。jpeg ファイルを開いて、export した場合に exif 内容が破壊されることがある。 gimp-2.8 ではそのような問題は一切ない。（確認済み）
exif の Camera make タグに PENTAX があると exif データが吹っ飛ぶ という話が出ているようだが、ここの話はたぶんちょっと間違っている。 exif データを処理する際に libexiv2 などのライブラリを使っているようだが、そこの処理に問題があって、exif タグの key と data の対に不整合が生じている。そして場合によっては exif データの大半が吹っ飛ぶ、というのが真相と思われる。
ちなみに PENTAX KP の JPEG ファイルで確認。Camera make tag は Ricoh Imaging であるが、ファイルによって exif が吹っ飛んだり、exif データは残っているがが key と value に不整合が発生するという現象が発生する。（画像ファイルによって現象が異なるので、十中八九アプリ側の内部処理ミスだと思いますね。）
（暫定的対処）内部処理がヘボであるならば、ある程度読みやすい形にしておけば良かろうと考えた。そこで幾らか試してみたところ exiftool を利用して exif データを幾らか削っておけばトラブルは生じないようなので、そういう処理をして gimp に渡す script を書いた。
この件、 gimp-2.10 か libexiv2 か libgexiv2 のいずれに問題があるのか調べて開発側に報告しておきたいところだが、調べてる時間がないんだよなぁ。。。
そもそも 2.8 と 2.10 で何が違うかと思ったら、そもそも使っている library が違ったのか。2.8 系は libexif を、2.10 系は gexiv2 library を使ってるや。
Plamo-7.1
パーティションを別に切って、Plamo-7.1 リリース版を入れる。設定は上（Plamo-7.1 テスト版）と同様。
インストールしたもの
- audacious-3.10.1 & audacious-plugins-3.10.1
- gnuplot-4.6.7 （gnuplot-5.2.x の epslatex に bug があったので、影響のない gnuplot-4.6 系を入れる）
- geeqie
- jhead
- Image-ExifTool
- powertop
- evince-3.28.5 (ps を表示できなかったので、backend の libspectre を事前に入れ、evince を入れる)
- eb-4.4.3 & pangox-compat-0.0.2 & ebview-0.3.6.2
- yatex1.81
省電力設定 TLP
GitHub: https://github.com/linrunner/TLP
ここが参考になるかも Ubuntuで省電力設定「TLP」編
powertop も併用しながら少電力化を試しているが、イマイチ。 amdgpu 周りの powersaving がうまくいってない気がする。amdgpu 周りのチューニングを調べてみる必要があるかな。
いやいや、amdgpu じゃなくて、Wi-Fi の RTL8822BE が犯人か？これ。6W くらい使ってるぞ。まぁ、Staging driver だしなぁ。。。（powertop の表示が変な気がする（ズレてる？）のでもうちょっと調べてみないと確定できないが）
memory suspend 復帰時のフリーズ
memory suspend から復帰 resume する際に、固まることがある。現在の kernel は 4.19.65 で運用中。ちなみに、いつも固まるわけではない。特定の module に問題がある可能性もあるが、同様の報告がいくらか散見されるところをみると、kernel の bug の可能性もありうる。kernel 5.x で解決している（？）という話もあるので、試してみることにしよう。→ kernel 5.2.9 + 最新 firmware で起動したところ、Xorg で画面が崩れる... orz...
5.x にするのは pending にして、疑わしい kernel module を suspend 前に unload することにしてみる。とりあえず、realtek の Wi-Fi module r8822be と、xhci_pci を外すようにしてみた。どうなるかな？ → 塩梅がよくなったような。suspend 時にこの２つの module (r8822be, xhci_pci) を外すようにしてから、resume 時に固まっていない。もうしばらく様子をみてみよう。（現在の kernel は 4.19.67 ） → あれから全く固まることが無くなった。間違いなくこの 2つの module のどちらかが犯人だったのだろう。r8822be は Staging な driver module なので（しかも realtek だし）、こっちが犯人の可能性が高い。 というわけで、suspend 時には r8822be を外す、というのが解決策だろう。
Keyword(s):[ThinkPad] [Linux]
References:[Linux] [ThinkPad X390]