7月 292021
 

前回のエントリでは Let’s Note CF-SZ5 の中古を購入して FreeBSD/amd64 13.0-RELEASE をインストールしました。そして、無事に動作して、なんちゃってな suspend/resume が動作しているところまで書いています。

 
さて、suspend/resume ですが、ports-CURRENT を追いかけていると、以下をインストールした辺りで正常に suspend/resume が動作するようになります。

  • drm-fbsd13-kmod-5.4.92.g20210720_1
  • mesa-dri-21.1.5
  • mesa-libs-21.1.5

もう、 /etc/rc.resume の中に色々書く必要ないです。

/etc/sysctl.conf に、以下の設定を記載すると、フタの開け閉めで suspend/resume ができるようになります。

# suspend/resume
#hw.acpi.lid_switch_state=NONE
hw.acpi.lid_switch_state=S3
hw.pci.do_power_suspend=0
hw.acpi.lid_switch_state=S3
hw.acpi.power_button_state=S5

 
すごいことですねぇ。 NotePC でバリバリ利用可能な FreeBSD の完成です;-)。

 
と、いうことで、ここからが本題。

以前のエントリでは Let’s Note のクルクル回すタッチパットでスクロールできない。と、書いていましたが、こちらも問題解決できたので、追加でエントリ書いてみたいと思います。

 
インターネット上で色々探してみると古い FreeBSD のバージョンでは特に気にすることなく動作していたみたいですが、12 系リリースの辺りからクルクルホイールさせるためには色々とワザが必要なって来たようです。

まず、カーネルがブートしたときの psm の状況を見てみましょう。
あ、このとき、/boot/loader.conf には以下のように設定してあります。

# psm/sysmouse
hw.psm.synaptics_support=1
hw.psm.trackpoint_support=1
#hw.psm.elantech_support=1

 
hw.psm.synaptics_support=1 が記載してあります。

それでもブート時には以下のように表示されます。

$ dmesg | grep psm
psm0:  flags 0x1000 irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0.
psm0: model Generic PS/2 mouse, device ID 0

 
このようになっていた場合、どう xorg の synaptics 設定を書いてもクルクルホイールできません。ただのタッチパッドの動作になります。この状態では、とあるおまじないをする必要があります。

おまじないが有効化されるとこのようになります。

$ dmesg | grep psm
psm0:  flags 0x6000 irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0.
psm0: model Synaptics Touchpad, device ID 0

 
一番最後が model Generic PS/2 mouse か model Synaptics Touchpad の違いです。

ではどのようにすると model Synaptics Touchpad になるのか?

ソースコードをいじる必要があるんですねぇ・・。
いやぁ、ようやっと、ネタを見つけた。と、いうか・・。

https://github.com/wulf7/iichid/issues/53

pciconf -lv したときに ichsmb0 があると良いのですが・・。 kldstat で ichsmb.ko がロードされているか確認してみてください。

さて、上記 URL を確認してみると、タッチパッドが SMBus 経由で動作するかもしれん。と、いうことで /usr/src/sys/dev/atkbdc/psm.c を書き換えてみてください。と記載されています。

--- psm.c.orig  2021-04-13 10:02:53.550143000 +0900
+++ psm.c       2021-07-28 10:23:34.503022000 +0900
@@ -6315,7 +6315,7 @@
                    active_ports_count);
 
        /* psm has a special support for GenMouse + SynTouchpad combination */
-       if (active_ports_count >= 2) {
+       if (active_ports_count >= 1) {
                for (port = 0; port < KBDC_AUX_MUX_NUM_PORTS; port++) {
                        if ((active_ports_mask & 1 << port) == 0)
                                continue;

 
(active_ports_count >= 2) の部分を 1 に書き換えたあと、カーネルを作り直して再起動してると・・。
おやまぁっ!! psm0 が model Generic PS/2 mouse から model Synaptics Touchpad になったではありませんかっ!!

最近の Let’s Note のタッチパットでクルクルを有効化させるためにはコードを修正する必要がある。と、いう感じでしょうか。

 
あとは xorg の設定をしていきます。僕の場合、/usr/local/etc/X11/xorg.conf.d/70-synaptics.conf を用意しました。

Section "InputClass"
    Identifier          "touchpad catchall"
    Driver              "synaptics"
    MatchIsTouchpad     "on"
    MatchDevicePath     "/dev/input/event*"
    Option              "CircularScrolling"     "1"
    Option              "CircularScrollTrigger" "0"
EndSection

 
/dev/input/event は何番になっているか? とかは libinput list-devices コマンドが良い感じかも。

あと、他の設定はどこに書いたら良いのか・・。僕の設定は /etc/sysctl.conf に書いていました。色々やったけど、動かなかったので /etc/sysctl.conf に書いていた。と、いう状態でしょうか・・。

# synaptics mouse 
hw.psm.synaptics.vscroll_hor_area=1300
hw.psm.synaptics.min_pressure: 16
hw.psm.synaptics.max_pressure: 220
hw.psm.synaptics.max_width: 10

 
こんな設定が入っていましたf(^^;;。これが効いているのかは sysctl で確認。と、いう感じです。
あと、KDE5 を利用している場合「KDE システム設定」の「入力デバイス」→「タッチパッド」で GUI 的に色々設定できるのでそっちで細かい設定をしたほうが直感的かも。

それにしてもようやっと、ホイールが動作してタッチパッドが動作するようになりました。嬉しいかぎかぎカギリですです。

ホイールクルクル回す他に、二本指で上から下に、もしくはその逆になぞるとスクロールもしてくれます。動作的には ThuinkPad X13 AMD みたいな感じかな。

 
さてと。これで Let’s Note CF-SZ5 はほぼぼカンペキな FreeBSD マシンになりました。 ThinkPad X13 AMD の Renoir が今でもまともに動作しないので、どうしてもこの NotePC が FreeBSD のメイン機として活躍していきそうな気配です。

 
あと、この NotePC は vPro が動くみたい(さすがはビジネス向けっ!!)みたいですが、 FreeBSD はそもそも vPro が動作しないようです。

6月 192021
 

最近はコロナの影響で非常事態宣言が発令されている状況において、皆様、いかがお過ごしでしょうか。
僕は飲み屋さんに行くことができないので、その分飲み代が現金として溜まってきている。みたいな感じかなぁ。

と、いうことで Let’s Note CF-SZ5 の中古を購入してしまいました。型番的には CF-SZ5PDY6S です。
中古ですが、状態が良く A ランクで、届いたのを見たら確かにきれいです。傷らしいのはロック穴の周りに 2,3 個ある程度で他の部分は非常にきれいでした。液晶も無事です。
型番的に CF-SZ5PDY6S という Let’s Note CF-SZ5 ですが、当然、企業向けモデルで、定価だと 30 万 yen くらいらしいですが、これを税込み 41,000yen で購入しました。 最近、アキバでも中古 PC がたくさん出回っているようですが、それに比べるとちょっと高いかな? まぁ、その分程度が良いのでちょっと多めに出した。と、いう雰囲気で;-)。

スペック的にはこんな感じ。

  • OS: Windows10 Pro
  • CPU: Intel Core i5-6300U (2Core/4Thread)
  • Mem: 8GB 増減不可
  • SSD: M2 2280 SATA 256GB
  • 光学ドライブ: 無し
  • SD カードスロット: 有り (SDHC)
  • NIC: if_em and if_iwm

 
約一年くらい前に ThinkPad X13 AMD が届いて、苦労して FreeBSD をインストールしつつもなんとか使っている状態ですが、ちょっと古い PC で動かすと、もっと楽できるんじゃね? みたいな・・。

例えば ThinkPad X13 AMD は default で NIC が付いてないので USB NIC を接続したり suspend/resume できなかったり、AC アダプタ引っこ抜くとリブートしてしまったり・・。やっぱりまだまだ FreeBSD を動かすにはちょっと早い。でもって、 AC アダプタ引っこ抜くと再起動してしまうので、外に持ち出すことができない・・。はぁ・・。

 
と、いうことで、今回購入した Let’s Note CF-SZ5 は FreeBSD 専用機です。

まず、届いた直後にインストールされている Windows10 Pro のライセンスキーをひっこ抜きます。その後、リカバリーイメージを作成して Windows10 の基本的なバックアップは終了。

 
次に FreeBSD/amd64 13.0-RELEASE をインストールです。 SSD が 256GB しかないのでマルチブートはしません。 FreeBSD 専用機です。
FreeBSD インストール時には何も意識することなく、Windows パーティションもサクっと、消してインストールします。

1. UEFI (BIOS) の画面でセキュアプートをオフ
2. 13.0-Rの ISO イメージを UEFI モードで USB メモリに書き込みインストール
3. Windows のパーティションは全て削除
4. FreeBSD のインストールだよん

 
で、無事にFreeBSD/amd64 13.0-RELEASE のインストールが完了。 ports から KDE5 をインストールして環境を整えて無事にシューリョー。マルチブートとか気にしなくて良いのでインストールは非常に楽です。

 
Let’s Note CF-SZ5 は 2016 年の NotePC なので、ちょうど BIOS から UEFI へと切り替わる過渡期で、BIOS 設定でも UEFI と BIOS の両方有効にできます。 ThinkPad X13 AMD には既に BIOS の機能が無いことを考えると中途半端な感じですね。

 
インストール後の機能については以下な感じ。

  • SSD は M2 でありながら SATA 接続なので /dev/ada0 で認識します
  • SD カードスロット は sdhci で認識して SD カードは mmc0 もしくは mmcsd0 で認識します
  • NIC は em0 と iwm0 として認識し WiFi チップは Wireless 8260 として認識します
  • i915kms.ko を利用しているので xrandr で確認するとディスプレーは eDP-1 で認識されるので brightness が利用できます
  • 音はスピーカ・ヘッドホン共に出ます。Fn キーでボリュームも調整できます

 
さすがに古い PC はと、いうか Intel 系 CPU 搭載の NotePC はデバイスが色々動いて良いですねぇ;-)。

今回は graphics/intel-backlight はインストールしていません。 xrandr(1) とか backlight(8) で画面の明るさを変更することができます。

ここまで動作すると、ほぼ ThinkPad X13 AMD と機能的には同等ですね。 AMD 最新 CPU に対してよくやっているなぁ。と、いう感じかな;-)。

 
と、いうことで肝心の xorg について、インストールしたドライバは以下の通り。

xf86-input-evdev-2.10.6_6 X.Org event device input driver
xf86-input-keyboard-1.9.0_4 X.Org keyboard input driver
xf86-input-libinput-0.30.0_1 X.Org libinput input driver
xf86-input-mouse-1.9.3_3 X.Org mouse input driver
xf86-input-synaptics-1.9.1_8 X.Org synaptics input driver
xf86-video-scfb-0.0.5_2 X.Org syscons display driver
xf86-video-vesa-2.5.0 X.Org vesa display driver

 
xf86-video-intel はインストールしません。グラフィックスドライバは以下を利用します。

drm-fbsd13-kmod-5.4.92.g20210419 DRM modules for the linuxkpi-based KMS components
gpu-firmware-kmod-g20210330 Firmware modules for the linuxkpi-based KMS components

 
なので xorg.conf の Section “Device” で Driver “intel” な設定は無いですね。自動的に設定される modesetting になります。
/etc/rc.conf に以下の設定を書くだけです。

kld_list="i915kms.ko"

 
そして、/boot/loader.conf は以下のような感じ。ちょっと長いかな。

#
##
#
kern.vty=vt
hw.vga.textmode=1

#
## ipfw
#
net.inet.ip.fw.default_to_accept="1"

#
## ACPI
#
#acpi_video_load="YES"
acpi_panasonic_load="YES"

#
## psm/sysmouse
#
hw.psm.synaptics_support="1"
hw.psm.elantech_support="1"
hw.psm.trackpoint_support="1"

hint.psm.0.flags="0x6000"

#
## Realtek and Intel wifi license
#
legal.realtek.license_ack="1"
legal.intel_iwm.license_ack="1"

#
##
#
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

coretemp_load="YES"

ichwd_load="YES"
smb_load="YES"

linux_load="YES"
linux64_load="YES"
linux_common="YES"
linprocfs_load="YES"

nfsclient_load="YES"
nfslockd_load="YES"
krpc_load="YES"

mem_load="YES"
io_load="YES"
aio_load="YES"

wlan_load="YES"
wlan_xauth_load="YES"
wlan_wep_load="YES"
wlan_tkip_load="YES"
wlan_ccmp_load="YES"
wlan_amrr_load="YES"

firmware_load="YES"
pchtherm_load="YES"

if_iwm_load="YES"
iwm8000Cfw_load="YES"

sound_load="YES"
snd_hda_load="YES"

#ipl_load="YES"
#ipfw_load="YES"

accf_http_load="YES"
sem_load="YES"

evdev_load="YES"
uinput_load="YES"
cuse_load="YES"

 
さてと。これだけ設定して必用な機能がほぼ動作しています。

AC アダプタ抜いてもリブートすることはないです。と、いうことは ThinkPad X13 AMD での問題点は個別にインストールした amdgpu.ko と、いうことになります。確かに /etc/rc.conf に kld_list=”amdgpu.ko” と書かない場合 (それはつまりは scfb で Xorg を動かす場合と、いうことになります) には AC アダプタを抜き差ししてもカーネルパニックになることはありません。

 
さてと。今回の Let’s Note CF-SZ5 ですが、一応、強引に suspend/resume まで動くようにしました。

FreeBSD 13.0-RELEASE は基本的に suspend はするが resume しなかったり resume したとしても画面がブラックアウトしてしまい、リモートから ssh して再起動することにより復活する。と、いう感じです。
基本的に acpi_video.ko は 13.0-RELEASE ではもう利用することはできません。 hw.acpi.reset_video=”1″ ももう使えません。

 
ただ、前のエントリでデスクトップ機が suspned/resume するっ!! と書いています。実際に結構良いあんばいで利用しているんですけども。Xorg は死んじゃうんだけど、 service sddm restart すると復活する。

では i915kms.ko 使っている場合も強引にやったらどうなるんだろう? と・・。

と、いうことで試した結果、 suspend/resume がまんまとできるようになりました;-)。以下の文字列を /etc/rc.resume の最後の exit 0 の上に書いてください。

#
service sddm stop
sleep 2
kldunload i915kms.ko
sleep 2
kldload i915kms.ko
sleep 2
service sddm restart

 
僕は KDE5 を利用しているので、ログインマネージャには sddm を利用しています。resume 後にそれを stop します。次に i915kms.ko をロードし直します。これがキモですっ!! これで X というか、画面 (tty というか vt のコンソール) が戻ってきます。そして再度 sddm を起動します。

suspend 前の画面の情報を引き継ぐことはできませんが、 suspend したあと OS 自体を再起動することなく利用を再開できるので、まぁ、なんとかなりそうです。(妥協的な部分ではありますが・・)。

あと resume したあとタッチパッドが利用できなくなるので /etc/loader.conf に hint.psm.0.flags=”0x6000″ の設定が必要です。

 
と、まぁ、ここまでで、ほぼ完璧に FreeBSD/amd64 13.0-RELEASE が動作しました。ただ、僕的一点困ってることがあります。調べても解決策が見つかりませんでした。

Let’s Note と言えば、タッチパッドをクルクル回すことによりスクロールすることが名物でありますが、その設定がどうにもわかりません。どなたか、現在タッチパッドをクルクル回してスクロールできている方がいましたら、その設定方法を教えて頂けませんでしょうか。

suspend/resume できるワザ書いたので、情報交換。と、いうことで;-)。よろしくおねがいしますぅ。

 
さてと。これで、持ち出せる FreeBSD が手元に準備できた。

この間、仕事でデータセンタに行ってパケットキャプチャする必要に迫られていんですよぉ・・。

Let’s note CF-SZ5 は軽いし NIC 付いているし移動には非常に良い感じ。 ThinkPad X13 AMD は 8Core 16Thread なので、ports のコンパイルにはモッテコイな状態です。今後は二台を上手に使い分けて FreeBSD を楽しみたいところです;-)。

5月 242021
 

前回は FreeBSD/adm64 13.0-RELEASE にして、drm-fbsd13-kmod を gitHUB から持ってきてインストールしたら AMD Ryzen 7 PRO 4750U の GPU である Vega10 が amdgpu として動き出した。と、いうところで終わっています。

あ。そーそー。 xrandr で eDP として認識されたのでバックライトも動作するようになった。と、書いたところで終わっていますね。

今回はその続きからです。

まず、バックライトについてですが、コマンド的には backlight (8) になります。こいつのオプションはすげーですぜ。明示的に明るさを指定するパターンと、ちょっとずつ明るくもしくは暗くしていくオプションがちゃんと用意してあります。

$ backlight -h
Usage:
        backlight [-f dev]
        backlight [-f dev] -i
        backlight [-f dev] <percent>
        backlight [-f dev] incr|+ <percent>
        backlight [-f dev] decr|- <percent>
$ backlight incr 20
$ backlight decr 20

 
backlight incr 20 と打つと、まぁ、雰囲気的には 20% ずつ明るくなって、 backlight decr 20 と打つと、こちらも雰囲気的に 20% ずつ暗くなります。

おやまぁっ!! つまりは acpi_ibm.ko で Fn キーにコマンドイメージをそのまま割り当てれば、 hw.acpi.video.lcd0.brightness へ値を食わせてあげるより楽じゃね? となるのであります。

僕の場合は Plasma5 KDE (この書き方初めてだ。普段は『KDE5』とか書いちゃうんだけど;-) を利用しているので acpi_ibm.ko を利用せずとも、ショートカットを設定すればサクと明るさが変えられるのでありますっ!! すげーっ!! すげーよっ!!

 
と、いうことで『KDE システム設定アプリ』を起動します。

[ショートカット] → [カスタムショートカット] と来て左下に [編集] というのがあるので [New] (これは翻訳されてない;-) → [グローバルショートカット] → [コマンド/URL] を選択します。

すると「名前」のところに「新しいアクション」が青くなるので、任意の文字列を指定します。

僕の場合は以下のようにしました。

そして、[トリガー] タブを開いてキーを指定します。 Fn キーも指定できます。がっ!! LCD の明るるさ調整のペイントがある F5 と F6 には Xorg 的にキーが割り当てられていないようです。 xev で F5 ・ F6 を押してもキー番号が表示されません。あらら・・。

しょうがないので僕の場合は Ctrl + ボリュームアップ と Ctrl + ボリュームダウン にキーをバインドしました。

そして、[アクション] タブを開いて [コマンド/URL] のところに上のコマンドイメージを設定してあげます。

Ctrl + ボリュームアップ を数回押すと 20% ずつ画面が明るくなって Ctrl + ボリュームダウンを数回押すと 20% ずつ画面が暗くなっていきます。いやぁ。思い通りの動作です。キーバインドがプリントされているのとはちょっと違うのが悲しいですが、やりたいことはできました。パチパチパチ。

 
これで、ネタは一個おしまい。

 
さてと。前回のエントリの下のほうに以下のように書きました

  • Realtek のカードリーダ (RTS522A) が rtsx0 で認識して動くようになりました。
  • 音はスピーカーからもヘッドホン端子からも出ます。
  • CPU の温度が拾えるようになりました。
  • Intel Wi-Fi 6 AX200 はまだ動きません。
  • Suspend して Resume で起きても動きません。電源ボタン押すと shutdown はしてくれるようですが、ネットワークは利用できません。

 
そして、

次は suspend/resume にトライだぁ;-)。

と・・。

 
suspend/resume はまるで動作しなくなりました。 suspend してくれます。そのあと resume してくれなくなりました。 12.2-RELEASE の頃は resume 後、画面は真っ暗たけどネットワークが利用できるので ssh してリブートしたり、電源ボタン押すとそのまま poweroff してくれましたが、そういったことはなくなり resume した段階で、シューリョー・・。

あらま・・。

あと、驚いたのが AC アダプタ引っこ抜くとカーネルパニックします。なので FreeBSD を起動したら電源ケーブル (USB Type-C) を引っこ抜くことはできません。

そして poweroff の状態で電源ケーブルが抜かれているときに電源ボタンを押すと FreeBSD は無事に起動します。そして、電源ケーブルを接続するとカーネルパパニックで落ちます。

ACPI の電源周りのコードがまだまだ怪しいのだと思います。お気をつけください。

 
ただ、 13.0-RELEASE にしたおかげで良いこともありました。なんとっ!! デスクトップ機が suspend/resume できるようになりましたっ!!

僕の場合、『Sandy Bridge おじさん』ではなく『AMD FX おじさん』とでも言いましょうか。今でも PRIMERGY MX130 S2 を利用しているわけですが、この PC は UEFI では無く BIOS で動作しています。
なんとっ!! この PC で動作する FreeBSD/amd64 13.0-RELEASE はちゃんと suspend/resume してくれます。ただ、グラフィックスカードが GeForce 210 で、ドライバ的には x11/nvidia-driver-340 を利用しているので resume での復帰後、画面がブラックアウトしてしまいます。が、しかし、これは service sddm restart すれば復活します。

他の AMD 系の古めのグラフィックスカード Radeon HD 5450 辺りを利用するとどうなのかな? とも思うのですが、手持ちがありません・・。 Radeon HD 5450 はその昔利用していたので Xorg が動作することは知っていますが。

 
と、いうことでまさかまさかのデスクトップ機で suspend/resume できるようになっているとは知りませんでした。

 
さてと。話をもとに戻して ThinkPad X13 AMD での FreeBSD/amd64 13.0-RELEASE ですが、上にもある通り Intel Wi-Fi 6 AX200 はまだ動きません。 Windows10 では AX200 を利用していて、 FreeBSD では USB の if_rtwn.ko を利用していました。 Amazon で見つけた RealTek の 802.11a で接続できる USB ドングルを利用していました。

で、ふと思いました。『Intel AX200 使おうとするからダメなんじゃね?』と。では FreeBSD で動作する Intel の WiFi アダプタに交換してしまえーっ!! と。

と、いうことで、調達したのはこれ。

Intel Wireless-AC 9260 で、ウェブで最安値を探していたらメルカリで未使用品が売っていたので、購入してみました。 1,780yen でした。それなりに安い値段でゲットできてホッとしました。いまどき FreeBSD でも利用できる RealTek の 802.11a 用 USB ドングルでも 2,000yen 前後するので、それなら内蔵のほうが良いですねぇ。みたいな。

ただ NotePC の、オンボードに接続されている WiFi アダプタって何回か交換したことあるのですが、別のに換装して電源入れた段階で BIOS が『そんなパーツは知らんっ!!』とか言って PC 自体起動してくれないことを何回か経験したことがあります。

今回もそーなるかな? とか思い下調べしてみると、どうやら ThinkPad X13 は Intel Wireless-AC 9260 は行けるっぽい雰囲気。で、もし動作しなくても最近はお買い物に利用していなかったメルペイの残高で、そこはかとなく安い値段が提示されていたので『行くべっ!!』って感じでした;-)。

 
NotePC の裏ブタ開けて、無線モジュール交換して電源入れたら特に BIOS (今は UEFI か) に怒られることもなくスルスルっと起動しました。
まずは Windows10 で認識して速度計測してみると網内では 500Mbps 程度。 FreeBSD を起動して計測してみると 20Mbps 程度の速度が出たので、まぁ、ヨシとしておきました。 Windows のドライバと FreeBSD のドライバの性能の差がこれだけある。と、いうことですが、確か、シャアは「ドライバの性能の違いが、戦力の決定的差ではないということを・・・教えてやる!」と、言っておりましたなぁ;-P。

pciconf -lv で見るとこんな感じ。 iwm9260fw.ko と if_iwm.ko が kldload され、簡単に動作しました。

iwm0@pci0:2:0:0:        class=0x028000 rev=0x29 hdr=0x00 vendor=0x8086 device=0x2526 subvendor=0x8086 subdevice=0x0014
    vendor     = 'Intel Corporation'
    device     = 'Wireless-AC 9260'
    class      = network

 
余った Intel Wi-Fi 6 AX200 は FreeBSD でドライバが書かれるまで御蔵入りか、メルカリで、今度は売ってしまうか;-)。

それにしても、今まで USB WiFi を接続していた USB ポートがこれで一個空いたことになります。いやっほーっ!!

 
とまぁ、こんな感じでコツコツとやっていくうちに、だいぶベースシステムが動作してくれるようになりました。購入からそろそろ一年が経とうとしているところで、保証も切れていく雰囲気ではありますが・・。

あとの残りは本当に suspend/resume のみになった感じですが AC アダプタを抜き差しするとカーネルパニックするデグレード部分は今後、どうなっていくことやら・・。

それにしても、ほぼ毎日触っている ThinkPad X13 AMD ですが、ほんと FreeBSD でだいぶ動作するようになったことは嬉しいことです。

 
次回、この系統のエントリをかくときは壊れたときか suspend/resume が動いたときだと思われます;-)。

 
あ。思い出したように加筆しておきます;-)。

Windows10 側で FF14 のベンチマーク取りました。そのときのキャプチャをつけておきすますー。

ベンチマーク取ったとしても、ゲームはやらないんですけどね・・。ゲームするなら llvm11 とか rust のコンパイルしてかかった時間をベンチマークとして計測したほうが楽しいよねぇ。みたいな;-P。

4月 142021
 

以前のエントリで「ThinkPad X13 AMD で利用する FreeBSD。」と、いうのを書きました。このときに利用した FreeBSD のバージョンは FreeBSD/amd64 12.1-RELEASE でした。その後 FreeBSD/amd64 12.2-RELEASE が出たときに試しましたが、やはり Renoir は認識せず、 xf86-video-scfb を使い続けていた状態なのでありました。

 
途中 13-CURRENT も試したりしましたが、カーネルと drm-kmod 辺りの相性が悪く、カーネルパニックになったりしてそこはかとなく悲惨な状態だったので利用を断念して RELEASE バージョンに戻した。と、いう雰囲気だったのであります。

さて、「ThinkPad X13 AMD のタッチパッド。」のエントリに書いていますが、drm-v5.0-fbsd12.1.zip を github から拾ってきて、自分でコンパイルして試したりしていますが、2021/04/14 にリリースされた FreeBSD/amd64 13.0-RELEASE は drm-kmod がバージョン 5 になっているのできっと動くだろうと思い早速トライしたのであります。

 
結果としては、見事に玉砕。最新の ports CURRENT でもカーネルパニックが発生しました・・。orz
ThinkPad X13 AMD はコツコツと BIOS (と、いうか UEFI) のバージョンアップがあるのでその影響が出たのかな? と、いう感じがします。

あ。FreeBSD の ports CURRENT を持ってこようとして svn update しようとしても、2021/04/02 で SVN サーバ上の更新が止まっていますね。しょうがないので git 経由 /usr/ports を更新することにしましょう。と、言いつつ、ウェブで色々探したのですが、一発目のコマンドイメージがどこにも書いてないですね・・。 /usr/src を持ってくる方法はあるのですが・・。と、いうことで、一発目に実行するコマンドイメージを探すのにずいぶんと苦労しました。
以下のコマンドを一回だけたたきます。

# cd /usr
# mv ports ports.svn
# git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports
<以下略>

 
二回目以降は

# cd /usr/ports
# git pull
<以下略>

 
これで良いです。
問題なのは、一回目に実行する git clone がどこにも書かれていない。と、いうことですかねぇ・・。

 
と、いうことで最新の ports CURRENT が手に入りました。これで Renoir に必要な ports を各種インストールすることにします。
だいたいこの辺りをインストールすると良いのではないかと思われます。僕の場合は kde5 を利用しているので、関連する ports もドドドと、当然インストールされますが。

  • drm-fbsd13-kmod-5.4.92.g20210202
  • gpu-firmware-kmod-g20210224
  • xf86-video-amdgpu-19.1.0_1
  • mesa-dri-20.2.3_1
  • mesa-libs-20.2.3

 
続いて、各種設定です。

 
1. /etc/rc.conf

kld_list="amdgpu.ko"

 
amdgpu.ko をロードする設定を記載します。

 
2. /boot/loader.conf

hw.amdgpu.exp_hw_support="1"

hw.psm.elantech_support="1"
hw.psm.trackpoint_support="1"

hw.vmm.amdvi.enable=1

vmm_load="YES"
cpp_load="YES"

ntb_hw_amd_load="YES"
amdpm_load="YES"
amdsmb_load="YES"
amdtemp_load="YES"
amdsbwd_load="YES"

smbus_load="YES"
smb_load="YES"
intpm_load="YES"
ichsmb_load="YES"
imcsmb_load="YES"

iichid_load="YES"
iicsmb_load="YES"
iic_load="YES"
ig4_load="YES"

 
hw.amdgpu.exp_hw_support=1 を記載すると amdgpu が使えるようになります。他、デバイスドライバを認識させるカーネルモジュールも書いておきました;-)。

 
3. /usr/local/etc/X11/xorg.conf.d/06-driver.conf

Section "Device"
    Option      "DRI" "3"
    Option      "AccelMethod" "exa"
    Option      "MigrationHeuristic" "greedy
    Option      "TearFree" "On"
    Driver      "amdgpu"
    BusID       "PCI:5:0:0"
EndSection

 
Driver に amdgpu を指定します。 BusID は pciconf -lv | grep vga を叩いたときに表示される番号を指定します。
準備ができたので、再起動して動作を確認して root で startx だぁーーっ!!

が、カーネルパニック・・。 orz
シューリョー・・。 orz

 
そんなばかなぁ・・。とか、思いつつ色々悪あがきで設定を見直してみましたが、ダメでした・・。引き続き /usr/local/etc/X11/xorg.conf.d/06-driver.conf の Driver は scfb の利用を継続・・。

 
と、いうことで、問題は ports の graphics/drm-fbsd13-kmod であることは多分明白です。これは 13-CURRENT をインストールしていたときに確認しています。 drm-fbsd13-kmod が 5.4 なので、もっと新しいバージョンはないのか?

 
https://github.com/freebsd/drm-kmod/tree/5.5-wip

 
こちらです。 5.5 です。他に drm-kmod-5.5-wip-amd と drm-kmod-5.5-wip-amd-pr がありましたが、これらは make が通りませんでした。
drm-kmod-5.5-wip.zip をダウンロードしてきて make && make install します。そのとき、ports からインストールした graphics/drm-fbsd13-kmod がインストールされていても問題ありません。 drm-kmod-5.5-wip を make install して上書きします。

 
これで、準備ができました。上の設定を全て有効にして再起動します。起動したらすかさず startx を叩きます。

ちょっと長いですが、dmesg を貼り付けます。

amdgpu: [powerplay] smu driver if version = 0x0000000a, smu fw if version = 0x0000000e, smu fw version = 0x00374700 (55.71.0)
amdgpu: [powerplay] SMU driver if version not matched
amdgpu: [powerplay] dpm has been disabled
amdgpu: [powerplay] SMU is initialized successfully!
[drm] Display Core initialized with v3.2.56!
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm ERROR :dm_helpers_parse_edid_caps] Couldn't read SADs: -2
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-2
[drm]   - kern.vt.fb.default_mode
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] VCN decode and encode initialized successfully(under DPG Mode).
[drm] fb mappable at 0x460BC7000
[drm] vram apper at 0x460000000
[drm] size 8294400
[drm] fb depth is 24
[drm]    pitch is 7680
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1080 width=1920 depth=32
cmsize=16 size=8294400
pbase=0x460bc7000 vbase=0xfffffe010c9c7000
name=drmn0 flags=0x0 stride=7680 bpp=32
cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
end FB_INFO
drmn0: fb0: amdgpudrmfb frame buffer device
drmn0: ring gfx uses VM inv eng 0 on hub 0
drmn0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
drmn0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
drmn0: ring comp_1.2.0 uses VM inv eng 5 on hub 0
drmn0: ring comp_1.3.0 uses VM inv eng 6 on hub 0
drmn0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
drmn0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
drmn0: ring comp_1.2.1 uses VM inv eng 9 on hub 0
drmn0: ring comp_1.3.1 uses VM inv eng 10 on hub 0
drmn0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
drmn0: ring sdma0 uses VM inv eng 0 on hub 1
drmn0: ring vcn_dec uses VM inv eng 1 on hub 1
drmn0: ring vcn_enc0 uses VM inv eng 4 on hub 1
drmn0: ring vcn_enc1 uses VM inv eng 5 on hub 1
drmn0: ring vcn_jpeg uses VM inv eng 6 on hub 1
[drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0
WARNING !(mask != 0) failed at /usr/local/src/drm-kmod-5.5-wip/drivers/gpu/drm/amd/display/dc/dc_helper.c:53
#0 0xffffffff80e3f803 at linux_dump_stack+0x23
#1 0xffffffff83604b0b at set_reg_field_values+0x4b
#2 0xffffffff83604a83 at generic_reg_update_ex+0x53
#3 0xffffffff8353932c at dp_disable_link_phy+0x5c
#4 0xffffffff8353d176 at core_link_disable_stream+0x416
#5 0xffffffff835a2aac at dcn20_reset_hw_ctx_wrap+0x15c
#6 0xffffffff8355f46b at dce110_apply_ctx_to_hw+0x2b
#7 0xffffffff835469de at dc_commit_state+0x51e
#8 0xffffffff8351a23f at amdgpu_dm_atomic_commit_tail+0x4bf
#9 0xffffffff83302f86 at commit_tail+0x46
#10 0xffffffff83302366 at drm_atomic_helper_commit+0x1e6
#11 0xffffffff833059e9 at drm_atomic_connector_commit_dpms+0xd9
#12 0xffffffff83333e3e at drm_mode_obj_set_property_ioctl+0x15e
#13 0xffffffff8330de6b at drm_connector_property_set_ioctl+0x2b
#14 0xffffffff8332cab2 at drm_ioctl_kernel+0x72
#15 0xffffffff8332ce18 at drm_ioctl+0x2c8
#16 0xffffffff80e3d053 at linux_file_ioctl+0x2e3
#17 0xffffffff80c76ced at kern_ioctl+0x26d

 
一応、認識しました。やったーっ!!
ただし、下のほうの # で始まる行は定期的にログが出力されます。まぁ、しょうがないか・・。

 $ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 293mm x 165mm
   1024x768      60.03 +
   1920x1080     60.03*+
   1680x1050     60.03  
   1280x1024     60.03  
   1440x900      60.03  
   1280x800      60.03  
   1280x720      60.03  
   800x600       60.03  
   640x480       60.03  
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)

 
ディスプレイが eDP として認識されました。と、いうことは xrandr –output eDP –brightness 0.5 も使えて、画面の明るさも変えられるようになりました。

FreeBSD 13.0-RELEASE になって /boot/kernel/backlight.ko というのができて、こいつが画面の明るさを管理しているみたいですが、kldload backlight.ko すると「dmesg 見てみろ。」とか言われいまいち動作していないようです。が、コマンド的に /usr/bin/backlight 30 とかすると画面の明るさが変わります;-)。

 
と、いうことで、Renoir (それはつまりは Vega10 のことですね;-) が無事に動作するようになり、ホッと一安心。そして、画面設定やコンポジタの設定は KDE5 の 「KDE システム設定」から色々できます。嬉しいことです。

 
最後にですが、FreeBSD/amd64 13.0-RELEASE になって、 ThinkPad X13 AMD で Renoir の他に動くようになったモノ、まだ動かないモノなどについて記載しておきます。

  • Realtek のカードリーダ (RTS522A) が rtsx0 で認識して動くようになりました。
  • 音はスピーカーからもヘッドホン端子からも出ます。
  • CPU の温度が拾えるようになりました。
  • Intel Wi-Fi 6 AX200 はまだ動きません。
  • Suspend して Resume で起きても動きません。電源ボタン押すと shutdown はしてくれるようですが、ネットワークは利用できません。

 
こんな感じでしょうかねぇ。それにしても、再度書きますが、 Renoir (それはつまりは Vega10 のことですね;-) が動作するようになったのは嬉しいことです。
AMD Ryzen 7 PRO 4750U で Xorg を動かしたいけど、カーネルがパニックしてしまう。と、いう人は github から drm-kmod-5.5-wip.zip を取ってきてインストールして見るのも一つの手だと思います。

次は suspend/resume にトライだぁ;-)。

1月 062021
 

以前のエントリで、「Nginx + quiche パッチで HTTP/3 にチャレンジ。」と、いうのを書いています。このエントリの『続編』を書いてみたいと思います。

と、いうのも色々あったからです。

簡単に書くと、あっという間にこのエントリは終わってしまいますf(^^;;。
ネタ的なモノを箇条書きにしてみると

  • nginx + quiche パッチでは SSI は動作しません
  • nginx + quiche パッチを利用した場合 RTMP モジュールが利用できないです

の二つになります。これが解れば詳細はどうでもいー。と、いう人はここでおしまいです。
『なんで?』と思った方は読み進んでくださいf(^^;;。

 
まず、上の部分の SSI についてですが、perl による index.cgi で SSI で吐き出すことと同じ動作をするモノを作成すると、無事に動作します。

以下はサンプルです。これは index.cgi 。

#!/usr/local/bin/perl
use strict;
print "Content-type: text/html\n\n";
print "<html>\n<head>\n";
print "<META HTTP-EQUIV=\"Content-type\" CONTENT=\"text/html;charset=utf-8\">\n";
print "<TITLE>IPv6 HTTP/3 Access Web page.</TITLE>¥n";
print "</head>\n<body>\n";

print "<br><h2>Hello HTTP/3 World.</h2><hr>\n";

my $word = "";
if ($ENV{'REMOTE_ADDR'} =~ /:/) {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv6 パケットを受け取りました。";
} else {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv4 パケットを受け取りました。";
}
print "$word<br><hr>\n";;

print "===> Protocol: $ENV{'SERVER_PROTOCOL'}<br>\n<hr>";
print "===> Access Port: $ENV{'SERVER_PORT'}<br>\n<hr>";

exit;

 
似たようなのを index.shtml と access.cgi でやるとこんな感じ。

こちらは index.shtml。

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-type" CONTENT="text/html;charset=utf-8">
<TITLE>IPv6 HTTP/3 Access Web page.</TITLE>
</HEAD>
<BODY>
<ht>
Hello HTTP/3 World.<br>
<hr>
<!--# include file="./access.cgi"-->
<hr>
</BODY>
</HTML>

 
こちらは access.cgi。

#!/usr/local/bin/perl
use strict;
print "Content-type: text/html\n\n";
my $word = "";
if ($ENV{'REMOTE_ADDR'} =~ /:/) {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv6 パケットを受け取りました。";
} else {
    $word  = "---> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv4 パケットを受け取りました。";
}
print "$word<br><hr>\n";;
print "===> プロトコル: $ENV{'SERVER_PROTOCOL'}<br>\n<hr>\n";
print "===> アクセスポート: $ENV{'SERVER_PORT'}<br>\n";
exit;

 
index.html (index.shtml) に include があると、 Nginx + quiche パッチではまともに動作しないようです。 quiche パッチを詳しく追ってはいないのですが、どうやら include 部分がそげ落ちているようです・・。 orz

まぁ、今の段階では SSI を利用しないコンテンツを用意する必要がありそうです。

 
二個目。

テレワークなどで、PC にカメラを接続する機会が多いのですが、せっかく購入したカメラ。もっと色々な用途で使ってみたい。などと思うわけです。 USB Video Class 、俗に USB な UVC カメラを FreeBSD に接続し、 webcamd や obs-studio をインストールして『ストリーミングなどしてみんべ。』などと思うわけです。
このブログでも以前に「NotePCに付いているカメラを FreeBSD で使う。」と、いうのを書いていたりしますが;-)。

更に一歩進んで obs-studio をイントールした場合、配信先に RTMP サーバが必要になります。
Nginx はモジュールとして RTMP モジュールや Stream・Stream SSL モジュールなどを利用可能ですが、HTTP/3 を有効にする quiche パッチを適用した Nginx ではこれらのもジュールは利用できません。

以下は nginx.conf の設定の抜粋です。

load_module /usr/local/libexec/nginx/ngx_stream_module.so;
load_module /usr/local/libexec/nginx/ngx_rtmp_module.so;

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        access_log /var/log/nginx/access_rtmp.log;

        application webcam {
            live on;
            record off;
            wait_video on;
        }
    }
}

 
load_module のところで早くもエラーが出ます。

# service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] dlopen() "/usr/local/libexec/nginx/ngx_stream_module.so" failed (/usr/local/libexec/nginx/ngx_stream_module.so: Undefined symbol "SSL_set_tlsext_host_name") in /usr/local/etc/nginx/nginx.conf:7
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

 
もしくは

# service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] dlopen() "/usr/local/libexec/nginx/ngx_rtmp_module.so" failed (/usr/local/libexec/nginx/ngx_rtmp_module.so: Undefined symbol "HMAC_CTX_new") in /usr/local/etc/nginx/nginx.conf:7
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

 
みたいな感じ。

最初、どうして、SSL 系でエラーが出るのか解らなかったのですが、ports の www/nginx/Makefile とかソースを眺めていたら解りました。以前のエントリで、Nginx + quiche パッチを適用する場合 configure オプションに –with-openssl=/usr/ports/www/nginx-http3/quiche/deps/boringssl を指定しているんですね。
RTMP や Stream モジュールを利用する場合、ベタな openssl のソースのパスを指定する必用があるのですが、 quiche パッチを適用した場合、quiche 独自の SSL のコードを参照する必用があるので、 RTMP や Steram モジュールのコンパイルが通ったとしても、いざ動作させようとすると色々とシンボル名がなかったりするのですな。

 
と、いうことで、 Nginx に quiche パッチを適用した場合は、 HTTP/3 でのアクセス可状態なサーバで、SSI を利用しないウェブサーバとして利用するみとになります。

あ。Nginx + quiche パッチを適用したウェブサーバでも HTTP/2 や HTTP/1.1 、そして HTTP/1.0 (今では w3m くらいか?) でアクセスがあった場合 (それは、つまりは TCP でアクセスがあった場合かぁ?) には SSI は動作します。あくまで HTTP/3 でアクセスがあった場合のみ SSI の記述がある index.html がまともに表示されない状態になります。

SSI 使ったり RTMP・Strerm モジュールを利用したい場合は別にコンパイルしたサラの Nginx を用意する必用があります。 quiche パッチを適用しない Nginx では SSI や RTMP のサーバとして利用できるので、仮想マシンやコンテナで別立てするのがよろしいかと思われます。

 
ちなみに、Firefox は 72 から、 macOS や iPhone は Safari 14 から HTTP/3 がサポートされるようになりました(詳細については gugu ってください;-)。 macOS や iOS から HTTP/3 でアクセスできるようになると、ウェブサーバ担当者としてもいよいよ HTTP/3 の設定をしてサーバを起動してみたくなりますなぁ;-)。 ファイアーウォールの UDP Port:443 を開けるときが、今っ!! 来ましたっ!! ;-)。

8月 022020
 

今回も ThinkPad X13 で FreeBSD を動かすネタです。前回のエントリは「ThinkPad X13 AMD で利用する FreeBSD。」というネタでしたが、結局のところ FreeBSD/amd64 12.1-RELEASE ではだいじなものが動作しない。と、いう結果に終わりました。

その後、それなりに使い続けているのですが、中々厳しい状況においてもそれなりに許せる点もあるので、その辺りについて先に書いてみます。

 
o. 音は出るね。
/dev/sndstat を覗いてみると音は出るみたいです。

Installed devices:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <ATI R6xx (HDMI)> (play)
pcm2: <ATI R6xx (HDMI)> (play)
pcm3: <Realtek (0x0257) (Analog)> (play/rec) default
pcm4: <Realtek (0x0257) (Right Analog Headphones)> (play)
No devices installed from userspace.

 
本体で音を出すのは Realtek 側のデバイスを利用する必要があるのですが、前のエントリでは「イヤホンジャックに切り替えられない」と、書いていたのですが、実はそんなことはなく、ちゃんと切り替えできました。

ただ、利用できない状態の場合もあります。例えば動画を mpv で見るとき、止まってしまいます。色々オプションを変えて確認したところ mpv -no-audio test.mp4 とかで再生できることが解りました。
つまり、mpv で動画の再生ができないのは Realtek のドライバがちょっと怪しいからなのね。と、いうことが解りました。

で、回避策ですが、Windows10 をリブートして FreeBSD を起動するとサウンドデバイスが怪しい。しっかりとシャットダウン状態から起動すると音が出るような感じです。通電している状態からの初期化がうまくいってないのかな?と、いう雰囲気です。

まぁ、音が出るのでヨシとしておきますf(^^;;。

 
o. suspend/redume もしないし画面の明るさ変えられないけど・・。
いやぁ・・。半分あきらめの境地で xf86-video-scfb を利用していますが、比較的新しい AMD APU を利用している人は以下の URL を見てみると良いかもです。

amd vega and radeon series vga card driver for FreeBSD 12.1 tutorial for beginner

Picasso は大丈夫そうですね。 Renoir はまだちょっと無理っぽい・・。

そして、drm-v5.0-fbsd12.1.zip を使い、 linuxkpi のソースにパッチを当てると suspend/resume もするみたいです。

いやぁ・・。早く Renoir に対応してくれないかなぁ・・。

 
画面の明るさを調整できないのは、AC アダプタ運用時には特に気にならないです。それにしても液晶ディスプレーが大きくて綺麗なので scfb でも結構それなりに綺麗に映ります。明るい画面だとなおさら綺麗に見えるっ!!

負け惜しみです・・。 orz

ThinkPad E145 の場合は 起動中の BIOS の画面とか、FreeBSD のブートセレクタの画面が出ているときに ThinkPad の Fn ボタンで画面の明るさが調整できた (FreeBSD が起動して acpi.ko に制御が渡るといきなりボタンが無効化される。 acpi.ko が悪さしていることは、文字通り、目に見えている) のですが、今はそれができない。最大の明るさで光っています。 xrandr でも制御できない。

 
と、いうことで、本題に行きましょうか。

ThinkPad X13 AMD に FreeBSD/amd64 12.1-RELEASE をインストールしていて、実はタッチパットの動作が怪しかったのであります。

どの辺りが怪しかったかというと、

  • タッチしてツーツーと指を動かしてもカーソルの動きがやたらと遅い
  • 二本指でスクロールしてくれない
  • KDE5 の「KDE システム設定」の「ハードウェア」→「入力デバイス」→「マウス」の [タッチパッド] のメニューで認識していない

みたいな感じです。一応、タップしてクリック風の動作はするし、タッチしてズズズとずらすとマウスカーソルが動いてくれるので『ま。こんなモノなのかな。新製品は。』などと、思っておりましたが、二本指でスクロールができないのは不便なことこの上ないので、やはり調べてみることにしました。

 
1. iichid って?
ports に sysutils/iichid というのがあります。これをインストールします。

GitHub に設定方法が書いてあるので、参考にして、色々設定します。

https://github.com/wulf7/iichid

/boot/loader.conf で ig4 iicbus と iichid を kldload するように設定しろ。って、書いてあります。その通りします。
xorg.conf のマウスの部分の設定も上記 URL に書かれているようにします。しかし、二本指スクロールの設定はなくてええんかい? と、なるのでありますが・・。

実は /boot/loader.conf にはもう一個設定が必要です。

 
2. /boot/loader.conf の設定
フツー、ThinkPad を利用している人は赤ポッチのマウスとタッチパッドの両方を利用したいと考えます。その設定を /boot/loader.conf に書きます。上記の kldload 分と合わせて書いたものはこんな感じです。

hw.psm.synaptics_support="1"
hw.psm.trackpoint_support="1"

ig4_load="YES"
iic_load="YES"
iichid_load="YES"

 
synaptics_support はタッチパットサポートの設定で trackpoint_supportは赤ポッチサポートですね。
そして xorg.conf のマウス部分の設定に入ります。

Section "InputClass"
    Identifier          "libinput touchpad catchall"
    MatchIsTouchpad     "on"
    MatchDevicePath     "/dev/input/event*"
    Driver              "libinput"
    Option              "NaturalScrolling" "on"
    Option              "ScrollMethod"     "twofinger"
    Option              "Tapping" "on"
    Option              "DisableWhileTyping" "on"
    Option              "AccelSpeed" "0.42"
EndSection

Section "InputClass"
    Identifier  "Trackpoint Wheel Emulation"
    Driver              "evdev"
    MatchProduct        "TPPS/2 IBM TrackPoint"
    MatchDevicePath     "/dev/input/event*"
    Option              "EmulateWheel"          "true"
    Option              "EmulateWheelButton"    "2"
    Option              "Emulate3Buttons"       "false"
    Option              "XAxisMapping"          "6 7"
    Option              "YAxisMapping"          "4 5"
EndSection

 
ThinkPad E145 の場合はこれで動いていました。以前のエントリの「FreeBSD に KDE5 が降ってきた。」で libinput を使うようにしました。その流れのまま ThinkPad X13 AMD の設定をしていたのですが、上記のような現象。 ScrollMethod twofinger が効いてない。

 
何回か、試してみましたが、ダメでした。で、色々と調べたところ、今の時代 hw.psm.synaptics_support ではなく hw.psm.elantech_support というのを使うと良いみたいなのであります。と、いうことで全て設定を見直してみました。

 
3. 結局 hw.psm.elantech_support=1 だね
まずは正しいと思われる設定を色々としていくことにします。

 
o./boot/loader.conf

#hw.psm.synaptics_support="1"
hw.psm.elantech_support="1"
hw.psm.trackpoint_support="1"

ig4_load="YES"
iic_load="YES"
iichid_load="YES"

evdev_load="YES"
uinput_load="YES"
cuse_load="YES"

 
ThinkPad X13 AMD の場合は hw.psm.synaptics_support ではなく hw.psm.elantech_support を 1 にします。
一応 iichid 関連を kldload するようにしました。
その下 evdev は libinput 系の Xorg で利用するときに必要なカーネルモジュールです。これらも kldload するようにしました。

とは言いつつ、僕の場合、デスクトップに KDE5 を利用しているので Wayland べったりです。 ports 的にインストールしたのは以下になるでしょうかね。

 
xf86-input-evdev-2.10.6_5
xf86-input-keyboard-1.9.0_4
xf86-input-libinput-0.30.0
xf86-input-mouse-1.9.3_3
xf86-input-synaptics-1.9.1_6 (多分、これはもう要らない)

 

o.Xorg.conf のマウス設定

Section "InputClass"
    Identifier          "libinput touchpad catchall"
    Driver              "libinput"
    MatchDevicePath     "/dev/input/event3"
    MatchIsTouchpad     "on"

    Option "AccelSpeed"  "0.1"
    Option "ClickMethod" "clickfinger"
    Option "DisableWhileTyping"  "on"
    Option "HorizontalScrolling" "on"
    Option "LeftHanded"          "off"
    Option "NaturalScrolling"    "on"
    Option "ScrollMethod"        "twofinger"
    Option "Tapping"             "on"
    Option "TappingDrag"         "on"
    Option "TappingDragLock"     "on"
EndSection

Section "InputClass"
    Identifier          "Trackpoint Wheel Emulation"
    Driver              "evdev"
#   MatchProduct        "TPPS/2 IBM TrackPoint"
    MatchDevicePath     "/dev/input/event4"
    Option              "EmulateWheel"          "true"
    Option              "EmulateWheelButton"    "2"
    Option              "Emulate3Buttons"       "false"
    Option              "XAxisMapping"          "6 7"
    Option              "YAxisMapping"          "4 5"
EndSection

 
上の部分がタッチパットで、下の設定が赤ポッチ(トラックポイント)です。 xinput list とか、コマンド打つとか /var/log/Xorg.0.log をひたすら眺めて /dev/input/event の何番目が割り当てられるのか確認する必要があります。

僕の場合 hw.psm.synaptics_support のときは event0 だったのに hw.psm.elantech_support にしたら event3 になりました。そしてトラックポイントは event4 になりました。

 
『hw.psm.synaptics_support=1 を設定しましょう。』と書かれているサイトはよく見るのですが『hw.psm.elantech_support=1 を設定しましょう。』ってのは、まだあまり見かけないので、今回のエントリーを書いてみました。
タッチパットが思ったとおりの動作をしない場合は hw.psm.synaptics_support ではなく hw.psm.elantech_support を指定してトライしてみてはいかがでしょうか。

 
ちなみにですが hw.psm.elantech_support を利用したら KDE システム設定のメニューにも正しく表示されるようになりました。

 
デバイス的には ETPS/2 Elantech Touchpad として認識されました。 ET な PS/2 なマウスって感じ? (なにそれ? f(^^;;)

xorg.conf で設定している値がそのまま KDE の設定画面から調整できるのが良いですよねぇ。これも Wayland の恩恵かなぁ;-)。

7月 152020
 

さてと。前回のエントリは ThinkPad X13 の AMD 版が納品されて、簡単なファースト・インプレッションを行いました。
僕はそもそも NotePC で Windows10 を利用することはあまりないので、ベンチマークとか全然できないのであります。なので、詳細な検証などはまるで皆無。参考にならない記事ですなf(^^;;。

と、いうことで、今回は出たばかりの最新鋭の NotePC に FreeBSD をインストールしてみます。色々と問題点があるのだろうなぁ。とは思うのでありますが、れっつとらい。

 
1. FreeBSD のインストール準備
今回チョイスした FreeBSD のバージョンは FreeBSD/amd64 12.1-RELEASE と、いうリリースされている標準的なバージョンです。このバージョンが、最新鋭の NotePC にインストールしてどこまで動作するのか確認してみたいと思います。

インストールの作業手順は以下のとおりです。

0).Windows10 の回復 USB の作成
1).Windows10 のパーティションの縮小
2).FreeBSD 用 UEF パーティションの確保
3).FreeBSD のインストール
4).bcdedit でブートメニューの登録

このうちのほとんどの作業は以前「ThinkPad E145 を UEFI ブートに変えてみた。」といえエントリに書いているのでサクっと省略します。実際に僕もこの手順で問題なくインストールできましたので、そちらを参考にして頂ければと思います。

ただ、今回は最新鋭の NotePC で、今まで利用していた ThinkPad e145 と比べて最新技術が導入されています。

気を付けたのは以下の点。

  • BitLocker が default で導入されている
  • UEFI (BIOS) の設定画面で「レガシー BIOS」(CSM のことですね) がどうも見当たらない

この二つをなんとか回避する必要があります。

 
2. BitLocker の解除
「コントロールパネル」から「BitLocker ドライブ暗号化」メニューを覗いても無効にはできませんでした。ただし、この画面から BitLocker のキーを取得しておきましょう。
BitLocker を解除するのは「設定」アプリの [更新とセキュリティ] の中にあります。ここからまず、 BitLocker を無効にします。

最初から入っている OS 以外をインストールするとき EFI セットアップメニュー (BIOS 画面) で「セキュアブート」を無効にする必要があるのですが、 BitLocker を有効にしたままセキュアブートをオフにすると青い画面が現れて何やらキーを入力するように要求されてしまい『むむむ。』などと思ってしまうのであります。

と、いうことで、新しい OS をインストールするためには、

・BitLocker を無効にする
・セキュアブートをオフにする

以上の二つが必要です。

 
3.「レガシー BIOS」の設定画面が見当たらない
もしかしたら EFI セットアップメニュー内にあるのかもしれません。が、しかし、僕は見つけられませんでした。と、いうか、もう FreeBSDの インストール時には「レガシー BIOS」の設定の有無は不要です。

ThinkPad e145 を UEFI で利用する設定を投入したときに FreeBSD のインストール用 USB メモリを Rufus で作成した。と、書いています。 Rufus で FreeBSD のブート USB イメージを作成するときは MBR で起動する USB ブートイメージしか作れない。と、書いているのですが、実は FreeBSD の 12.1-RELEASE のインストールイメージは UEFI+GPT に対応しているんですね。

Rufus を利用して UEFI 対応の FreeBSD の USB ブートイメージを作成する場合 ALT+E を押すことにより BIOS+MBR にするか UEFI+GPT にするか選択できます。

なので、「レガシー BIOS」 をオンにせずとも UEFI モードのままで FreeBSD をインストールすることができるのであります。

 
4.FreeBSDのインストール
EFI セットアップメニューで変更するのは セキュアブート “オフ” のみで FreeBSD のインストールが可能になりました。

と、いうことで、あとは FreeBSD をインストールするのみです。途中パーティションの設定の所では、 [Auto] を設定すると、SSD の全領域を対象としてしまうので、ここは [Manual] で、必要な領域を確保するようにします。

インストールが完了したあとは Windows10 が起動するので bcdedit で Firmware Windows Boot Manager に FreeBSD がブートするように登録してあげてインストール作業は終了です。

 
5.いよいよ FreeBSD の起動。しかし NIC は?
まず、必要なのにデバイス的に動かないもの。あ、今回は一発目のインストールなので 12.1-RELEASE になります。あまりにも動かないようであれば CURRENT に移行するか。などと思っていますが。

  • WiFi6 AX200
  • Ryzen7 Radeon Vega10

この二つは結構痛い・・。orz
順番に話して行きます。

そもそも pciconf -lv すると none のデバイスが 8 個もあります。orz

pciconf -lvの結果

vmm.ko を kldload するとか、仮想 OS 用のブリッジ・RealTek のデバイス・AMD のマルチメディア系デバイスなどが認識していません。

 
Intel の WiFi6 対応の AX200 は 調べてみたところ OpenBSD のほうでは if_ixw と、いうドライバが書かれているみたいですが、 FreeBSD はまだ未対応のようです。 if_iwm.ko でも動作しません。

ThinkPad X13 の内臓 re0 を利用するためのアダプタを購入してないので USB WiFi や USB NIC を利用しようと思いましたが・・。それにしても最近の FeeeBSD の USB NIC はボロボロですな・・。RealTek の WiFi NIC ドライバ if_urtw.ko は 802.11a 対応したチップをマージしたら速度が全く出ないし、 if_axge.ko は ue0 の 1Gbps で接続する JR45 の NIC なのに、こいつは ping の損失率は 60% 前後。もう、悲惨というほかない・・。

ショーがないので WiFi の場合は if_run.ko を利用し RJ45 NIC の場合は if_axe.ko を利用する。と、いう状態・・。orz

 
6.Xorg 動く?
Ryzen7 Radeon Vega10 はディスプレイ用のチップですが ports から graphics/drm-fbsd12.0-kmod/ をインストールして

kld_list="/boot/modules/amdgpu.ko "/boot/modules/radeonkms.ko"

 

を書いても認識されませんでした。

/dev/dri/Card0 が生成されないので OS 的にも認識されていません。

まぁ、この際 amdgpu.ko をきっぱりと諦めて vesa ドライバで Xorg が起動してみようと試みるもダメ・・。あらまぁ。

[ 71220.842] (II) VESA(0): initializing int10
[ 71220.843] (EE) VESA(0): V_BIOS address 0x0 out of range
[ 71220.843] (II) UnloadModule: "vesa"
[ 71220.843] (II) UnloadSubModule: "int10"
[ 71220.843] (II) Unloading int10
[ 71220.843] (II) UnloadSubModule: "vbe"
[ 71220.843] (II) Unloading vbe
[ 71220.843] (EE) Screen(s) found, but none have a usable configuration.
[ 71220.843] (EE) 
Fatal server error:
[ 71220.843] (EE) no screens found(EE) 
[ 71220.843] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[ 71220.843] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 71220.843] (EE) 
[ 71220.844] (EE) Server terminated with error (1). Closing log file.

 
vesa ドライバを利用した場合はこんな感じのログが出力されます。

それなら最後の手段だ。と、いうことで scfb で試してみたところ、一応 Xorg の画面は現れました。が、 xrandr で対応する画面サイズを確認してみると・・。

# xrandr 
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 640 x 480, maximum 640 x 480
default connected 640x480+0+0 0mm x 0mm
   640x480        0.00* 

 
orz。

しかし、scfs ドライバというのは UEFI と密接に関連いているようですね。 xorg.conf でディスプレイサイズを変更するのではなく UEFI 用のコマンドが用意されていて、 OS 起動時の画面サイズを調整してから、そのサイズを scfb ドライバが読み取って画面サイズが決定されるようです。

FreeBSD の起動時に OS ブートのメニューが表示されますが、そこで 3 を 押して OK プロンプトを出します。

表示された OK プロンプトで gop コマンドを打ちます。 GOP とは Graphics Output Protocol のことらしいです。オプションは list (選択枝の表示) get (現在の設定情報の取得) set (新しい設定を指定) の三つ。

OK プロンプトから gop list と打つとディスプレイが対応しているサイズの一覧が表示されます。そこて gop set 0 などと打ち、使いたいサイズの番号を打ちます。

すると、コンソールが中央付近に小さくなって表示されます。そこの OK プロンプトで boot と打つと指定した画面の大きさで FreeBSD がブートします。くれぐれも reboot とは打たないように;-)。
OS の起動後にすかさず startx と叩くと、さっきまで 640×480 でしか表示してくれなかった scfb ドライバが大画面で表示できるようになります。

ちなみに ThinkPad X13 AMD は色々なサイズがあったのですが、実質的に 640×480 か 1920×1080 の二つのサイズしか表示できませんでした。

なお、 /boot/loader.rc に gop set で指定したモードの番号を記載することにより毎回 OK プロンプトで設定する必要がなくなるらしいのですが、それはちょっとバグがあるみたいで正しく動作しないようです。
では、どうするか? と、いうと /boot/loader.conf に exec=”gop set 0″ と、コマンドイメージそのままを書くと良いです。

これで Xorg が無事に起動したので、ずいぶんと利便性がアップしました;-)。いやぁ。良かった。
あと、 NotePC のスペックが非常に高いので scfb ドライバでもその遅さがあまり気になりません。これは非常にラッキーです;-)。

 
7.Suspend/Resume するの?
以前、今回の ThinkPad X13 AMD を購入する前に FreeBSD の偉い人が既に ThinkPad X1 を持っていたのでその人に「Suspend/Resume します?」って、聞いたら「興味ない。」と、つれない返事。あらま。

では、ThinkPad X13 AMD が届いてから確認すれば良いやぁ。などと思ったのですが、今回はその検証を。

 
まず、何はなくとも zzz と打ってみると、一応は寝てくれました。しかし、電源を投入すると、 OS が起動して来て fsck が走ります。あらら・・。

試しに以下のコマンドを打ってみます。

# sysctl hw.acpi.supported_sleep_state
hw.acpi.supported_sleep_state: S4 S5

 
うひょー。 S3 ステートがないじゃーーん。 orz
なるほど。これが原因で「興味ない。」と、コメントが返ってきたんだな。と、一人で納得。

本当に S3 ステートが無いのか? とウェブで探し回ったことろ、以下の URL にぶち当たりました。

Lenovo ThinkPad X1 Carbon (Gen 6)

最近の ThinkPad には BIOS レベルで S3 ステートがなく、かわりに s0i3 スリープというのがあるらしい。では s0i3 スリープとはなんぞや? と、思い調べてみると Windows10 もしくは Microsoft 『モダンスタンバイ』というモノらしく OS べったりなスリープモードらしいです。

これを FreeBSD 側、上記 URL では『Linux 側』で利用するには ACPI の DSDT を書き換える必要がります。まぁ、過去に何回か書き換えたことがあるのでどーにかなるだろう。などと思いつつも EFI セットアップメニューを眺めていたらなんとっ!!

ThinkPad X13 AMD はスリープステートを EFI セットアップメニューから切り替えられるようになっておりました。

[Windows 10] にすると「モダンスタンバイ」 になって [Linux] にすると今までどおり S3 ステートになります。 [Linux] に変更したあとに上記 hw.acpi.supported_sleep_state を確認すると S3 S4 S5 と、 S3 が生えてまいりました;-)。

 
と、いうことで準備が整ったので再度 zzz と打ちます。 Suspend は割と素直に寝てくれます。フタを閉じて再度開けると、画面はブラックアウトです。しかし、 USB WiFi がピカピカ光っているのでカーネル自体は起き上がったようです。

しばらく待って ping の疎通確認したら目覚めていました。 ssh したらログインできました。無事に Suspend/Resume 自体は動作しているようですが、画面は真っ暗なまま。まぁ、まだ Xorg 動き始めたばかりなのでなんとも言えないですが、 コンソール周りの vt や Xorg 次第で画面が復活するかな?などと安直に思っています。

ちなみに、相変わらず acpi_video.ko はまともに動作せず sysctl の hw.acpi.reset_video mib を 1 にするとカーネルが凍りつくのは ThinkPad e145 と一緒ですね。

 
8.その他
画面の明るさ変更についてですが、上にも書いた通り acpi_video.ko がまともに動かないので sysctl の hw.acpi.video.lcd0.brightness mib などが使い物になりません。

これまた、画面の明るさについては Xorg が動いたら本格的にいじっていきたいです。

 
あと、まださわりだけですが、イヤホンジャックから音が出ません。 /dev/sendstat 見ると色々デバイスはあるみたいですが sysctl hw.snd.default_unit で切り替えてもヘッドホン端子にさしたイヤホンで音が出ていません。

pciconf -lv で AMD マルチメディアチップが none8 になっていたのでその辺りが影響しているのかな?

 
9.で、結局?
しかし、普段から NotePC で FreeBSD を利用しているので Windows10 では PC のスペックに対してその速さをあまり体験できなかったのですが FreeBSD をブートするとその性能が体感できますね。起動がむちゃくちゃ速い。 KDE5 も sddm からログインしたらサクっとデスクトップが表示されるし、 Firefox の起動もむちゃくちゃ速い。『いやぁー。速い NotePC は中々良いねぇ。』と、なるのであります;-)。

そして、ですが FreeBSD/amd 12.1-RELEASE では結局、以下が動きませんでした。

  • WiFi の AX200 が動作しない
  • Radeon Vega10 が amdgpu.ko で認識しない
  • S3 ステートは利用可能だが Suspend して Resume 後は画面がブラックアウト
  • 画面の明るさは変更できない
  • 音声出力がイヤホンジャックに切り替えられない

こんな感じでしょうか。Radeon Vega10 が graphics/drm-devel-kmod/ な ports で動作するのか確認したいところではありますが、そーすると OS 自体を CURRENT に上げる必要があります。

上記の状態を鑑みると CURRENT を試してみる価値ば十分にあるのかなぁ? などと、思っている次第ではあります・・。

が、このネタ、もう一回続くかも。

7月 122020
 

いやぁ。久しぶりに NotePC を新調しました。以前購入し、今でも現役なのは ThinkPad Edge e145 ですが、それ以来です。で、ThinkPad e145 はいつ購入したの? と、いうと なんとっ!! 2013/11 なのですねぇ。
ThunkPad e145 は、最近はディスプレイのヒンジを固定しているプラスチックが砕け散って液晶ディスプレイの開け閉じに支障が出ていたのでありました。

長く使うとプラスチックというのは壊れてきますねぇ。まぁ、長く使いすぎた。と、いう話もあるかと思いますが;-)。

 
と、いうことで、今回購入した ThinkPad を含めて、僕の使った歴代の ThinkPad を並べてみました。

ThinkPad 535E -> (途中 DELL とか購入) -> ThinkPad X100e -> ThinkPad e145 -> ThinkPad X13

ThinkPad X100e からずっと AMD の CPU を利用したモノを購入しており、今回の X13 も当然 AMD な CPU 版をチョイスです。実は ThinkPad X395 を買おうかと悩んでいたところに『 ThinkPad X13 は新しい Ryzen で登場予定っ!!』とのことだったので待って待って待って、ようやっと購入しました。

それにしても、購入した歴代の ThinkPad で 10 万 yen を超えたのは今回が初めてです・・f(^^;;。 AMD CPU は安さが魅力ですからね。そして、ThinkPad の看板でもある X シリーズを購入したのも今回が初めて。なるほど 10 万 yen 突破するわけだぁー。

 
ウェブから申し込んだのが 発売日の 2020/06/05 。その後、カードで引き落としできず結局銀行振込にして 5 日ほど無駄な日々を過ごし、納品されたのが 2020/07/07 でした。大体約一ヶ月ですね。
ThinkPad e145 と同じくらいでしょうか。

あ。カードで引き落としができなかった件ですが、僕は macOS の Safari で Lenovo のポームページを見て購入しました。最後のカード番号を入力するところで画面が動作的に壊れてしまいカード番号を入れたんだけど、うまく Lenovo 側に伝わっておらず「このカードは利用できません。」となっているそうでした。

macOS の Safari と、あと AD Block が悪さしているかもしれません。 macOS でカードで購入しようとしている方は Safari ではない別のブラウザを利用したほうが良いかもです。
僕の場合は Microsoft Edge を利用し、 AD Block をオフにしました。が、それでもダメで、諦めて、サポートの人にメールで振込先口座番号を聞いて、銀行振り込みにしました。

 
それでは使用感。ファースト・インプレッションをば。

まず、箱から取り出しての感想。『でかいっ!!』 フツーの ThinkPad って、こんなにでかいのか?と、愕然。まぁ、 X100e も e145 もこぢんまりとした機種でありましたから、それと比較すると、ずいぶんと大きく感じます。

あと、排気熱がすごいっ!! 筐体の右側にダクトがあるのですが、この辺りって外付けマウスを利用する場所なんでよ。気がつくと、マウスを握っている親指に熱風が降り注いている・・。いやぁ。気をつけないと・・。

 
・default は Windows10 バージョン 1909
Windows10 バージョン 1909 をインストール直後から初期設定するのは初めてだったのですが、インストール時にコルタナが登場して音声で設定することができます。「次へ」とか口に出して言うとマウス操作が必要なかったりとか。

あと Windows10 バージョン 1909 で驚いたのはローカルユーザで利用できません。 Microsoft アカウントが必要です。
新規に作るか、既存アカウントでログインすることになります。ただ、回避策があるようで、初期の段階でネットワークに接続しないとローカルアカウントを作成することができるようです。

僕の場合は、一旦 Microsoft アカウントでログインしたあと、ダミーのローカルユーザをなんとか作成して、ローカルユーザでログインし直して、Windows10 上の Microsoft アカウントを削除して、ローカルユーザを Microsoft カウントに結びつけました。

ローカルユーザを作成するときのキャプチャを掲載しておきます。

「設定」アプリ -> [アカウント] -> [家族とその他のユーザー] -> [その他のユーザーをこのPCに追加]

ここで、ウィンドが開きます。そして

[このユーザーのサインイン情報がありません] -> [Microsoftアカウントを持たないユーザを追加する]

これでローカルユーザなアカウントが作成できます。

 
・Windows10 な NotePC で使う 8 コア 16 スレッドって、あまり意味を感じられないのですが・・f(^^;;。あ。今回購入した ThinkPad X13 AMD のスペックは以下の通りです。

  • CPU: Ryzen 7 PRO 4750U 8 コア/ 16 スレッド
  • メモリ: 16GB DDR4 3200MHz
  • SSD: 1TB M.2 2280 PCIe-NVMe
  • NIC: Wi-Fi 6 AX200 (RJ45 アダプタ購入せず)
  • ディスプレイ: 1920×1080 IPS・マルチタッチ非対応
  • その他: 指紋認証・WLAN・キーボードバックライト無し

 
以前購入し、デスクトップとして利用している Mac mini に続き 8 コア/ 16スレッドな CPU です。AMD では初です;-)。
SSD は奮発しました。512MB から 1TB へは増量キャンペーンで +9,900yen だったので飛びつきました。どうせ FreeBSD もインストールするだろうしみたいな。

その代わり、要らないのを思う存分削ぎ落とした。と、いう感じでしょうか。 Windows10 を利用していると指紋認証あると便利だろうけと、 FreeBSD で利用した場合は必要ないし、キーボードのバックライトで ACPI 周りを悩みたくないし。みたいな。

Windows10 ってあまり使い込んだとこないのですが、8 コア/ 16スレッドな PC って、恩恵受けられるのかぁ?

Windows10 側は普段必要なモノをインストールして、WLS と ubuntu をインストールして MobaXterm をインストールした段階で、一応 UNIX 風環境が整ってしまうので、それで『はい。シューリョー。』となってしまうんですよね。

 
そーそー。Windows10 って、Microcoft アカウントを利用していると、他の PC の情報を新しい PC に引き継いでくれるんですね。例えば Ctrl2Cap を使って Ctrl と CapLock を入れ替えていると、新しい PC でもその情報が反映されます。あと、同じように XMouseSetting ですね。こちらは X-window みたいにマウスオーバーによる Auto Rize の機能を設定していると、その設定も引き継いでくれました。手間を省略できたのが嬉しいし、素晴らしいですねぇ。

 
PC の速さには問題ない状況です。しばらく使い込んで、その後 FreeBSD をインストールする予定ですが、それは次のネタとして取っておきます;-)。

実は上の写真。 ThinkPadX 13 AMD で、もう FreeBSD/amd64 12.1-RELEASE が動いていたりします;-)。

詳細については次回を待て;-)。

1月 092020
 

2020 年の 正月に ports を csv update したら Firefox72 が降って来ていたので、そのまま FreeBSD/amd64 12.1-RELEASE にインストール。
しかし、ハタと考えてみた。『Firefox って 72 から HTTP/3 をサポートしたんじゃなかったけっ?』
果たして about:config で確認してみると

network.http.http3.enabled

と、いうのがあるではないかっ!! これをすかさず true にして google などを確認してみる。

HTTP/3 というのは、チョー簡単に言うと UDP で SSL 通信を行うものであります。詳細についてはウェブで情報を探してください;-P。
ファイアーウォールなどで UDP の 443 ポートなんてのは中々開いているものではないので、自宅なり、オフィスなりのファイアーウォールをまず先に確認してみましょう。

 
しかし、自分でも UDP:443 で通信するサーバを構築してみたい。色々探してみると apache24 はまだ、未対応ですが、 nginx は対応パッチが出ているようです。

まずは以下の URL にアクセス。

https://blog.cloudflare.com/experiment-with-http-3-using-nginx-and-quiche/

 
ここに記載されている git からパッチを取ってきて nginx のソースにパッチを当てて make しても良いんだけど、configure のオプションがややこすぃー。せっかく FreeBSD が手元にあるので ports の nginx に quiche パッチを適用してサーバ環境を構築してみましょう。

と、いうのが今回の趣旨です。ひと足お先に HTTP/3 を体験してみましょう。

このブログでは以前に apache24 で HTTP/2+TLSv1.3 対応にするエントリを書いていますが、今回は nginx のエントリになります。

 
1). ports の準備
以下に手順を書いてみます。

# cd /usr/ports/www/
# cp -pr nginx nginx-http3
# cd nginx-http3/
# git clone --recursive https://github.com/cloudflare/quiche
# make patch

 
原本となる /usr/ports/www/nginx/ は一応残しておいて nginx-http3/ というディレクトリで作業を始めます。
git から quiche を一式持ってきて、ports 的には make patch まで走らせます。make patch 時に make config が走ると思いますがお好みの設定で、絶対に忘れてはいけないオプションが HTTP_SSL と HTTPV2 です。 default で [X] になっていると思うんですけどね。

 
2). パッチ適用

# cd work/nginx-1.16.1/
# patch -p01 < ../../quiche/extras/nginx/nginx-1.16.patch
# cd ../..

 
nginx-1.16 用の quiche パッチなので、最新の ports ツリーであれば容易に適用できます。

 
3). ports の Makefile の編集
www/nginx-http3/Makefile を編集します。上記 URL では configure オプションが記載されていますが、それを FreeBSD の ports に書いて上げます。

diff -ur Makefile.orig Makefile
--- Makefile.orig       2020-01-03 12:00:17.947717000 +0900
+++ Makefile    2020-01-03 12:01:29.885305000 +0900
@@ -53,6 +53,9 @@
 
 HAS_CONFIGURE= yes
 CONFIGURE_ARGS+=--prefix=${ETCDIR} \
+               --with-http_v3_module \
+               --with-openssl=/usr/ports/www/nginx-http3/quiche/deps/boringssl \
+               --with-quiche=/usr/ports/www/nginx-http3/quiche \
                --with-cc-opt="-I ${LOCALBASE}/include" \
                --with-ld-opt="-L ${LOCALBASE}/lib" \
                --conf-path=${ETCDIR}/nginx.conf \

 
さーっ!! 準備ができたのでいよいよ make だぁっ!! などと思っては行けません。 quiche 側のソースコードのコンパイルには rust の cargo build を実行するので、なんとっ!! ここへ来て、 rust をインストール必要があります。
Firefox を自前でコンパイルする人は既に rust はインストール済みだと思われるため簡単ですが、持っていない人は /usr/ports/lang/rust/ を make install しましょう。速いマシンでも 30 分くらいかかると思いますけど。

 
rust のインストールが終わったらいよいよ nginx を make install します。

 
以上で HTTP/3 対応 nginx のインストールが完了しました。めでたしめでたし。

 
4). nginx.conf の設定
nginx.conf の設定は抜粋のみです。

user  www;
worker_processes  4;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  16;
}

http {

    autoindex off;

    server {
        listen [::]:443 quic reuseport;
        listen [::]:443 ssl  http2;
        listen      443 quic reuseport;
        listen      443 ssl  http2;

        server_name         nx.icmpv6.org;

        access_log  /var/log/nginx/access_nx_icmpv6_org.log;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.shtml index.php;
            allow  all;
        }

        ssl_certificate     /usr/local/etc/letsencrypt/live/nx.icmpv6.org/cert_chain.pem;
        ssl_certificate_key /usr/local/etc/letsencrypt/live/nx.icmpv6.org/privkey.pem;

        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
        ssl_session_cache   shared:SSL:1m;
        ssl_session_timeout 5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        add_header alt-svc 'h3-23=":443"; ma=86400';

        http3_max_concurrent_streams 128;
        http3_max_requests           1000;
        http3_max_header_size        16k;
    }
}

 
listen は計 4 行ありますが、HTTP/3 で接続する場合には 443 quic reuseport の行が利用されます。 HTTP/3 に対応していないブラウザでは HTTP/2 で待ち受けるので、その設定は 443 ssl http2 になります。

そして、IPv6/IPv4 のデアルスタクです。

HTTP/2 も HTTP/3 も SSL が必須なので証明書を準備しましょう。 SSL 関連の設定もお忘れなく。

 
5). 実際に起動してみる
まず、何はなくとも以下のコマンドを叩いて確認。

$ netstat -an | grep 443
tcp4       0      0 *.443                  *.*                    LISTEN     
tcp6       0      0 *.443                  *.*                    LISTEN     
udp4       0      0 *.443                  *.*                    
udp4       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*
$
# tcpdump -i em0 udp port 443

 
うぉー。udp4,6 で port:443が開いているっ!!
tcpdump を起動して、UDP の port:443 でパケットが流れているか、確認ができます。
また、nginx のアクセスログで "GET / HTTP/2.0" は TCP Port:443 の接続になります。 "GET / HTTP/3" が UDP の Port:443 の接続になります。
上記の nginx の設定ではもう HTTP/2 か HTTP/3 の接続になりますな。高級なブラウザの場合は HTTP/2 か HTTP/3で、 w3m でアクセスするとようやっと "GET / HTTP/1.0" でのアクセスになります。

 
あとは nginx の root パスにドカドカコンテンツを置いていけば良いと思われます。

しかし、 netstat -an で UDP port:443 を確認して待受状態になっているにも関わらず接続できない場合があります。
サーバ側で tcpdump で確認してみると、クライアント側からアクセスがあるだけで、サーバ側からの応答がない場合が・・。しかし、とあるタイミングでは接続できるので・・。今の所 nginx を再起動してみたりと、いう運用ですかねぇ。

あと、Firefox72 は HTTP/3 で接続できなかった場合 HTTP/2 や HTTP/1.1 にフェイルオーバーしません。 HTTP/3 の応答が無くともずっと待っている状態になります。 about:config の HTTP/3 のタイムアウト設定も見当たらないし・・。

 
と、いうことで、今から遊ぶには十分に楽しい HTTP/3 です。FreeBSD では ports を利用すると Firefox72 は使えるわ、 nginx は ports にパッチを当てるだけで configure オプションに悩まなくて済むわ。比較的容易に、そして十分に楽しめること間違いなしです。

ここいらで UDP の世界にどっぷりとハマってみるのも良いのではないでしょうか;-)。

1月 072020
 

Vmware ESXi 上で動作している FreeBSD 12.0-RELEASE を freebsd-update upgrade -r 12.1-RELEASE で 12.1-RELEASE したところ、パッタリと通信が止まった。

まぁ、ssh でログインして ls とかたたく分には問題はない。ログイン先から scp でファイルを転送しようとしたときや、 12.1-RELEASE のサーバが nfs サーバだったりすると、データの転送が全くできない状態。

FreeBSD 12.1-RELEASE はアップロード (受信側) はなんとか速度が出る状態だけど、ダウンロード (送信側) は最初チョロョロそのうちストール。状態で全く利用できない状態。

 
どうしてそうなったのか? と、言えば FreeBSD 12.1-RELEASE になって、 if_vmx.ko は fib に対応したのですが、そこにバグがあるようです。fib については簡単にですが以前書いていますので、そちらを参考にして頂ければと思います。僕的には ubuntu の VRF のような動作ができない機能なので、全く使う気にはならないのですけども。

 
12.1-RELEASE でバグが入り込んでしまったのは if_vmx.ko のみなので、 Vmware ESXi で動作している FreeBSD 12.1-RELEASE は NIC を E1000 、つまりは em0 に変えることにより通信が復活するようになります。ただし、 NIC を変更すると /etc/rc.conf などに記載している設定を変更する必要があるために、インパクトがそれなりに大きいです。

12.0-RELEASE のカーネルソースツリーが手元にある人は 12.1-RELEASE 上で sys/modules/vmware/vmxnet3/ までたどり着いて、そこで make install 叩けばフツーに利用できるようになります。

とは、簡単に行かないか・・。

 
1). 12.0-RELEASE のソースツリーを 12.1-RELEASE 上に用意
2). 12.1-RELEASE 上で 12.0-RELEASE の sys/modules/vmware/vmxnet3/ を make install
3). カーネル再構築時は 12.1-RELEASE のソースを利用
4). GENERIC カーネルを利用しているのであれば GENERIC コンフィグから device vmx をコメントアウトしてカーネル再構築 && インストール
5). /boot/modules/ にインストールされた 12.0-RELEASE の if_vmx.ko を /boot/kernel/ に移動
6). /boot/loader.conf に if_vmx.ko をロードするように記載
7). FreeBSD の再起動

 
これだけやる必要があります。

 
今の所 12.1-RELEASE にバージョンアップして通信ができなくなるのは if_vmx.ko が原因になるので、他の NIC では発生していないと思われます。

 
僕は、物理 NIC を割り当てていない vSwitch 経由の FreeBSD の NIC は if_vmx.ko を利用して MTU を 9000 にしています。
物理 NIC を割り当てている vSwitch では if_vmx.ko を利用していますが MTU は 1500 のままにしています。
どちらの場合も通信が滞るので MTU は関係ありません。

バグレポートも上がっているようです。が、直接的な解決策はまだ見つかっていないようです。

Bug 236999 – vmx driver stops sending network packets and resets connections (TCP) but allows ICMP

某 BSD 系な Slack で仲間連中と色々話したり試験したりしているのですが、再現性は 100% で、かつ、今日現在 if_vmx.ko での回避策を見出せていません。

 
なお、 Vmware ESXi 上に FreeBSD をサーバとして if_vmx.ko を利用しているサービスはほぼ全滅です。ウェブ・ FTP ・ svn サーバ・ NFS サーバ、その他諸々。

FreeBSD 12.0-RELEASE を Vmware ESXi 上で稼働させていて、FreeBSD 12.1-RELEASE にバージョンアップした人、しようとした人はお気をつけください。