コグノスケ

Ubuntu 20.04 LTSでxrdpのエラーを再現できるか挑戦

目次: Linux

先日（2024年10月1日の日記参照）のUbuntu 22とxrdpの組み合わせで起きるエラーですが、Ubuntu 20で再現できるかやってみました。グラフィクスは種類が違いますがAMDのGPU（Radeon RX 6900 XT）です。条件は同様でgdm3は終了させてxrdpのみ起動しています。

結論から言うと再現しました。以下が通常時のログです。正常に画面が表示されます。

gnome-session-binary[2712263]: DEBUG(+): Enabling debugging
gnome-session-binary[2712263]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-binary[2712263]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
gnome-session-binary[2712263]: WARNING: Error creating FIFO: File exists

ログにはデバッグ有効であること以外は特に何も出ません。FIFOが作れない警告が出ます、これは何だろう？まあいいか。

次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。画面は真っ黒になってすぐに切断されます。Ubuntu 20.04 LTSでも再現するんですね。ログは下記のようになりました。

gnome-session-binary[2712010]: DEBUG(+): Enabling debugging
gnome-session-binary[2712010]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:2712146): WARNING **: 14:44:50.573: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[2712010]: DEBUG(+): hardware acceleration check failed: Child process exited with code 1
gnome-session-binary[2712010]: GLib-DEBUG(+): setenv()/putenv() are not thread-safe and should not be used after threads are created
gnome-session-binary[2712010]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:2712203): WARNING **: 14:44:55.610: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[2712010]: WARNING: software acceleration check failed: Child process exited with code 1
gnome-session-binary[2712010]: CRITICAL: We failed, but the fail whale is dead. Sorry....

前回も見かけたamdgpu_get_auth()のエラーが出て止まりました。AMDのGPUの場合、エラーが起きると止まってしまう疑いが強まりました。本当はエラーが起きたらソフトウェアレンダリングにフォールバックしてほしいんですけど、そうならないようです……。

デバイスファイルが/dev/driに全く存在しなくてもamdgpu_get_auth()が怒ってくるところを見ると、X.orgはPCのグラフィクスの種類（VirtualBoxなのかAMDのGPUなのか）を最初から決め打ちにしているんですね。

VirtualBoxでxrdpのエラーを再現できるか挑戦

目次: Linux

昨日（2024年10月1日の日記参照）のUbuntu 22とxrdpの組み合わせで起きるエラーですが、VirtualBox 7.0.18で再現できるかやってみました。グラフィクスはVMSVGAを選択しています。VMSVGAは/dev/driの下にcard0とrenderD128が生成されるようです。ちなみにgdm3は終了させてxrdpのみ起動しています。

ちなみに結論から言っておくと再現しません。以下が通常時のログです。正常に画面が表示されます。

gnome-session-binary[2774]: DEBUG(+): Enabling debugging
gnome-session-binary[2774]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’

ログにはデバッグ有効であることと、libEGLが何かしら見つけて反応しています。それ以外は特に何も出ません。

次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。しかし正常に画面が表示されます。えぇー？ログは下記のようになりました。

gnome-session-binary[4319]: DEBUG(+): Enabling debugging
gnome-session-check-accelerated: GL Helper exited with code 512
libEGL warning: DRI2: failed to authenticate
gnome-session-check-accelerated: GLES Helper exited with code 512
gnome-session-binary[4319]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’

AMDのGPUでも見かけたfailed to authenticateが出ています。が、エラーは無視されるんでしょうか？謎の動きですね。

Ubuntu 22.04のxrdpに接続できない病

目次: Linux

WindowsからUbuntu 22.04 LTSのxrdpに接続すると真っ黒な画面しか出ず、すぐに接続が切断されてしまう問題に遭遇しました。どこでクラッシュしているか調べるため、xrdpがGNOMEを起動するところまでを追いかけると下記のようになっていました。

/etc/xrdp/startwm.sh
  exec /bin/sh /etc/X11/Xsession
    /etc/X11/Xsession.d/99x11-common_start
      /usr/bin/ssh-agent /usr/bin/im-launch x-session-manager
        /usr/bin/x-session-manager
          /usr/libexec/gnome-session-binary

スクリプトx-session-managerを書き換えてgnome-session-binaryの引数に--debugを足すと、GNOMEはより詳細なメッセージを出力します。メッセージはホームディレクトリの.xsession-errorsに記録されます。GNOMEのエラーメッセージは下記です。

** (gnome-session-check-accelerated-gles-helper:3301100): WARNING **: 13:50:04.884: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[3300977]: DEBUG(+): hardware acceleration check failed: Child process exited with code 1
gnome-session-binary[3300977]: GLib-DEBUG(+): setenv()/putenv() are not thread-safe and should not be used after threads are created
gnome-session-binary[3300977]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256    ★★ここでエラーが発生している
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:3301174): WARNING **: 13:50:09.927: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[3300977]: WARNING: software acceleration check failed: Child process exited with code 1
gnome-session-binary[3300977]: CRITICAL: We failed, but the fail whale is dead. Sorry....

エラーメッセージ曰くamdgpu_get_auth()が失敗しています。関数名から推測するにAMDのGPUが装着されているマシンでしか発生しないエラーなのかもしれません。この関数は何者なのかDRMのソースコード（Mesa/libdrmのソースコードリポジトリへのリンク）を見ると、

// drm/amdgpu/amdgpu_device.c

/**
* Get the authenticated form fd,
*
* \param   fd   - \c [in]  File descriptor for AMD GPU device
* \param   auth - \c [out] Pointer to output the fd is authenticated or not
*                          A render node fd, output auth = 0
*                          A legacy fd, get the authenticated for compatibility root
*
* \return   0 on success\n
*          >0 - AMD specific error code\n
*          <0 - Negative POSIX Error code
*/
static int amdgpu_get_auth(int fd, int *auth)
{
	int r = 0;
	drm_client_t client = {};

	if (drmGetNodeTypeFromFd(fd) == DRM_NODE_RENDER)
		*auth = 0;
	else {
		client.idx = 0;
		r = drmIoctl(fd, DRM_IOCTL_GET_CLIENT, &client);    //★★エラーを返すのはこの関数だけ★★
		if (!r)
			*auth = client.auth;
	}
	return r;
}


// drm/xf86drm.c

/**
 * Call ioctl, restarting if it is interrupted
 */
drm_public int
drmIoctl(int fd, unsigned long request, void *arg)
{
    int ret;

    do {
        ret = ioctl(fd, request, arg);    //★★drmIoctl()はioctl()が返すエラーをそのまま返す★★
    } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
    return ret;
}

ソースコードから推測するにグラフィクス系のデバイスファイルにioctl()しようとして失敗しているものと思われます。

XのグラフィックスはDRI（Direct Rendering Infrastructure）と呼ばれるインタフェースを経由してGPUを使用します。Xとカーネルの間にはlibDRMがおり、libDRMはLinuxカーネルのDRM（Direct Rendering Manager）を使用してGPUにアクセスします。DRMのデバイスファイルは/dev/driディレクトリの下にありますが、名前がDRIだったりDRMだったりして謎ですね。グラフィクス周りはあまり詳しくなくて理由はわかりません……。

# ls /dev/dri/* -la

crw-rw-rw-+ 1 root video  226,   0  4月 30 15:00 /dev/dri/card0
crw-rw-rw-+ 1 root render 226, 128  4月 30 15:00 /dev/dri/renderD128

上記のようにキャラクタデバイス/dev/dri/card0と/dev/dri/renderD128のパーミッションを0666にしたところエラーが出なくなりました。今回はこの2つのデバイスファイルで解決しましたが、他のデバイスファイルにもアクセスしていた場合はさらに調査が必要かもしれません。グラフィクス系のエラーは簡単に調べる方法がないのが辛いですね。

ちなみにこの症状はQEMUだと再現しません。card0のパーミッションを0000にするとlibEGLがエラーになるのですが、なぜかGNOMEはエラーを無視して起動してしまいます。AMDのときだけなんで止まるんでしょうか。いまいち釈然としません……。

TAS動画をニコニコ動画にアップロードできない

クラッキングでぶっ壊されてしまったニコニコ動画が復活し、シン・ニコニコ動画になって帰ってきました。いちユーザーとしては嬉しい気分でいっぱいです。

しかし前と比べて困ったことが起きていて、BizHawkで出力した動画をシン・ニコニコ動画にアップロードしようとすると「この動画の映像形式には対応していません」とエラーが出てしまって投稿できません。試行錯誤の末、解決方法を見つけたのでメモしておきます。

端的に言えば原因はピクセルフォーマットでした。BizHawkは特に何も言わないとYUV444で出力しますが、ニコニコ動画はYUV420でないと受け付けてくれないようです。どこにもそんな制約は書いていないため、仕様か？バグか？どちらともわかりません。

YUV420にする方法ですけども、BizHawkの出力設定を[Custom]にして、下記のようにピクセルフォーマットを明示的に指定すればYUV420で出力してくれました。

-c:a aac -c:v libx264 -preset ultrafast -pix_fmt yuv420p -f mp4

もしすでにYUV444で出力済みの動画ならば、ffmpegを使って再エンコードすれば良いです。

$ ffmpeg -i input.mp4 \
    -vcodec libx264 -vb 2048000 -r 60 -s 1280x720 -pix_fmt yuv420p \
    -acodec aac -ar 44100 -ab 192000 output.mp4

動画ビットレート（-vb）、フレームレート（-r）、動画サイズ（-s）は元の動画に応じて調整してください。

Yoctoの並列Fetchでエラーが起きるとき

目次: Yocto

Yoctoは特に何も指定せずにビルドすると全スレッドを使おうとします。この挙動はコンパイルだけでなくFetchでも同様のようです。最近のCPUは一般向けでも8〜16スレッドが珍しくないので、何も考えずにbitbakeを実行すると16接続同時にFetchを試みて、サーバー側の同時接続数制限か何かに引っかかってエラーで落ちます。

このエラーが鬱陶しくて困っていたのですが、並列数を2〜4程度（サーバーに蹴られない接続数）に制限して、最初にFetchだけ実行してしまうとよさそうです。

BB_NUMBER_THREADS=2 bitbake core-image-sato --runall=fetch

一度Fetchが終わればその後はFetchしませんから、並列数を16でも32でも好きな数にして良いです。

OpenSBIを調べる - scratch領域の詳細

目次: Linux

今回はOpenSBIのコード内に頻出するscratch領域について調べます。OpenSBI内で設定値を格納するために何かと登場するscratch領域ですが、hartごとに用意されている領域であることくらいしか知りません。具体的にどこに配置されるのか？どんな領域があるのか？を調べます。

まずscratch領域の場所を調べましょう。アセンブラで書かれている_hartid_to_scratch()関数を読み解くのがわかりやすいでしょう。

// opensbi/lib/sbi/sbi_scratch.c

int sbi_scratch_init(struct sbi_scratch *scratch)
{
	u32 i, h;
	const struct sbi_platform *plat = sbi_platform_ptr(scratch);

	for (i = 0; i < plat->hart_count; i++) {
		h = (plat->hart_index2id) ? plat->hart_index2id[i] : i;
		hartindex_to_hartid_table[i] = h;
		//★★scratch領域の先頭アドレスはhartindex_to_scratch_table[]に保存されている★★
		hartindex_to_scratch_table[i] =
			((hartid2scratch)scratch->hartid_to_scratch)(h, i);
	}

	last_hartindex_having_scratch = plat->hart_count - 1;

	return 0;
}


// opensbi/firmware/fw_base.S

	.globl _hartid_to_scratch
_hartid_to_scratch:
	/*
	 * a0 -> HART ID (passed by caller)
	 * a1 -> HART Index (passed by caller)
	 * t0 -> HART Stack Size
	 * t1 -> HART Stack End
	 * t2 -> Temporary
	 */
	lla	t2, platform
#if __riscv_xlen > 32
	lwu	t0, SBI_PLATFORM_HART_STACK_SIZE_OFFSET(t2)
	lwu	t2, SBI_PLATFORM_HART_COUNT_OFFSET(t2)
#else
	lw	t0, SBI_PLATFORM_HART_STACK_SIZE_OFFSET(t2)
	lw	t2, SBI_PLATFORM_HART_COUNT_OFFSET(t2)
#endif
	sub	t2, t2, a1    /* hart数 - hart indexに */
	mul	t2, t2, t0    /* スタックサイズを掛ける */
                              /* index 0が末尾側、index 1が末尾の1つ手前となる */
	lla	t1, _fw_end   /* OpenSBIバイナリの終端、メモリマップを参照 */
	add	t1, t1, t2    /* _fw_endの後ろがスタック領域 */
	li	t2, SBI_SCRATCH_SIZE    /* 現状はSBI_SCRATCH_SIZE = 0x1000 */
	sub	a0, t1, t2    /* スタック領域の末尾がscratch領域 */
	ret

コードを見る限り、scratch領域の場所を知るにはhartindexが必要です。hartindexはhartに関係する何かの配列のindexに使う値です。0〜hart数 - 1の値を取ります。

なぜhartidをindex代わりにしないのか？理由はRISC-Vのhartidがindex値として適していないからです。hartidは0から始まる連続した値とは限らず、非連続でも構いませんし、非常に大きな値をとっても構いません（推奨はされませんが）。そのためhartindexのような別概念を持ち出す必要があります。ちなみにhartindexとhartidの関係はhartindex_to_hartid_table[]に保持されています。

例えばhart数4、hartindex 0だとしますと、スタック領域はhart数分つまり4つあります。scratch領域の先頭は
(4 - 0) * hart_stack_size - SBI_SCRATCH_SIZE
なので、4つ目のスタック領域の末尾 - 0x1000です。図示したほうがわかりやすいでしょう。

スタック領域とscratch領域の関係

アドレスの高位側からhartindex 0, 1, 2, ...用のスタックおよびscratch領域が並んでいて、hartindex_to_hartid_table[]にhartindexとhartidの関係が保存されており、hartindex_to_scratch_table[]にhartindexとscratch領域の先頭アドレスの関係が保存されています。

scratch領域の中身

以上でscratch領域の場所はわかりました。次は領域の内部を調べましょう。コードを見るとscratch領域は2つの機能があります。

• 先頭にstruct sbi_scratchが存在
• 以降はsbi_scratch_alloc_offset()関数で確保するための領域

先頭に構造体があって、その後の領域はOpenSBI内で自由に確保して使う方式です。領域の確保にはsbi_scratch_alloc_offset()関数を使用します。コードはこんな感じ。

// opensbi/lib/sbi/sbi_scratch.c

unsigned long sbi_scratch_alloc_offset(unsigned long size)
{
	u32 i;
	void *ptr;
	unsigned long ret = 0;
	struct sbi_scratch *rscratch;

	/*
	 * We have a simple brain-dead allocator which never expects
	 * anything to be free-ed hence it keeps incrementing the
	 * next allocation offset until it runs-out of space.
	 *
	 * In future, we will have more sophisticated allocator which
	 * will allow us to re-claim free-ed space.
	 */

	if (!size)
		return 0;

	size += __SIZEOF_POINTER__ - 1;
	size &= ~((unsigned long)__SIZEOF_POINTER__ - 1);

	spin_lock(&extra_lock);

	if (SBI_SCRATCH_SIZE < (extra_offset + size))
		goto done;

	//★★extra_offsetは最初struct sbi_scratchの末尾を指している★★
	//★★sbi_scratch_alloc_offset()が成功するたびに高位側のアドレスにズレていく★★
	ret = extra_offset;
	extra_offset += size;

done:
	spin_unlock(&extra_lock);

	if (ret) {
		for (i = 0; i <= sbi_scratch_last_hartindex(); i++) {
			rscratch = sbi_hartindex_to_scratch(i);
			if (!rscratch)
				continue;
			ptr = sbi_scratch_offset_ptr(rscratch, ret);
			sbi_memset(ptr, 0, size);
		}
	}

	return ret;
}

柔軟で面白い仕組みですがscratch領域内に保存された情報がどこにあるか分かりづらく、コードを読む側としては嫌な作りとも言えます。下記の図にscratch領域にメモリを確保するとどうなるか？を示します。

scratch領域の初期状態

100バイトメモリ確保した後のscratch領域の状態

初期状態と100バイトのメモリ確保を行った後で、scratch領域のメモリマップとextra_offsetが高位側のアドレスにズレる様子を表しました。

scratch領域にメモリを確保する人たち

実際にはたくさんの領域が確保されます。下記はsbi_scratch_alloc_offset()を呼んでscratch領域にメモリを確保し、どんな種類のデータを何バイト確保しているか？の一覧表です。

表の1列目はsbi_scratch_alloc_offset()の返り値を保存している変数名です。hart_features_offsetを例にして、領域の確保を行っているコードと、領域のアドレスを取得するコードを見ましょう。

// opensbi/lib/sbi/sbi_hart.c

int sbi_hart_init(struct sbi_scratch *scratch, bool cold_boot)
{
	int rc;

	/*
	 * Clear mip CSR before proceeding with init to avoid any spurious
	 * external interrupts in S-mode.
	 */
	csr_write(CSR_MIP, 0);

	if (cold_boot) {
		if (misa_extension('H'))
			sbi_hart_expected_trap = &__sbi_expected_trap_hext;

		//★★scratch領域に領域を確保する方法★★
		//★★領域を確保して、scratch領域先頭からのオフセットアドレス（＝返り値）を★★
		//★★hart_features_offsetに保存★★
		hart_features_offset = sbi_scratch_alloc_offset(
					sizeof(struct sbi_hart_features));
		if (!hart_features_offset)
			return SBI_ENOMEM;
	}

	rc = hart_detect_features(scratch);
	if (rc)
		return rc;

	return sbi_hart_reinit(scratch);
}

bool sbi_hart_has_extension(struct sbi_scratch *scratch,
			    enum sbi_hart_extensions ext)
{
	//★★scratch領域に確保した領域を参照する方法★★
	struct sbi_hart_features *hfeatures =
			sbi_scratch_offset_ptr(scratch, hart_features_offset);

	if (__test_bit(ext, hfeatures->extensions))
		return true;
	else
		return false;
}

端的に言うと領域の確保にsbi_scratch_alloc_offset()関数、領域の参照にsbi_scratch_offset_ptr()関数を使えば良いです。

複数hartの場合は問題ない？

結論から言うと問題は起きません。領域確保時と領域参照時に分けて考えましょう。

最初にscratch領域のメモリを確保する場合です。これは単純で、初期化を担当する1つのhartだけがscratch領域のメモリ確保を行えば、同じ領域をダブって確保してしまう問題は発生しません。

次にscratch領域を参照する場合です。全てのhartが同じオフセットを使用すれば、重なったりはみ出たりする問題は発生しません。例えばsbi_scratch_alloc_offset()関数で確保したメモリ領域Aがありサイズ16、オフセット120だとしたら、全hartのscratch領域にメモリ領域Aが存在していて、同じサイズとオフセットであるとみなします。全hartのscratch領域の大きさが同じだからできる芸当ですね。

これで謎に包まれたOpenSBIのscratch領域も多少は晴れたはずです。たぶん……。