トップ «前の日記(2024-06-06) 最新 次の日記(2024-06-10)» 編集

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|

2024-06-07 [長年日記]

_ [FreeBSD]FreeBSD on Let'snote FV5

LV8との違いで見つけた件

  • acpi_video.koをロードしても、hw.acpi.video.lcd0生えてこない
    • hw.acpi.video.lcd0.brightnessを使った液晶輝度制御が出来ない
    • acpi_panasonic.koのhw.acpi.panasonic.lcd_brightnessは生えてるし、Fn+F1/F2で変化するが、液晶輝度が変化しない Orz
    • CF-LV8だと、hw.acpi.video.lcd0.brightnessが生えていて、実際に液晶輝度が変えられる
      • でも、FreeBSD 12入れた当時と異なり、液晶輝度が細かく変わらないように見える
        • インストーラレベルでテスト出来るはずなので、古いインストーライメージを引っ張ってきて確認すべきか？

stable/14ベースでの調査結果

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))
  • CF-LV8 (うまくhw.apci.video.lcd0が生えるケース)
    • \\134_SB_.PCI0.GFX0.DD1Fの_ADRが _DODリスト(Enumerate All Devices Attached to the Display Adapter)に照合し、_BCLメソッド(Query list of brightness control levels supported)が実装されている
    • stable/14だとうまく輝度調整が動かないのはなぜだろう(stable/12で導入した直後は確かに輝度が段階的に変わるのを確認したのだが…)
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]
  • CF-FV5 (hw.acpi.video.lcd0が生えないケース)
    • \\134_SB_.PC00.GFX0.DD1F及びDD2Fに_BCLが実装されているが、_ADRが共に0x001fで、_DODリストに照合しない
    • _DODリストが2エントリ共に0x10000を指している
    • 内蔵LCDパネルなら、当該デバイスの_ADRや_DODの登録は0x04##になるはずなのだが…
    • ACPICAの規格書を斜め読みした範囲では、Firmware側に正しい情報が登録されていないように見える Orz
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]

_ [FreeBSD]buildworld+buildkernel ベンチマーク対決

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倍弱と喧伝されていたはず)

_ [雑記]Filesystem coding変換

EUC-JPからUTF-8へ変換実施

UTF-8モードで稼働するFDcloneでは、波ダッシュ(U+301C)だと表示がバグる

xterm/kterm(utf-8モード)上のlsだと問題無いので、内部処理で何か変換してる？

  • FDClone内部で、EUC-JP or ShiftJISへ変換して処理しているため、外部コード(UTF-8)→内部コード→外部コードのラウンドトリップで処理化けしている
  • EUC-JP的には、波ダッシュ(U+301C)・全角チルダ(U+FF5E)が縮退している
    • 参考 https://www.tohoho-web.com/ex/dash-tilde.html
    • nkfのEUC-JP→UTF-8変換は、波ダッシュ(U+301C)を選ぶ
    • subversionに、EUC-JPでcommitしたものをUTF-8でcheckoutすると波ダッシュ(U+301C)を選ぶ
    • Anthy/Emacsも、ダッシュ記号の全角モードは、波ダッシュ(U+301C)
    • FDCloneは、全角チルダ(U+FF5E)を期待している

解決法は、

  1. パス中の波ダッシュ(U+301C)を全角チルダ(U+FF5E)へ置き換える
  2. FDCloneの変換テーブル(mkunitbl.c)を修正する

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},
[ツッコミを入れる]

カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記

Generated by tDiary version 5.2.4
Powered by Ruby version 3.2.5-p208