11月 202021
 

新しくデスクトップ PC を購入しました。『AMD FX おじさん』ではないですが、今まで利用していた PRIMERGY MX130 S2 は 2012 年に購入したのですなぁ。約 10 年使っていた。と、いうことか・・。速度的に『遅いっ!!』とは思ってなかったのでずっと使い続けていましたが・・。

今は半導体不足なときで、PC も決して安くはない。 AMD Ryzen7 PRO 4750G / Memory 16GB / 512GB SSD で 85,000yen 程度。納期は約一週間でした。

写真的には外側よりも内部のほうが嬉しいですよね。多分;-)。

HP ProDesk 405 G6 SFF/CT を買う前に一旦 Lenovo の ThinkCentre M75t Tower Gen2 を注文したんだけど、納期が約半年先、来年の 3 月になる。とのことだったので、待ってられないのでキャンセルした。ということがあるのであります。
HP は昔の日本 DEC の工場を持っているので納期が早いのねぇ。と、いう感じがします。

default の OS は Windows10 home でした。まだ Windows11 にはしていません。それよりも先に、すかさず FreeBSD のインストールを開始するのであります。

 
がっ!!驚きーっ!!よく調べずに今回の PC を買ったのですが、なんとっ!! FreeBSD/amd64 13.0-RELEASE がインストールできないのです。インストール用 USB メモリを Rufus で書き込みブートさせるのですが —<<BOOT>>— が出る前でフリーズしてしまうのでありました。『あらら? もしかしてハズレな PC 買ってしまったか?』 などと調べ始めると・・。

ほおほお。 HP の デスクトップ PC や NotePC では 13.0-RELEASE 以前のバージョンではブートできないパターンがあるのねぇ。

https://forums.freebsd.org/threads/freebsd-on-hp-prodesk-g6.79252/

こちらのスレッドがまさしくビンゴ。 HP の PC は本当に悩みモノらしい。下まで読み進むと 14-CURRENT ではブートするようになったみたいなので、試してみたら確かにブートしてインストールできた。ホっ。
で、更に追加で 13.0-STABLE でも試してみたらこちらも無事にブートしたのでありました。ふぅ。

上記 URL のネタは 6 月には CURRENT 用の修正版が出たみたいだし STABLE に降りてくるのにはそんなに時間がかからないと思うので、今の 11 月辺りでは 13.0-STABLE でも OK 。と、いう感じなのでしょうねぇ。
と、いうことで今回インストールしたのは FreeBSD-13.0-STABLE-amd64-20211111-7647baa1e8f-248036-bootonly.iso になります。 2021/11/11 分の STABLE ですね。

一個前のエントリで書いていますが 13.0-RELEASE と同様に Windows の EFI パーティションをつぶすこともなく、インストールが完了しました。
Lenovo の PC と違い BitLocker を気にする必要がなく、素直にセキュアブートをオフにするだけでインストールすることができたのであります。

 
デバイス的なことを書きましょう。手元に Intel AX200 の代わりに購入した Intel Wireless-AC 9260 があったので、それを設置しました。 NotePC 用に買ったのでアンテナが無かったのですが Amazon で 760yen で追加購入。ただのケーブルが二本だけど、Wi-Fi モジュールに接続できる必要があるので、しっかりと選択する必要があります。長さはだいたい 30cm ほどかなぁ。ケース内にケーブルを這わせたあと、 FreeBSD で利用すると 20Mbps 程度、Windows で利用すると 200Mbps 程度出ます(自宅で可動しているスピード計測サイトでの計測;-)。

他に S-ATA 接続の Samsung SSD 870 QVO 1TB SVQ01B6Q も設置。 M2.2280 な SSD と合わせて 1.5GByte の容量を確保できました。

 
FreeBSD の pciconf -lv で特筆すべきデバイスをちょっと並べてみます。

none0@pci0:4:0:0:       class=0xff0000 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816e subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'Realtek RealManage BMC'
re0@pci0:4:0:1: class=0x020000 rev=0x29 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x103c subdevice=0x872d
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
none1@pci0:4:0:2:       class=0x070002 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816a subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111xP UART'
    class      = simple comms
    subclass   = UART
none2@pci0:4:0:7:       class=0x0c0701 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816c subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111xP IPMI interface'
    class      = serial bus
    subclass   = IPMI
iwm0@pci0:5: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

 
HP の法人向け PC なので Intel でいうことろの vPro みたいなのを積んでいるようですが、 AMD の CPU 搭載なので Intel チップはちと無理か。そのかわりに Realtek のリモート管理系チップが搭載されているようです。俗に『AMD DASH』と呼ばれているヤツかな? BIOS (UEFI) の設定メニューにオン/オフのオプションがありました。

が、当然 FreeBSD では認識されません。

iwm0 はあとから自分が取り付けたモノになります。 BIOS (UEFI) 的にもフツーに認識されているし Bluetooth も BIOS で認識しているので問題ないですね。
下の写真では、一番上の真ん中にあるある出っ張ったパーツです。アンテナが伸びているのは一枚目の写真でも解るでしょうか?

せっかく 13.0-STABLE にしたし Intel Wireless-AC 9260 もついたので、Iwlwifi を試してみるかねぇ。みたいな状態で https://wiki.freebsd.org/WiFi/Iwlwifi を試してみましたが・・。
https://people.freebsd.org/~bz/wireless/apply-wireless-latest.sh これはもうコードが古くてコンパイルも通らないですね・・。orz 20210904 のカーネルソースコードだと linuxkpi のコードにもずいぶんと改修が進んでいるだろうに・・。
と、いうことで FreeBSD での 802.11ac はまだ待ちの状態です。

 
Realtek の NIC は re0 で認識されてはいますが /boot/kernel/if_re.ko では認識できないチップです。最新のチップかな? 最初『え゛。Realtek のチップ認識しないの?』と、驚いたのですが、今の世の中 ports からインストールするとか。 ports の net/realtek-re-kmod/ をインストールすると /boot/modules/if_re.ko が入ります。これを利用すると re0 で認識できます。
/boot/loader.conf はこんな感じで。

if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"
hw.re.max_rx_mbuf_sz="2048"

 
あと、今回の PC は CPU が AMD Ryzen7 PRO 4750G なので GPU は Renoir です。これは ThinkPad X13 と一緒。 ports の graphics/drm-devel-kmod/ では X が起動しませんでした。
せっかく 13.0-STABLE を利用しているので linuxkpi 系は最新のソースコードがはいっているはず。と、いうことで GitHub から drm-kmod-master の最新版を取ってきました。今だと drm-kmod-5.7 になります。これをインストールしたらあーたっ!!

X はバリバリ動作する。

$ xrandr 
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
   2560x1440     59.95*+  60.00  
   2048x1152     60.00  
   1920x1200     59.88  
   1920x1080     60.00    60.00    59.94    30.00    24.00    29.97    23.98  
   1600x1200     59.95  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.95  
   1280x800      59.95  
   1280x720      60.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x480       60.00    59.94  
   640x480       60.00    59.94  

 
スゲースゲー。 ThinkPad X13 では 13.0-RELEASE と drm-kmod-5.5-wip でやっとこさ X を動かしたんだけど、 AC アダプタ抜くとカーネルパニックとかしていてまだまだだなぁ。と思っていたんだけどそんなこともなく。

あと、デスクトップ PC で 13.0-STABLE + drm-kmod-master (5.7) を利用すると suspend/resume できますっ!! デスクトップ PC で suspend/resume っ!! resume 後に X が死ぬ。と、いうこともなく本当に無事に、 WindowsOS のようにフツーに動作します。かなり感動的っ!!

 
今回、HP ProDesk 405 G6 SFF/CT にイントールしたあと、すかさず ThinkPad X13 も同じ構成にしてみたんだけど、上にも書いた通り AC アダプタ抜いてもカーネルパニックせず、 X は無事に動作するし suspend/resume も完璧に動作する。嬉しいっ!!

 
PC の技術はどんどん進化しているんだけど UEFI+CSM 時代は 10.1-RELEASE が一番良いと思っていた (suspend/resume していた)。そして、 UEFI 時代の FreeBSD は今度でる 13.1-RELEASE が最適なバージョンになるでしょうなぁ。今回利用した 13.0-STABLE の出来の良さに驚いたのでありました。

もし、手元に UEFI のみで動作するバリバリ最新の PC があるのであれば、是非とも FreeBSD をインストールしてみて頂きたいものであります。

いやぁ。今回は「イバラの道」というのは 13.0-RELEASE インストールでフリーズする以外、13.0-STABLE をチョイスして drm-kmod-master をインストールしたらスルっと、なんの苦労もなく動作したので、幸せな日々が送れて嬉しいのであります;-)。

このネタ、もう完結してしまって、続きませんf(^^;。

11月 102021
 

過去に何回か ThinkPadE145 や ThinkPad X13 に FreeBSD をインストールしているネタとか書いているのですが、 12.2-RELEASE の頃は Windows の UEFI を boot1.efifat が上書きしてしまい、Windows がブートしなくなってしまう。と、書いています。なので、FreeBSD インストール時には FreeBSD 専用の EFI パーティションを切ってあげると FreeBSD はそこを利用することになるので Windows が無事に動作して、マルチブートが可能な状態になるんですね。

しかし、まぁ、FreeBSD/adm64 13.0-RELEASE からは Windows の EFI パーティションの中に bootx64.efi を書き込んでブート情報を Windows と同列に設定してくれるようになりました。
Windows 側で mountvol して以下のオペレーションをする必要がなくなりました。

C:\Windows\system32> mountvol
C:\Windows\system32> mountvol z: /S
C:\Windows\system32> z:\
z:\> mkdir EFI\FreeBSD\Boot 
z:\> cd EFI\FreeBSD\Boot 
z:\> copy c:\boot1.efi ./bootx64.efi
z:\> dir
z:\> c:\
C:\Windows\system32> exit

 
この部分を bsdinstall がやってくれるようになりました。なので、うも、なんの遠慮もなく、何回でも FreeBSD のインストールが可能になりました。嬉しいことですね。

ただ、一点。「Firmware Windows Boot Manager」に対しては bcdedit /set {fwbootmgr} displayorder {UUID} /addfirst するようで、 FreeBSD の起動が一番上に来ます。 PC を再起動すると FreeBSD がブートするので『あらら? Windows パーティション飛ばしてしまったか?』となりますが、PC の BIOS (UEFI) のブートの順番画面で変えてあげると Windows が無事にブートします。
なので、いつもブートする OS を Windows か FreeBSD どちらにするかの選択が容易にできるようになります。

さぁ、皆さんもドドドと、 PC に FreeBSD をインストールしてみましょうっ!!

 
と、いうことで今回のエントリはこれで終了。次回のエントリは 13.0-STABLE について書いてみます;-)。

10月 222021
 

以前のエントリで、FreeBSD の VRF (setfib) は正しく使えない。と、書いたことがありました。エントリ的には「FreeBSD でポリシールーティング。」と、いうヤツですね。

setfib 0 の中に setfib 1 のルーティング情報が載ってしまい、ルーティングテーブルがインターフェースと結びついていない。と、いうのが問題点だ。と、書いています。

しかし、設定の詳しい人に聞いてみるとちゃんとそーいう設定ができるらしいんですね。ちょっと、今更感満載なんですけども・・f(^^;;。
/etc/rc.conf に以下のように書くと良いみたいです。

#defaultrouter="192.168.22.1"
#ipv6_defaultrouter="2001:470:fe36:beef::1"

static_routes="0:vmx0 1:em0"
route_0="-net -inet default -gateway 192.168.22.1 -fib 0"
route_1="-net -inet default -gateway 192.168.1.1  -fib 1"

ipv6_static_routes="0:vmx0 1:em0"
ipv6_route_0="-net -inet6 default -gateway 2001:470:fe36:beef::1  -fib 0"
ipv6_route_1="-net -inet6 default -gateway 3ffe:6580:aa40::ffff:1 -fib 1"

ifconfig_vmx0="inet 192.168.22.20 netmask 255.255.255.0 fib 0"
ifconfig_em0="inet 192.168.1.20   netmask 255.255.255.0 fib 1"

ifconfig_vmx0_ipv6="inet6 2001:470:fe36:beef::20:1 prefixlen 64"
ifconfig_em0_ipv6="inet6 3ffe:6580:aa40::20:1      prefixlen 64"

 
defaultrouter の設定は必要ありません。
static_routes= と、 setfib が IPv6 対応になったので ipv6_static_routes= の二つのオプションがインターフェース名と setfib 番号を紐つけてくれます。そして、route_?= で default gateway を指定してあげれば良い。

この設定で起動したときのネットワークテーブルは以下の通り。

$ setfib 0 netstat -nr -f inet
Routing tables (fib: 0)
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         vmx0
127.0.0.1          link#1             UH          lo0
192.168.22.0/24    link#2             U           vmx0
192.168.22.20      link#3             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS         em0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U           em0
192.168.1.20       link#3             UHS         lo0

 
良い感じですねぇ。これで 192.168.1.30 辺りの PC から ping を打つと em0 から入ってきて、em0 から抜けていきます。良かったですねぇ。

 
しかし、問題なのは上記の設定を施したサーバ側です。

なんか、僕は思いっきり勘違いしていたか安直に考えすぎていました。 setfib した PC はなんでもかんでも setfib 0 側から出て行ってしまいます。これは想定していなかった・・。

em0 側に 192.168.1.0/24 が付いているのに、とある PC に対して ping 192.168.1.30 すると setfib 0 側、つまり、vmx0 側から出ていきます。
192.168.1.30 側では 192.168.22.20 に返すんだけど、返ってきていないことになっていて、到達性がない状態・・。orz

setfib を利用した VRF でルーティングテーブルが二つに分かれるのは良いんだけど、コネクテッドな IP アドレスに対するアクセスは setfib 0 のルーティングテーブルに関係なく、コネクテッドなインターフェースからパケットが出て行ってほしかった・・。

と、いうか、出ていくモノだと、思っていた。ここが、考えが甘かった点です・・。orz
うーむ・・。世間一般の VRF って、こーいう仕様なのか?

sysctl でコネクテッドな IP アドレスの場合はコネクテッドなインターフェースからパケットが出ていく。と、いうオプションはないものかのぉ・・。orz

 
この仕様のおかげで色々なものが動作しない・・。今悩んでいるのは MRTG。
ウェブ UI は setfib 0 を向いているんだけど、MRTG で情報を取得したいのは em0 なコネクテッドな IP アドレスを持つ宛先。 em0 側はそもそも LAN-ZONE でメンテナンスインターフェースという想定だしねぇ・・。

setfib 1 snmpwalk -v2c -c ICMPv6 192.168.1.30 system

 
これは動くんだけど、 MRTG.cfg に 192.168.1.30 にアクセスする設定を書いた mrtg を動作させようとしても動かない・・。

setfib 1 /usr/local/bin/mrtg /pathto/MRTG.cfg

 
mrtg は setfib 1 を無視して setfib 0 側から出ていくようです。まぁ、perl の内部構造に対して setfib 1 を食わせてあげないとどうしようもない状態かな。

似たようなのに httpd と MySQL の関係もありますな。 httpd は vmx0 側に開いているのは良いことで、別のサーバのコネクテッドな IP アドレスを持つ mysqld へのアクセスは em0 側で行いたい。だけど setfib 0 側から mysqld へのアクセスが出ていくのでこれはアクセスできんぞぉ・・

ansible も動かなくなった・・。AWX と ansible-playbook の関係も似たようなもん。もう、ヒサンすぎる・・。 orz

NFS マウントも /etc/fstab 内ではできなくて、 /etc/rc.clocal 内で setfib 1 mount_nfs -o tcp -o rw hoge と記載すると良いよ。なんてのが、どこかのフォーラムに書かれていたなぁ。 /etc/fstab が setfib に対応していない。

 
と、いうことでやっぱり FreeBSD の VRF は利用するのをやめる予感。

今のように出ていくパケット (established なパケット。と、いう意味かな) は何でもかんでも setfib 0 から出ていく。と、いうのとは別に、コネクテッドな IP アドレスの場合はコネクテッドなインターフェースからパケットが出ていく。と、いうオプションを用意してくれても良いと思うのだけどなぁ・・。

やっぱり pf のポリシールーティングに戻るかねぇ・・。

 
と、いうか、最後に書くんだけど、ネットワーク構成がまちがっている。と、いうことかな。

  • setfib 0 : em0 : サービス提供用ネットワーク
  • setfib 0 : em1 : バックヤード用ネットワーク
  • setfib 1 : em2 : ssh でのメンテナンス専用ネットワーク

 
FreeBSD で setfib な VRF を利用するにはこのように三つのネットワークが必要で「バックヤード用ネットワーク」は MRTG とか snmp、MySQL へのアクセス、と、いう感じでその目的をにして、「ssh でのメンテナンス専用ネットワーク」はリモート管理用に setfib をわけてあげる。と、いう感じですかねぇ。

10月 042021
 

今までは MVNO の IIJmio を契約していて、スマートウオッチが 990yen で売っていたので購入しようとしたら、免許証の写真をアプロードしろだのと、スマートウオッチ買うために、スマートフォン購入時と同じ手続きをしなければならない。
サポートに電話して確認しようとしたら 0570 の電話番号だし、最近 IIJmio のアプリポロボロだし IIJ なのにウェブページにアクセスしようとしてもクラウドに AutoScale とかしようとしないのか、全然見ることできないし・・。
ホトホト嫌気がさして、サクっと解約。ついこの間「IIJmio ギガプラン」の 4GB 版に更新したばっかりだけど、約二ヶ月で解約。

 
と、いうことで三台あるスマートフォン (Apple iPhoneOPPO Reno ASONY Xperia 10II (XQ-AU52)) うち、IIJmio で利用していたのは Xperia だったので、そこに楽天モバイル並の料金で運用できると思われる povo 2.0 を導入してみることにしました。
ちなみに楽天モバイルの SIM は Reno A に入っています。iPhone8 には Y-monile が入っています。

で、今回は物理 SIM なので、届いたのはこんな感じ。

CD みたいな梱包でした。

 
さてと。結論からいいますと Xperia 10II の海外版である XQ-AU52 では、au の SIM である povo は、通話ができませんでした。データ転送は特に問題なく利用できます。

通話のほうについては、箇条書きで。

  • Xperia 10II の海外版である XQ-AU52 は日本国内の VoLTE に対応していません。
  • au は 3G の場合は WCDMA なので XQ-AU52 では 3G に接続できません。
  • 国内向け VoLTE に対応していないスマートフォンは、フツーであれば、通話は 3G で行います。が、XQ-AU52 は WCDMA に接続できません。

 
と、いうことでデータ通信はできますが、通話はできません。Android の「デバイス情報」で確認しても SIM が入っている スロット 1 では電話番号が “不明” となっています。

まぁ、XQ-AU52 での通話に関してはあきらめましょうかねぇ。 VoLTE に対応していない端末で au の SIM を利用しようとした (つまりは何も予備知識・事前の調査などをしていなかった・・。orz) 当人がダメだった。と、いうことでしょうなぁ・・。

ちなみに iPhone8 と RenoA では問題無く通話もデータ通信も行うことができました。

 
なお、データ通信についてですが、特に問題なくできました。
APN は簡単なので手で打っても問題ないですし「ネットワークとインターネット」のメニューから「インターネット設定」をタップすると APN の情報をダウンロードして来てくれるので povo の設定をそのまま利用することができます。

「優先ネットワークの種類」は Android の隠しコマンド *#*#4636#*#* で LTE Only も選択可能ですが、その辺りについては、特に意識する必用もなく LTE/WCDMA/GSM でも大丈夫でした。

 
と、いうことで、早速 データ追加 1GB (7 日間) を 390yen で購入してみましたが、検証段階で、あっという間に終わってしまいましたf(^^;;。

では、トッピングを購入していない povo ではどれくらい利用できるのか?僕の思った感覚ですが、

  • 通話の受信は大丈夫。SMS の受信も大丈夫 (XQ-AU52 以外の端末で)。
  • データ通信時、トッピングがない場合、povo 2.0 のアプリを起動してトッピングを購入する程度の通信はできる。常用するには無理がある・・。
  • XQ-AU52 は au のメインチャンネルである Band18 が利用できないので、そもそも au の SIM には根本的に向かない端末である。

こんな雰囲気でしょうかねぇ・・。トッピング購入せずに利用する。と、いうのは携帯電話の受電と SMS の受信のみが効果的でしょうかねぇ・・。

 
さてと。僕の場合、 XQ-AU52 で au の SIM が利用できない。と、いうことが解ったので、このまま、トッピングは購入せず 180 日後に自動解約・・。と、いう運命をたどりそうな感じなのであります・・。

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 を開けるときが、今っ!! 来ましたっ!! ;-)。