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