ToDo:
LV8からのリプレース機
Meteor Lake-Pなので、そのままだと色々デバイス認識しないので、ハックする
一応、タッチパッドと無線LANのdriver attachまでは出来たので、/etc, /usr/local/etcまわりの設定作業と運用試験に進める
実運用に移るのに必要な確認項目
Meteor Lake-PがPコア/Eコア/LEコア混載なので、thread scheduler起因とおぼしき妙な遅延(LEコアにタスクが割り当てられている？)や有線LANの速度低下(Rx側で顕著)が見られる
確かに、Pコアx6だけでもmake buildworldはLV8より早いのだが、LV8だと素直に上り下り共に110MB/sec出てるのに、FV5だとRxが60MB/sec止まり Orz
コメントにある通り、小手先のidProduct追加程度ではどうにもなりそうに無いくらい前世代から仕様が異なる模様
一応、実験的なコードはある模様なので、実験してみる
Command: iwmbtfw -D -I -d ugen1.4 -f /usr/local/share/iwmbt-firmware main: opening dev 1.4 iwmbt_is_tlv: found TLV iwmbt_dump_one_tlv: TLV: 0x10 = 0x00000800 iwmbt_dump_one_tlv: TLV: 0x11 = 0x00000410 iwmbt_dump_one_tlv: TLV: 0x12 = 0x00003700 iwmbt_dump_one_tlv: TLV: 0x15 = 0x0613 iwmbt_dump_one_tlv: TLV: 0x16 = 0x0000 iwmbt_dump_one_tlv: TLV: 0x17 = 0x8087 iwmbt_dump_one_tlv: TLV: 0x18 = 0x0033 iwmbt_dump_one_tlv: TLV: 0x1c = 0x01 iwmbt_dump_one_tlv: TLV: 0x1d = 0x1612 iwmbt_dump_one_tlv: TLV: 0x1e = 0x01 iwmbt_dump_one_tlv: TLV: 0x1f = 0x0000c072 iwmbt_dump_one_tlv: TLV: 0x27 = 0x00 iwmbt_dump_one_tlv: TLV: 0x28 = 0x01 iwmbt_dump_one_tlv: TLV: 0x29 = 0x00 iwmbt_dump_one_tlv: TLV: 0x2a = 0x01 iwmbt_dump_one_tlv: TLV: 0x2b = 0x01 iwmbt_dump_one_tlv: TLV: 0x2c = 0x00 iwmbt_dump_one_tlv: TLV: 0x2d has unhandled length of 3 iwmbt_dump_one_tlv: TLV: 0x2e = 0x00 iwmbt_dump_one_tlv: TLV: 0x2f = 0x01 iwmbt_dump_one_tlv: TLV: 0x30 has unhandled length of 6 iwmbt_dump_one_tlv: TLV: 0x31 = 0x00 iwmbt_dump_version: status 0x00 iwmbt_dump_version: hw_platform 0x37 iwmbt_dump_version: hw_variant 0x1b iwmbt_dump_version: hw_revision 0x00 iwmbt_dump_version: fw_variant 0x00 iwmbt_dump_version: fw_revision 0x00 iwmbt_dump_version: fw_build_num 0x00 iwmbt_dump_version: fw_build_ww 0x00 iwmbt_dump_version: fw_build_yy 0x00 iwmbt_dump_version: fw_patch_num 0x00 main: fw_variant=0x00 main: firmware_path = /usr/local/share/iwmbt-firmware/ibt-0180-0041.sfi iwmbt_init_firmware: loading /usr/local/share/iwmbt-firmware/ibt-0180-0041.sfi iwmbt_load_fwfile: file=/usr/local/share/iwmbt-firmware/ibt-0180-0041.sfi, size=824316 iwmbt_load_fwfile: transferring 128 bytes, offset 644 ... iwmbt_load_fwfile: transferring 208 bytes, offset 824076 iwmbt_load_fwfile: transferring 4 bytes, offset 824284 iwmbt_load_fwfile: boot_param=0x00100800 iwmbt_load_fwfile: transferring 28 bytes, offset 824288 main: Firmware download complete main: Firmware operational iwmbt_dump_version: status 0x00 iwmbt_dump_version: hw_platform 0x37 iwmbt_dump_version: hw_variant 0x1b iwmbt_dump_version: hw_revision 0xa0 iwmbt_dump_version: fw_variant 0x63 iwmbt_dump_version: fw_revision 0x0c iwmbt_dump_version: fw_build_num 0x00 iwmbt_dump_version: fw_build_ww 0x00 iwmbt_dump_version: fw_build_yy 0x0e iwmbt_dump_version: fw_patch_num 0x18 main: ddc_path = /usr/local/share/iwmbt-firmware/ibt-0180-0041.ddc iwmbt_init_ddc: loading /usr/local/share/iwmbt-firmware/ibt-0180-0041.ddc iwmbt_load_ddc: file=/usr/local/share/iwmbt-firmware/ibt-0180-0041.ddc, size=9 iwmbt_load_ddc: transferring 4 bytes, offset 0 iwmbt_load_ddc: transferring 5 bytes, offset 4 main: DDC download complete main: Intel Event Mask is set main: Firmware download is successful! Command exit status: 0
運用に必要な道具はだいたい揃ってきたので、/etc, /usr/local/etcを整理と/home同期を行って入れ替えかなぁ…(Windows側の設定・データ引き継ぎ作業が残っているが)
とりあえず、必要そうな作業のピックアップ
設定系は、ほぼ完了
後は、/homeの転送・同期して本番環境と入れ替えるのみ
現時点で判明しているCF-LV8に対するRegressionは…
あとは、Windows環境の引き継ぎ作業がまるまる残っている
それと、Bluetooth firmwareの検証とパッチの整理 (CF-FV5まとめにまとめた)
LV8との違いで見つけた件
acpi_videoのprobe/attachで照合している内部情報を吐かせるパッチを当てて、CF-FV5とCF-LV8を比べてみる
--- sys/dev/acpica/acpi_video.c.orig
+++ sys/dev/acpica/acpi_video.c
@@ -528,6 +528,9 @@ acpi_video_bind_outputs_subr(ACPI_HANDLE handle, UINT32 adr, void *context)
struct acpi_video_softc *sc;
struct acpi_video_output *vo;
+ if (bootverbose)
+ printf("acpi_video_bind_outputs_subr: %s\n", acpi_name(handle));
+
ACPI_SERIAL_ASSERT(video);
sc = context;
@@ -564,6 +567,9 @@ acpi_video_vo_init(UINT32 adr)
const char *type, *desc;
struct acpi_video_output_queue *voqh;
+ if (bootverbose)
+ printf("acpi_video_vo_init[0x%08x]\n", adr);
+
ACPI_SERIAL_ASSERT(video);
switch (adr & DOD_DEVID_MASK) {
@@ -698,6 +704,9 @@ static void
acpi_video_vo_bind(struct acpi_video_output *vo, ACPI_HANDLE handle)
{
+ if (bootverbose)
+ printf("acpi_video_vo_bind: %s\n", acpi_name(handle));
+
ACPI_SERIAL_BEGIN(video_output);
if (vo->vo_levels != NULL) {
AcpiRemoveNotifyHandler(vo->handle, ACPI_DEVICE_NOTIFY,
@@ -1021,16 +1030,37 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 level __unused,
ACPI_SERIAL_ASSERT(video);
argset = context;
status = acpi_GetInteger(handle, "_ADR", &adr);
+ if (bootverbose) {
+ if (ACPI_FAILURE(status))
+ printf("vid_enum_outputs_subr: %s._ADR -> failed\n", acpi_name(handle));
+ else
+ printf("vid_enum_outputs_subr: %s._ADR -> 0x%08x\n", acpi_name(handle), adr);
+ }
if (ACPI_FAILURE(status))
return (AE_OK);
for (i = 0; i < argset->dod_pkg->Package.Count; i++) {
+#if 1
+ ACPI_HANDLE bcl;
+ if (ACPI_FAILURE(AcpiGetHandle(handle, "_BCL", &bcl)))
+ bcl = NULL;
+ if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0) {
+ if ((val & DOD_DEVID_MASK_FULL) == (adr & DOD_DEVID_MASK_FULL)) {
+ printf("vid_enum_outputs_subr: HIT DOD[%zd] -> 0x%08x [_BCL=%s]\n", i, val, bcl ? "true" : "false");
+ argset->callback(handle, val, argset->context);
+ argset->count++;
+ } else if (bootverbose)
+ printf("vid_enum_outputs_subr: MISS DOD[%zd] -> 0x%08x [_BCL=%s]\n", i, val, bcl ? "true" : "false");
+ } else if (bootverbose)
+ printf("vid_enum_outputs_subr[%zd]: dod_pkg error\n", i);
+#else
if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 &&
(val & DOD_DEVID_MASK_FULL) ==
(adr & DOD_DEVID_MASK_FULL)) {
argset->callback(handle, val, argset->context);
argset->count++;
}
+#endif
}
return (AE_OK);
@@ -1050,6 +1080,9 @@ vid_enum_outputs(ACPI_HANDLE handle,
dod_buf.Pointer = NULL;
status = AcpiEvaluateObject(handle, "_DOD", NULL, &dod_buf);
if (ACPI_FAILURE(status)) {
+ if (bootverbose)
+ printf("vid_enum_outputs: package[%s._DOD] evaluation failure[%d].\n", acpi_name(handle), status);
+
if (status != AE_NOT_FOUND)
printf("can't evaluate %s._DOD - %s\n",
acpi_name(handle), AcpiFormatException(status));
@@ -1071,6 +1104,8 @@ vid_enum_outputs(ACPI_HANDLE handle,
argset.context = context;
argset.dod_pkg = res;
argset.count = 0;
+ if (bootverbose)
+ printf("vid_enum_outputs: Wake in namespace[%s]\n", acpi_name(handle));
status = AcpiWalkNamespace(ACPI_TYPE_DEVICE, handle, 1,
vid_enum_outputs_subr, NULL, &argset, NULL);
if (ACPI_FAILURE(status))
acpi_video0: <ACPI video extension> on vgapci0 vid_enum_outputs: Wake in namespace[\134_SB_.PCI0.GFX0] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD01._ADR -> 0x00000100 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD02._ADR -> 0x00000002 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD03._ADR -> 0x00000300 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD04._ADR -> 0x00000301 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD05._ADR -> 0x00000302 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD06._ADR -> 0x00000303 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD07._ADR -> 0x00000304 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD08._ADR -> 0x00000305 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD09._ADR -> 0x00000009 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD0A._ADR -> 0x0000000a vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD0B._ADR -> 0x0000000b vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD0C._ADR -> 0x0000000c vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD0D._ADR -> 0x0000000d vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD0E._ADR -> 0x0000000e vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD0F._ADR -> 0x0000000f vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.DD1F._ADR -> 0x00000400 vid_enum_outputs_subr: HIT DOD[0] -> 0x00000400 [_BCL=true] acpi_video_bind_outputs_subr: \134_SB_.PCI0.GFX0.DD1F acpi_video_vo_init[0x00000400] found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 acpi_video_vo_bind: \134_SB_.PCI0.GFX0.DD1F vid_enum_outputs_subr: \134_SB_.PCI0.GFX0.IPUA._ADR -> 0x00003480 vid_enum_outputs_subr: MISS DOD[0] -> 0x00000400 [_BCL=false]
acpi_video0: <ACPI video extension> on vgapci0 vid_enum_outputs: Wake in namespace[\134_SB_.PC00.GFX0] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD01._ADR -> 0x00000001 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD02._ADR -> 0x00000002 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD03._ADR -> 0x00000003 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD04._ADR -> 0x00000004 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD05._ADR -> 0x00000005 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD06._ADR -> 0x00000006 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD07._ADR -> 0x00000007 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD08._ADR -> 0x00000008 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD09._ADR -> 0x00000009 vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD0A._ADR -> 0x0000000a vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD0B._ADR -> 0x0000000b vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD0C._ADR -> 0x0000000c vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD0D._ADR -> 0x0000000d vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD0E._ADR -> 0x0000000e vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD0F._ADR -> 0x0000000f vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=false] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD1F._ADR -> 0x0000001f vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=true] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=true] vid_enum_outputs_subr: \134_SB_.PC00.GFX0.DD2F._ADR -> 0x0000001f vid_enum_outputs_subr: MISS DOD[0] -> 0x00010000 [_BCL=true] vid_enum_outputs_subr: MISS DOD[1] -> 0x00010000 [_BCL=true]
Let'snote LV8 vs FV5でビルドタイム比較
Sourceは、stable/14のもの
| Model | CPU | -j# | world+kernel |
| CF-FV5U | Core Ultra 7 165H(6P/8E/2LE) | 12(6P) | 94:19 |
| CF-FV5U | Core Ultra 7 165H(6P/8E/2LE) | 22 | 69:58 |
| CF-LV8 | Core i7 8665U(4C) | 8 | 144:56 |
| EQ12Pro | Core i3 N305(8E) | 8 | 79:45 |
ノート対決だと、4C/8T→6C/12Tで順当にタイムが縮んでいる
が、AlderLake-Nの8C/8T相手だと、MeteorLake-Pの6P/12Tだけだと負けてる
物理コア数を考えれば、Meteor Lake-Pが健闘している事に…
もちろん、全コア投入で適切にスケジュール出来れば優位になるはずだが、 そうそう巧く行くものだろうか？
6C/8E/2LE計22-thread投入で94:19(6P)→69:58 なので劇的な短縮にはならないものの、LV8比で2倍強の性能になっている (ある意味、カタログ通り LV9→FV5でビジネスベンチで2.1倍弱と喧伝されていたはず)
EUC-JPからUTF-8へ変換実施
UTF-8モードで稼働するFDcloneでは、波ダッシュ(U+301C)だと表示がバグる
xterm/kterm(utf-8モード)上のlsだと問題無いので、内部処理で何か変換してる？
解決法は、
FreeBSD側メインでの運用を想定すると、FDCloneの変換テーブルにパッチを当てる方が素直かも
CFLAGSに、-DWAVE_DASH付けてコンパイルするとUnicode - 内部コード変換で、U+FF5Dの代わりにU+301Cを使う
元より、符号定義や運用実態が錯綜する領域なので、運用環境によっては障害が生じる点に留意
(Windows 9x相手のファイル共有を行う場合、Samba側にも手当てが必要か？)
--- mkunitbl.c.orig 2019-07-27 00:00:00.000000000 +0900
+++ mkunitbl.c 2024-06-09 15:11:47.662354000 +0900
@@ -339,6 +339,9 @@
{0x3013, 0x81ac},
{0x3014, 0x816b},
{0x3015, 0x816c},
+#ifdef WAVE_DASH
+ {0x301c, 0x8160},
+#endif
{0x301d, 0x8780},
{0x301f, 0x8781},
{0x3041, 0x829f},
@@ -9245,7 +9248,9 @@
{0xff5b, 0x816f},
{0xff5c, 0x8162},
{0xff5d, 0x8170},
+#ifndef WAVE_DASH
{0xff5e, 0x8160},
+#endif
{0xffe0, 0x8191},
{0xffe1, 0x8192},
{0xffe2, 0x81ca},
日本語(おそらくマルチバイト文字)を含む行末へCtrl-Eでカーソルを飛ばすと、 実際の行末より後ろにカーソルが飛んでいく
カーソルの位置計算がおかしい？
多分、eucJPだとワイド文字～2byte符号だったのが、utf-8だと典型的には3byte符号化している為では…
試しに、utf-8で一文字毎に送っていくと、ワイド文字で2回足踏みする
まあ、元々マルチバイト文字にきちんと対応していない訳なのだが、 eucJPだとそこそこ実用になったので重宝していた(軽いし)
LANG=ja_JP.UTF-8なKanjiMode utf8運用時、表示やコピーペーストは問題ないが、XIM入力が文字化けする
X Resource Databaseの状態が錯綜していたので、整理してみた...
解決方法に関して、
--- convert.c.orig 2016-11-05 06:41:21.000000000 +0900
+++ convert.c 2024-06-13 12:50:40.353827000 +0900
@@ -1106,7 +1106,7 @@
if (e2 = *es++) {
int c1 = e1 & ~0x80;
int c2 = e2 & ~0x80;
- int ucode = ucode_kanji1[(c1-33)*94 + (e2-33)];
+ int ucode = ucode_kanji1[(c1-33)*94 + (c2-33)];
int len = utf8_len(ucode);
if (ucode == U_error) {
素直にutf-8モードのxtermに移れ説はあるのだが、仕様しているフォントのグリフセットの都合で一部不具合が出るのでもうしばらくktermで頑張りたい (local filesystem上で、xterm向けのiso10646 fontにグリフが未実装な文字が使われてる)
実は、LV8より単純にバッテリー容量が小さい
出っ張りの無いフラットデザインなため、単純に体積が減っているためと思われる (光学ドライブを下ろして空いたスペースにバッテリを配置し、キーボード下に配したメインボードを後方排気クーラーと直結するレイアウトなので、他に合理的な配置が無い＆前方配置なのでバッテリー部を厚くする余地が無い)
バッテリーパック(L)の仕様は以下の通り
| バッテリ | 定格電圧 | 定格容量 | 重量 |
| LV8用(L) | 10.80V | 6300mAh(68.0Ah) | 355g |
| FV5用(L) | 11.55V | 4786mAh(55.3Wh) | 300g |
バッテリ重量からみるとかなり健闘しているし、フットプリントが小さいSR/QR系よりマシなのだが…
バッテリパック(L)装着時のカタログ上の駆動時間は以下の通り
| モデル | JEITA2.0 | JEITA3.0(動画) | JEITA3.0(アイドル) |
| LV8 | 18.5h | n/a | n/a |
| FV5 | 20.0h | 9.0h | 18.1h |
で、FreeBSD等で稼働状態でacpiconf -i0の推定稼働時間を測定してみると、LV8 5～6時間に対してFV5 4～5時間になる
acpiconfが報告するアイドリング時の消費電力は、LV8 8～9Wに対してFV5 9～14Wなので、 バッテリ容量の減少も相まって実稼働時間はかなり不利な模様
もちろん、稼働コア数(4C/8T vs 6P+8E+2LE/22T)を考慮すれば、大変効率的になっているのだが…
カタログ稼働時間は、電力消費をギリギリまで絞り込んだ値なんだけど、JEITA3.0もかなり現実から遠い気がする
現状、acpi_videoでバックライト制御が出来てない分は分かるが、CPUパワーとかどうやってそこまで絞ってるんだか Orz
以前報じたdevel/glib20をアップグレードするとlibreofficeが起動しなくなる件だが、 glib-2.80.3,2で修正されたことを確認
どうやら、libreofficeのBugzillaに報告されている通り、 glib-2.80.1のエラッタでglib-2.80.3で修正された模様
でも、Ctrl-qでlibreofficeが終了出来ずに、クラッシュからの回復画面に戻ってしまうバグがぁぁぁ Orz
接続経路を変えたら問題なくTx/Rx共に110MB/sec出たので、ハードウェア的な相性がある模様...
| Let'snote | 経路(A) | 経路(B) | 経路(C) |
| CF-FV5U | Tx 111MB/s / Rx 111MB/s | Tx 110MB/s / Rx 60MB/s | Tx 110MB/s / Rx 62MB/s |
| CF-LV8W | Tx 110MB/s / Rx 110MB/s | Tx 110MB/s / Rx 68MB/s | - |
どうやら、10GBASE-T SFP+ plugin moduleとの接続相性もしくは間に入っている長めの継ぎ足しパッチケーブル(爪折れ対策にノート側で短いケーブルを継ぎ足している)が原因の模様
10GBASE-T SFP+ plugin moduleを別のモジュールに差し替えた直後は、Tx/Rx共に110MB/sが出たのでモジュールの発熱が原因か？
数日前にglib-2.80.3へのアップデートでlibreoffice起動問題が修正されたが、終了時にトラブル件だが、 libreoffice側の起動不良が繰り替えされた環境で生じる問題かも知れない…
FV5セットアップの過程で判明した、現時点のOut of BoxなFreeBSD 14.1-STABLEでサポート不足なもの纏め
各種パッチを当てた状態での実用上の問題は、以下の通り
手持ちのモバイルディスプレイ(2560x1440)とLet'snote FV5との接続試してみた (kmsサポートがまだなので、Windows11にて試験)
ちなみに、USB-C - USB-Cケーブルは、USB3 10Gbps(DP Alt Mode)とUSB4 40Gbpsの二種をためしたが、どちらもパネルを認識するが写らない
問題のモバイルディスプレイはLet'snote LV8ではType-C DP Alt Mode接続で問題なく動いた機材なのだが、 購入時期的にUSB3.x DP Alt Mode時代のものなのでUSB4 DP Alt Modeと非互換性がある？
| インターフェース | DP Alt Mode HDMIアダプタ | USB3.2 Gen1 10Gbpsケーブル | USB4 40Gbpsケーブル |
| CF-FV5U(USB4/Thunderbolt 4) | ○ | ×(*1) | ×(*1) |
| CF-LV8W(USB3.1/Thunderbolt 3) | ○ | ○ | ○ |
acpi_call(ports/sysutils/acpi_call)を使って調べたが、 _SB_.PC00.GFX0.DD1F._BCMで内蔵液晶の輝度が変わる
設定値が0～13と14～100でacpiconf -i0が報告する電力と輝度が2値化する
低い方の設定だと、電力が1Wぐらい低下するがすごく暗くなる
1と13だと13の方が少し見やすいので明るくなってる？
13と14が違い過ぎるので滑らかな輝度制御は別の手段が必要な模様
# acpi_call -v -p '\_SB_.PC00.GFX0.DD1F._BCM' -i 13
kterm + ibus-anthyで、なぜか全角～がXIM経由で入力出来ないので要調査
確認した振る舞い
推論メモ
別解
~(U+007E)の全角対応の不一致問題
調査結果
kterm + ibus-anthyで、なぜか全角＼がXIM経由で入力出来ない
確認した振る舞い
前のWAVE DASHの件と異なり、U+FF3CはEUC側にもCode Pointが定義されているはずなのだが…
ktermにデバック用のパッチを当てた状態での観測
従って、XIM層かibus側で欠損が発生している模様
確認済みの事実
作業仮説
今後調べる場所
調べた
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記