刹那(せつな)の瞬き

Willkömmen! Ich heiße Setsuna. Haben Sie etwas Zeit für mich?

B450 AORUS PRO WIFIのBIOS更新後、lm_sensorsの出力結果に変化あり

先日、GIGABYTEB450 AORUS PRO WIFI BIOS を F64e まで更新しました。

更新直後は何も問題ないと思ってたのですが、Linux 環境で lm_sensors を動作させると、期待したものとは異なる結果になりました。

幸い、すぐに対策が見つかったので、今は問題ありません。

※過去記事にもその対策を追記しておきました。

私の環境では、KDE neon 5.27.9, Ubuntu 22.04.3 LTS, openSUSE Tumbleweed で確認しているので、当面は問題ないと判断しました。

....

この件について掘り下げて調査していたところ、「最新の Ubuntu の it87 ドライバなら対応しているのでは?(意訳)」との英文記事が目に付きました。
半信半疑ですが、それが真実ならドライバをビルドしなくて済むので助かります。

タイミングよく Ubuntu 23.10 がリリースされたばかりなので、そのインストールついでに調べてみました。

Ubuntu 23.10 インストール直後に lm_sensors を導入

まずは lm_sensors をインストールして実行してみます。

$ sudo apt install lm-sensors
$ sensors
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:            N/A  

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +16.8°C  (crit = +20.8°C)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +31.2°C  

BIOS が F32 の頃とは結果が異なりますが、it87 ドライバがロードされていない状態での実行結果と同じです。

念の為、環境やドライバの所在について調べてみます。

$ sudo sensors-detect --auto
# sensors-detect version 3.6.0
# System: Gigabyte Technology Co., Ltd. B450 AORUS PRO WIFI [Default string]
# Board: Gigabyte Technology Co., Ltd. B450 AORUS PRO WIFI-CF
# Kernel: 6.5.0-10-generic x86_64
# Processor: AMD Ryzen 5 2600X Six-Core Processor (23/8/2)

Running in automatic mode, default answers to all questions
are assumed.

(...ざっくり省略...)

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
it87
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO)

Unloading cpuid... OK

$ sudo modprobe -D it87
insmod /lib/modules/6.5.0-10-generic/kernel/drivers/hwmon/hwmon-vid.ko.zst 
insmod /lib/modules/6.5.0-10-generic/kernel/drivers/hwmon/it87.ko.zst 

既定の it87 ドライバが提供されているので、ロードして確認します。

$ sudo modprobe it87
$ sensors
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:            N/A  

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +16.8°C  (crit = +20.8°C)

it8792-isa-0a60
Adapter: ISA adapter
in0:         916.00 mV (min =  +0.00 V, max =  +2.78 V)
in1:           1.08 V  (min =  +0.00 V, max =  +2.78 V)
in2:           1.10 V  (min =  +0.00 V, max =  +2.78 V)
+3.3V:         3.36 V  (min =  +0.00 V, max =  +5.56 V)
in4:           1.26 V  (min =  +0.00 V, max =  +2.78 V)
in5:           1.15 V  (min =  +0.00 V, max =  +2.78 V)
in6:           2.78 V  (min =  +0.00 V, max =  +2.78 V)  ALARM
3VSB:          3.33 V  (min =  +0.00 V, max =  +5.56 V)
Vbat:          3.25 V  
fan1:           0 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
temp1:        +29.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +34.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:        +35.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
intrusion0:  ALARM

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +34.4°C  

表示される内容が増えましたが、求めている内容ではありません。
IT8686 の情報が欠落し、肝心の CPU コア 6 個分の温度が表示されません。

残念ですが今までと同様に、別途 it87 ドライバを用意する必要があるみたいです。

必要なドライバのソースを取得してビルドする

過去記事と同様にソースを取得して it87 ドライバを構築してみます。

まずはビルド環境を用意します。

$ sudo apt install build-essential dkms

また、ドライバのソースを取得するのに git が必要です。

$ sudo apt install git

適当なフォルダを用意してドライバのソースを取得します。

$ mkdir ~/work
$ cd ~/work
$ git clone https://github.com/a1wong/it87.git

ビルド前にロードしてあったドライバを解放しておきます。

$ sudo modprobe -r it87

準備が整ったら it87 ドライバをビルドしてみます。

$ cd it87
$ sudo make dkms
Creating symlink /var/lib/dkms/it87/v1.0-48-g40bec4b/source -> /usr/src/it87-v1.0-48-g40bec4b
Sign command: /usr/bin/kmodsign
Certificate or key are missing, generating them using update-secureboot-policy...
Secure Boot not enabled on this system.
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der

Building module:
Cleaning build area...
make -j12 KERNELRELEASE=6.5.0-10-generic TARGET=6.5.0-10-generic...
Signing module /var/lib/dkms/it87/v1.0-48-g40bec4b/build/it87.ko
Cleaning build area...

it87.ko.zst:
Running module version sanity check.
 - Original module
 - Installation
   - Installing to /lib/modules/6.5.0-10-generic/updates/dkms/
depmod...
modprobe: ERROR: could not insert 'it87': Device or resource busy
make: *** [Makefile:101: dkms] エラー 1

結果を見ると、ビルドは成功したのに modprobe でエラーが発生しています。

ドライバの確認と対策

ビルド自体は成功しているので、成果物である新しいドライバの所在を確認します。

$ sudo modprobe -D it87
insmod /lib/modules/6.5.0-10-generic/kernel/drivers/hwmon/hwmon-vid.ko.zst 
insmod /lib/modules/6.5.0-10-generic/updates/dkms/it87.ko.zst

改めてこのドライバをロードしてみます。

$ sudo modprobe it87
modprobe: ERROR: could not insert 'it87': Device or resource busy

既定のドライバでは何も表示されなかったのですが、ビルド時と同様に modprobe でエラーが発生します。

この件について、ネットの類似事例にあるように OS 起動時のパラメータやドライバロード時の ID 指定等、色々と試してみましたが解決しません。

どうやらマザーボードの製造メーカーによって対策は異なるらしく、最終的に GIGABYTE の B450 マザーボードで有効なパラメータはこちらでした。

$ sudo modprobe it87 ignore_resource_conflict=true
$

modprobe を実行して、エラーが表示されなければロード成功です。
この状態で sensors を実行すると期待通りの結果になります。

$ sensors
it8792-isa-0a60
Adapter: ISA adapter
in0:         403.00 mV (min =  +0.00 V, max =  +2.78 V)
in1:         916.00 mV (min =  +0.00 V, max =  +2.78 V)
in2:           1.05 V  (min =  +0.00 V, max =  +2.78 V)
+3.3V:         3.36 V  (min =  +0.00 V, max =  +5.56 V)
in4:           1.26 V  (min =  +0.00 V, max =  +2.78 V)
in5:           1.13 V  (min =  +0.00 V, max =  +2.78 V)
in6:           2.78 V  (min =  +0.00 V, max =  +2.78 V)  ALARM
3VSB:          3.33 V  (min =  +0.00 V, max =  +5.56 V)
Vbat:          3.25 V  
fan1:           0 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
temp1:        +29.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +34.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:        +35.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
intrusion0:  ALARM

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:            N/A  

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +16.8°C  (crit = +20.8°C)

it8686-isa-0a40
Adapter: ISA adapter
in0:           1.39 V  (min =  +0.00 V, max =  +3.06 V)
in1:           2.02 V  (min =  +0.00 V, max =  +3.06 V)
in2:           2.00 V  (min =  +0.00 V, max =  +3.06 V)
in3:           2.02 V  (min =  +0.00 V, max =  +3.06 V)
in4:         924.00 mV (min =  +0.00 V, max =  +3.06 V)
in5:         900.00 mV (min =  +0.00 V, max =  +3.06 V)
in6:           1.21 V  (min =  +0.00 V, max =  +3.06 V)
3VSB:          3.26 V  (min =  +0.00 V, max =  +6.12 V)
Vbat:          3.14 V  
fan1:         394 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
fan4:           0 RPM  (min =    0 RPM)
fan5:           0 RPM  (min =    0 RPM)
temp1:        +32.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +37.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:        +34.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = AMD AMDSI
temp4:        +35.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp5:        +40.0°C  (low  =  +0.0°C, high = -120.0°C)  sensor = thermistor
temp6:        +46.0°C  (low  =  +0.0°C, high = -120.0°C)  sensor = thermistor
intrusion0:  ALARM

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +34.2°C  

後は OS 起動時にこの状態になるように設定します。

ドライバの追加とドライバオプションの設定

次の 2 つのファイルにそれぞれ追記します。
※存在しなければ、ファイルを作成します。

(1) /etc/modules

/etc/modulesに以下の内容を追記

# Chip drivers
it87
(2) /etc/modprobe.d/it87.conf

/etc/modprobe.d/it87.confに以下の内容を追記

options it87 ignore_resource_conflict=1

 modprobe コマンド実行時とは異なり true ではなく 1 をセットします。

この記述があれば modprobe コマンド実行時、オプション指定しなくてもパラメータが反映されます。

(3) OS 再起動

OS 再起動後、sensors を実行して期待通りの結果になれば作業完了です。

Flatpak版PPSSPPの動作が芳しくないのでロールバックしてみた

久々に Flatpak 版 PPSSPP を起動したところ、私の環境では動作が芳しくありません。

現在 flathub に登録されている PPSSPP の最新版は v1.16.6 ですが、

  • UI の日本語フォントが文字化けして読めない。 ※いわゆる tofu 状態
  • BGM にノイズが乗る。
  • BGM の一部が遅延する。

のような不具合が発生しています。

UI に関しては、とりあえず PPSSPP のユーザ環境にある SYSTEM/ppsspp.ini をエディタで開いて、Language=en_US に書き換えて対処したのですが、Play に支障がある BGM 関連の不具合は解決できませんでした。

....

最後に PPSSPP を起動したのは今年の初めだったと思います。
その頃は問題なかったはずなので、敢えて古いバージョンに置き換えてみました。

※Flatpak の公式サイトで紹介されている手順 →こちら

ログの確認

まずは flathub に登録されている PPSSPP のコミットログを確認します。

$ flatpak remote-info --log flathub org.ppsspp.PPSSPP
        ID: org.ppsspp.PPSSPP
       Ref: app/org.ppsspp.PPSSPP/x86_64/stable
      Arch: x86_64
    Branch: stable
Collection: org.flathub.Stable
  Download: 18.7 MB
 Installed: 38.5 MB
   Runtime: org.freedesktop.Platform/x86_64/23.08
       Sdk: org.freedesktop.Sdk/x86_64/23.08

    Commit: afb2dff758946b753bf72115b0e1f4cff3fdf5f2870b4885518ae5dd0c6743de
    Parent: 5ae906ce2c24771afedd7d5f9ad0385c10a7aa78ef6a816c3bbe744b07d1d8ea
   Subject: Update ppsspp.git to 1.16.6 (4979c41a)
      Date: 2023-10-14 10:57:34 +0000
   History:

    Commit: 5ae906ce2c24771afedd7d5f9ad0385c10a7aa78ef6a816c3bbe744b07d1d8ea
   Subject: Update ppsspp.git to 1.16.5 (8c56d859)
      Date: 2023-09-28 17:32:43 +0000

(...ざっくり省略...)

    Commit: 8e0dfcf012c0f06f38e0bc74c01b75c0d7a26309b81621d3813fbe31dfbe0a0f
   Subject: Update ppsspp.git to 1.15.2 (1813576f)
      Date: 2023-05-05 13:24:21 +0000

(...ざっくり省略...)

    Commit: 56e27068f5d45875e8638d8f2734220f1e2ffd5b6eff9ddcbf541e3b21c4ce40
   Subject: Update ppsspp.git to 1.14.4 (e80ddde9)
      Date: 2023-01-03 12:02:02 +0000

延々と表示されるので、途中で Ctrl+Cで中断しました。

古いバージョンへのロールバック (Commit id を指定した update)

古いバージョンに戻すにはflatpak updateコマンドを実行します。
※ update なので、flatpak install flathub org.ppsspp.PPSSPPが実行済みである事が前提です。

先程のログで、戻したいバージョンの Commit: 欄にある id 値を確認します。
そして、flatpak updateコマンドに対し、その値を--commitオプションで指定します。

$ sudo flatpak update \
--commit=56e27068f5d45875e8638d8f2734220f1e2ffd5b6eff9ddcbf541e3b21c4ce40 \
org.ppsspp.PPSSPP

上記の例では、v1.14.4 がコミットされた時点に戻りました。

...

実はバージョンを一つ一つ戻して試してみたのですが、私の環境で問題なく動作する直近のバージョンは v1.14.4 でした。

Flatpak の自動更新から除外

古いバージョンに戻したのは良いのですが、何も対策をしないと OS 起動時の Flatpak の自動更新でまた最新版に戻ってしまいます。

それを防ぐには、flatpak update の対象から PPSSPP を除外(マスク)します。

$ flatpak mask org.ppsspp.PPSSPP

これで flatpak update を実行しても処理されません。

もし別バージョンを試したり、再び最新版にする場合はマスクを解除します。

$ flatpak mask --remove org.ppsspp.PPSSPP

当面、環境を変える予定はないので、しばらく v1.14.4 で過ごすつもりです。

SQLServerのBuild-an-appのWebページが無くなってた

SQL Server 2017 の頃に見つけた、お気に入りの開発者向けサイトがありました。

Microsoft のサイトなのですが、SQL Server の公式ドキュメント群とは別のものです。

C#, Java, Node.js, PHP, Python, Ruby, Go の各言語で

  1. データベース接続までに必要な準備とそのコード
  2. CRUD な事例
  3. 何かの事例

のコードを記述し、それを Windows, macOS, Ubuntu, ... の各 OSで開発する方法を説明していました。

そのページには各言語のアイコンが用意され、OS を選択するとそれに合わせて記事の内容が変化するので、同じ言語でも OS の差異を確認したり、異なる言語での記述の違いを比較するのに適度なサイトでした。

C#, Java, PHP は既に非 Windows 環境から SQL Server に接続していたので再確認。Node.js, Go は初学者として手を動かしてみたのは良い思い出です。

....

元々は Linux で Rust から SQL Server を扱う方法を調査中に見つけたものです。
言語のラインナップに Go があるのに Rust がない事に憮然としました。

それでも Microsoft は Rust に力を入れると公式発表してるし、基本的な C/C++ もないので、それらはそのうちラインナップに追加されるものだと思ってました。

それから随分経ちますが、一向にサイトが更新される気配はありません。
SQL Server は 2017 のままだし、各言語のバージョンの古さも目立ちます。
※ サイトが確認できないのでうろ覚えですが Node.js は v6 くらいだったかと。

最低月に一度はアクセスして更新を期待してたのですが、先日ついに、

We are sorry, the page you requested cannot be found.

The URL may be misspelled or the page you're looking for is no longer available.

となり、ページそのものが無くなってしまいました。残念無念です。

....

Microsoft の Web サイトは割と頻繁に見直しが入るため、油断していると古い情報はあっさり無くなるのは何度も経験してます。
有用なページを失う度、地味にダメージを受けてます。

どこかに代替ページがないか探したのですが、見つけられませんでした。

とりあえず Go 言語以外の説明ページは以前のまま残ってます。

一応、Go 言語の情報は Azure SQL のドキュメントに存在します。

Build-an-app の内容とは異なりますが、参考になると思います。

....

私は Build-an-app に触発されて、新しい開発言語を学ぶ際は、SQL Server との接続も試すようになりました。

自分なりの CRUD と接続プールの事例を用意して、これらを macOSLinux で動作確認してます。
Build-an-app に存在しなかった言語では、Rust, Zig, Nim 辺りは動作確認できてます。

同じ事例のサンプルを増やしていくと、目的がはっきりしているせいか、理解が早くなるような気がするのですが、私だけでしょうか。

とにかく、復活、または、同様のページが用意される事を願うばかりです。

 

追記 2023-11-03

件のサイトですが、本日 (2023-11-03) 確認したところ、リンク切れが修正され、

として、新たなページに生まれ変わってました。

....

"Developing with SQL Server" セクションに Build-an-app と同様、.NET/C#, Java, Node.js, Python, Go, PHP の コンテンツがあります。

ただし、Build-an-app と同じ内容ではありません。

  • コンテンツのリンク先が Github の AzureSQLDB
  • OS を切り替えて見比べる手段は無し
  • 環境構築(dotnet, OpenJDK 等のインストール方法)の記述は無し

思ってたものとは少し方向性が異なりますが、各言語のコードは以前より新しいバージョンに寄せてあるみたいなので、復活というか再誕は大歓迎です。

B450 AORUS PRO WIFIのBIOS更新でのアレコレ

GIGABYTEB450 AORUS PRO WIFI を購入して 5 年が経過します。

少々思うところがあり、BIOS を F64e (2023-09-21) まで更新しました。

更新後、私の環境では特に問題は発生してません。
BIOS 画面の機能が改善され、CPU の脆弱性対策もできて作業結果には満足してます。

ただ、その過程で色々あったので、以下にその顛末を残しておきます。

BIOS 更新作業前の PC 環境

購入当初はメモリ関連で些細な不備があり、BIOS を F32 まで更新しました。

  • CPU は Ryzen 5 2600X (Zen+)
  • BIOS: F40 以降は第3世代 Ryzen 対応と解釈し、F32 で止める
  • 当時の OS は Windows 10
  • 将来 F40 への準備として EC FW Update Tool (B19.0606.1) は適用済み

F32 までの更新で私が気になる不備は解消され、致命的な障害報告もありません。
なので、新しい BIOS が提供されても私には必要ないと考えてました。

B450 だけど、もうしばらく戦えそう

昨年発売された Zen 4 アーキテクチャからパッケージが AM5 になりました。
一気に Socket AM5 への移行が進むのかと思いきや、現状はそうでもないようです。

私も価格次第ですが、今のところは現状維持で良いと思ってます。

私が所有してるASUS Vivobook Pro 14 OLED M3401QA (Ryzen 9 5900HX) にベンチマークで劣る Ryzen 5 2600X ですが、実際の用途では特に不満はありません。

どちらかと言えば性能より OS 起動用 SSD/HDD を複数接続できる方が望ましいです。
なので M.2 の使用は控えてます。1 OS なら M.2 NVMe は速くて良いんですけどね。

M/B の B450 はチップセット単体で PCIe 2.0 / SATA x 4 ポートです。
メンテ用の Windows で 1 ポート、その他 OS で 3 ポート 利用できます。
そして ASATA x 2 ポートのおまけ付き。費用対効果を鑑みると私的には好物件でした。

仮に M/B が故障した場合、後継の B550 だと Zen+ な Ryzen 5 2600X は非対応です。
X570, B450 等の対応 M/B を探すか、CPU を諦めて別の構成にするしかありません。

一方で B450 は BIOS 次第で Ryzen 5000 シリーズまで対応するようです。

当面、CPU を換装してまで性能強化する予定はないのですが、もし不足を感じたら、Ryzen 5 5600X (PCIe 4.0) か 5600G (PCIe 3.0) に換装するのも良さそうです。
Ryzen 5 2600X は PCIe 3.0 / 最大レーン数 24 (16x GPU / 4x General / 4x Chipset Link)

そんな感じで、新しい BIOS に興味が湧きました。

BIOS の更新履歴に CPU 関連の脆弱性で気になる記述あり

幸いなことにB450 AORUS PRO WIFI BIOS の提供は現在も継続してます。

公式サイトの BIOS 情報を確認したところ、見過ごせない記述がありました。

• Major vulnerabilities updates, customers are strongly encouraged to update to this release at the earliest.

これはバージョン F62 の詳細欄に書かれている情報ですが、「主要な脆弱性の更新」とか「更新を強くお勧めする」とか、およそ BIOS 更新らしくない表現が使われてます。

脆弱性について、軽く調べたのですが Zen+ 関連は見つけられませんでした。
古い世代の情報なので見つけ難かっただけかもしれません。

対象外としても、何らかの脆弱性対策が施されているなら、最新の BIOS に更新するべきでしょう。しかし、その結果 2600X の使用に支障を来たすのは困ります。

幸い CPU の脆弱性を調べる過程で、たまたま同じ M/B ユーザの情報を見つけました。
その方は F32 以降の新しい BIOS で 2600X を使用中との事。

それならばと、私も BIOS 更新を決意しました。

Windows 11 22H2 から BIOS 更新できずにモヤモヤ

現在、私の Windows 11 22H2 (Build: 22621.2428) 環境では @BIOS が動作しません。

@BIOS を実行すると DLL をロードできず、起動に失敗します。
コア分離のメモリ整合性を「オフ」にしても同様です。

ダメ元で EC FW Update Tool (Win10 用)も試しましたが、こちらも同様に失敗します。Windows 11 用が提供されていないので、Windows 10 なら問題ないかもしれません。

何れにしても今更 Windows 10 環境を用意するのは面倒です。
ここは素直に Q-Flash 経由で BIOS を更新するべきでしょう。

BIOS 更新は Q-Flash で問題なし (F32 -> F40 -> F50 -> F62 -> F64e)

Q-Flash での更新作業は、ダウンロードした BIOS ファイルを FAT32 形式でフォーマットされた USB メモリにコピーして、BIOS 画面の Q-Flash メニューから指定するだけです。

公式サイトの BIOS 情報に従い、段階的に更新していきます。

(1) F32 -> F40

作業開始時点での BIOS は F32 なので、まずは F40 に更新しました。

その際、事前に EC FW Update Tool (Win10用) を実行しておくべきなのですが、前述したように、今の私の環境 (Windows 11 22H2) では実行しても処理に失敗します。

Windows 10 の時点で EC FW Update Tool を実行しておいて、本当に良かったです。

(2) F40 -> F50

この手順は不要かもしれません。
私は公式サイトの注意書きが気になったので、一旦 F50 に更新しました。

更新後 PC を再起動したところ F50 の BIOS 画面からメニューに変化がありました。
特に起動デバイスの設定項目が増えたのが嬉しいところです。

(3) F50 -> F62

この手順も不要かもしれません。
F50 の Q-Flash から Dual BIOS の更新方法が選択可能でしたが既定のままです。

F62 は前述した脆弱性の対策済みバージョンなのと、fTPM の既定値が Enabled に変更されたので、その確認のために更新しました。

(4) F62 -> 最新バージョンの BIOS  ( 現在は F64e )

最新の BIOS に更新したいところなのですが、F62 更新以降の BIOS は公開されているバージョンに変動がありました。

少し前まで F64a が公開されていたのですが、より新しい F64e に置き換わってます。

現在確認できる最新バージョンなので、 F64e に更新しました。

現在の構成

BIOS を更新したので、改めて現在の構成を確認します。

主なハードウェア
CPU AMD Ryzen 5 2600X (Zen+)
M/B GIGABYTE B450 AORUS PRO WIFI (BIOS: F64e / AMD AGESA V2 1.2.0.B)
GPU NVIDIA GeForce GTX 1050 Ti
Mem G.Skill F4-3600C19D-16GSXWB ( 2 枚組 )
Dual Channel (A: DDR4_2,  B: DDR4_1) に装着
主な BIOS 設定 (F64e)
SVM AMD SVM Mode は Enabled
「M.I.T」メニューの「Advanced Frequency Settings」から「Advanced CPU Core Settings」に進み「SVM Mode」を Enabled に設定。
Mem

「M.I.T」メニューの「Advanced Frequency Settings」で確認すると、既定は 3600MHz だが自動認識だと 2133MHz で動作。

「M.I.T」メニューの「Advanced Memory Settings」から 「Extreame Memory Profile(X.M.P.) 」を Disabled に設定。
続いて「System Memory Multiplier」を「29.33」に設定。

※ 2933MHz では 15-15-15-15-36 で動作中

UEFI CSM UEFI CSM Support は Enabled
BIOS」メニューの「CSM Support」を Disabled に設定していたが、既定値(Enabled) に戻した。
TPM TPM 2.0
「Peripherals」メニューの「AMD CPU fTPM」は 既定値 (Enabled) のまま。
「Trusted Computing 2.0」の各設定は既定値のまま。

現在、B450 の SATASSD/HDD を 4 台接続して、4 つの OS を使い分けてますが、Windows 11 22H2, その他 OS は問題なく動作してます。

ちなみに BIOS F64e の AMD AGESA 1.2.0.B は Inception 攻撃対策済みらしいです。
影響を受ける Ryzen 5000 シリーズに換装しても良さそうな感じです。

CPU を換装する際はメモリを 2 枚刺しで試して、正常に認識・起動すれば、 EC FW Tool が正しく適用されていると考えて良いのかな。

また、密かに期待してたメモリのオーバークロック動作は少し改善してました。

2600X の定格動作では DDR4-2933 (1Rank / 2DIMM) が最速です。
以前はメモリ本来の 3600MHz まで上げて再起動するとリブートを繰り返し BIOS 画面まで到達しませんでしたが、今回は不安定ですが何度か起動まで漕ぎ着けてます。

ロマンは感じますが無謀が過ぎるので、現在は 2933MHz で常用してます。

macOS Ventura 13.4に移行。周辺機器は少々調整が必要かも

先日、M1 Mac minimacOS Ventura 13.4 にアップグレードしました。

結果は良好で、最終的には周辺機器を含めて問題なく利用できてます。

最も懸念してた Thunderbolt / USB-C 変換ケーブル経由、Thunderbolt2 拡張ドック CalDigit Thunderbolt Station 2 の DisplayPort 1.2 モニタ出力 (3840x2160@60Hz) は正常動作してます。

スリープ移行・復帰、USB機器の認識も一応問題ありません。

以下は、その顛末です。

macOS Ventura の不具合の噂が怖すぎ

macOS Ventura がリリースされた直後から、Thunderbolt / USB-C Dock や変換器経由で外部ディスプレイ接続の問題が報告されてます。
※この件は、最新版の macOS Ventura 13.4 でも解消しない環境があるようです。

後は、スリープしない / スリープから復帰しない問題や、USB 機器の認識が解除される場合がある等々、相変わらずハードウェアの不具合報告はよく目にします。

macOS Monterey にダウングレードして解決したという報告もありますが、それは「解決した」とは言えないような気が…

Thunderbolt2 変換アダプタと Thunderbolt2 Dock は大丈夫か

不具合の噂が本当だとすると、私の環境は最悪です。

macOS Monterey で快適なのに、この環境を壊すリスクを負うのは辛いです。

それでも macOS Ventura に移行する理由

Docker Desktop for Mac v4.16 から Beta features として

が利用できるようになってます。

この機能は macOS Ventura の Virtualization framework と Rosetta2 が前提なので、macOS Monterey のままでは利用できません。

諸事情により、どうしてもこの機能が必要になり、環境を壊してでも macOS をアップグレードする事にしました。

macOS Ventura へのアップグレードは突然に

環境を壊すと言っても、Mac mini 本体のポート類で網羅できる範囲内です。

細かい事は後回しにして、とりあえず OS イメージのダウンロードだけしておこうと「ソフトウェアアップデート」から macOS Ventura をクリックしたところ、突然インストールが始まりました。

え!ちょっと待って!
ダウンロードしたかっただけなんだけど!

いつもと同様にダウンロードだけしてインストールをキャンセルつもりだったのに、いきなり「黒画面に林檎のマークと進捗ゲージ」が表示され、もう後戻りはできません。

OS アップグレードの際は、余計な周辺機器を外してからが鉄則です。
せめてモニタを DisplayPort から HDMI 接続に変更したかったのに、手遅れです。

後はただ見守るだけです。

でも無事に起動したぞ

インストール中は何も手出しできないので、ひたすら待ちます。
途中、モニタがブラックアウトしてる時間が長い場面があり、心配ですが待ちます。

そして、幾度かの再起動の後、ついに macOS Ventura が起動しました。

古い周辺機器はそのままだったのに、無事に起動してくれて嬉しかったです。

いつもの調整

Launchpad を開くと、標準アプリケーションがいくつか増えてます。

私はアップグレード直後くらいは初期値にしたい派です。

$ defaults write com.apple.dock ResetLaunchPad -bool true
$ killall Dock

今回もこのコマンドで初期状態に戻せました。

後は諸々のアプリケーションをアップデートして調整は完了です。

ハードウェアも一応問題なし

macOS Monterey と同様、私の環境では大きな問題は発生してません。

ただ、ログイン直後、Marble Mouse はポインティングデバイスとして動作はするものの Logi Options によるポインタスピードが反映されませんでした。

実際、Logi Options を開くと Marble Mouse を認識しなくて、USBケーブルの抜き差しで再認識させると期待通りに動作します。

毎回毎回、ログイン後に抜き差しするのは面倒なので、試しに拡張ドック側のUSBポートに接続したところ、見失う事はなくなりました。

macOS Ventura で Daemon の起動タイミングが変わってしまったのでしょうか。

最後に

macOS Ventura で変更された UI にもそこそこ慣れました。

Docker のためにアップグレードしましたが、後悔はしてません。
現在 Docker Desktop for Mac v4.20.1 で目的の機能を確認できました。

また、スリープモードについては経過観察中です。

実は macOS Monterey の頃、スリープしたのに突然復帰→時間経過してスリープ移行、という現象が稀に発生していました。

今のところ macOS Ventura では発生してません。

....

おまけ: 今後の事もあるので、公式サポートのリンクを貼っておきます。

support.apple.com

macOS Sonoma のリリースでは心配事がないと良いんだけどな。

今更ながら3DSポケモンピクロスでエンディング到達

昨年 2/16 、ニンテンドー3DSの「ニンテンドーeショップ」サービス終了のアナウンスがありました。

ダウンロード版のソフトや追加コンテンツは今年 3/28 までダウンロードできるとの事だったので、手持ちの MHX, MHXXダウンロードコンテンツを確認して放置してました。

ポケモンピクロスを見つけた

そして、ちょうど一年くらい前の事。
気まぐれに3DSを起動してみたら、ふとサービス終了の件が頭をよぎりました。

せっかくニンテンドーeショップからダウンロードできる無料ソフトがいくつかあるのにまったく利用しないのは勿体無い。

そこで、隙間時間で遊べるソフトを探したところ「ポケモンピクロス」を発見!
ゆっくりのんびり進められそうなのも私に刺さります。

最後のダウンロード版ソフトは「ポケモンピクロス」に決定!
という事で、サービス終了前にダウンロードしておきました。
※現在はサービス終了しているため、ダウンロードできません。

ゲームを進めるにあたり

とにかく隙間時間で遊ぶのが目的です。

エリア解放は効率度外視。
深い意味はないけど番号順に解放し、まずはエンディング到達を目指します。

チュートリアルは数日かけて、ゆっくりと進めました。
もちろんピクロス・ミクロスは自力で解いてます。

また、ゲームの進行上、どうしてもネットに公開されている情報が必要になります。
不本意ですが、そこだけは攻略サイトに頼りました。

ピクロイト集めは大変

エリア解放してゲームを進めるにはピクロイトが必要です。

ピクロイトは有限で、消費すれば数が減ります。
再びピクロイトを貯めるには、購入する以外だと

  • ミッションクリアのご褒美 (1 〜 3個)
  • メダル取得 (3個)
  • デイリートレーニングのご褒美 (4 〜 15個)

があります。

これに対し、エリア解放に要求されるピクロイトは数十個〜250個とかなり多く、エリアを進むにつれて多くなります。

エリア 1 〜 11 くらいの話

ピクロスを解くのは楽しいです。

しかし、数ヶ月もするとピクロイト不足による中弛み期に陥ります。

序盤は簡単なステージばかりです。

同じお題を解き続けるとして、スキル縛り、スキルなし、タイムアタック等、飽きない工夫をしても、どうしても飽きます。
ミッションをクリアするためのポケモンやスキル不足もモヤモヤします。

隙間時間で遊んでるので、そんなに深刻ではないのですが、苦痛といえば苦痛です。

しばらくはメダル取得で気がまぎれるのですが、達成条件が簡単なものは少数です。
結局、デイリートレーニングしかする事がなくなります。

それでもエリアが進むにつれ、ステージの難易度も徐々に上がります。
そのおかげで、繰り返し解くのも段々と苦痛ではなくなってきます。

エリア 12 〜 20 くらいの話

中盤に差し掛かった半年後、デイリートレーニングは確実に追加報酬を見込めるようになりました。

調子がよけれは1分以内にクリアする事もあります。

この頃は、7〜10日くらいでエリア解放に必要なピクロイトが貯まるので、序盤のような苦痛はほとんど感じません。

全部ではないですが、取りこぼしてたミッションをクリアできるのも好感触です。

20x15, 15x15 なステージを繰り返し解いてたら、いつの間にかエリアが進んでた。
すんなりあっさりスムーズに。そんな感じです。

エリア 21 〜 30 くらいの話

終盤に入ると、デイリートレーニングで入手するピクロイトが13〜15個なのに対し、終盤のどのエリアも解放には200個以上のピクロイトが必要です。

エリアを一つ解放するのに10日以上かかってしまうのは確実で、飽きない努力もより必要です。

この頃になると、スキルを使えばステージ初回クリアはほぼ確実で、ミッションも可能な限りこなします。

私の場合、ステージクリア後は基本的にポケモンなしで再チャレンジしてます。

なので、後でタイムアタックも楽しむため、クリア時間がミッションの2/3くらいからギリギリになるように最後のひと塗りのタイミングを調整してました。

エンディング到達

隙間時間で遊んでましたが、昨日約一年かけてエンディングに到達しました。
ようやく一区切りです。

私はお絵描きロジック系が好きなのですが、ついついやり過ぎてしまいます。
やる気スイッチが入ると、あまりに時間を溶かしてしまうので、視界に入れない様にしてたくらいです。

しかし、ポケモンピクロスではこの心配はありません。

ピクロイトだけでなく、Pゲージによる塗り数の制限もあるので、プレイ時間が抑えられて好都合です。

まだまだやる事はある

エンディングに到達しましたが、ゲームは半分も終わってません。

次の目標はノーマルモードのクリアです。
まずはメガペンシル取得のため、ピクロイトを500個貯めなきゃです。

メガポケモンゲット、アナザーモード解放、拡張コンプリート等、メダルコンプリートまでにやる事は多いです。

少なくともあと一年くらいは余裕で遊べそうです。

ずっと困ってたQODBCの問題がQt6.5.0で解消されたっぽい

macOS / Linux での話です。

Qt 6.3 がリリースされた頃くらいからでしょうか。
macOS / Linux 環境で動作してた Qt5 (qmake) プロジェクトを少しづつ Qt6 (cmake) に移行・確認する作業をしてます。

Qt5 と Qt6 で動作結果が異なるケースは徐々に減り、私の手持ちでは ODBC ドライバでSQL Server を扱うものだけが残りました。

Qt6 の QODBC で困ってた事

Qt5 -> Q6 では QODBC3 -> QODBC と変更するだけで済むと思ってたのですが...
細かい部分で差異があり、スムーズに移行できません。

私が遭遇した中で、特に大きな問題は 2 つです。

  1. データベースの NULL 値の扱いが Qt5 と異なる動作をする場合がある。
  2. プレースホルダを経由すると項目に余計な終端文字 (0x00, 0x00) が付加される。

これらは 0S や Qt6 / QODBC のバージョンによって発現するパターンが変わるため、なかなか現象・原因を特定できずにいました。

1 つ目は QVariant 型に入った結果セットの項目を isNull() で判別する処理の動作結果が、期待通り Qt5 と同様になる場合と、そうでない場合がありました。

2 つ目は、SQL の SELECT 文では問題ない(ように見える)のですが、INSERT, UPDATE 文を処理すると、データベース項目に終端文字が付加されてしまいます。

私は macOS で処理したデータを Linux (Qt5) で確認した際に動作の差異に気づき、Azure Data Studio で SELECT CAST(書き込んだ項目 AS VARBINARY) FROM... 等として内容を確認したところ、文字列の末尾に余計な終端文字を見つけました。

Qt 6.5.0 で再確認 -> OK!

その後、Qt6 のバージョンアップに伴い、細かい問題点も同時に解消されつつあり、Linux 環境では少し前に Qt 6.5.0 で問題ない事を確認してます。

macOS 環境は、本日の brew updateで qt, qt-unixodbc が outdated になったので、 brew upgrade を実行。qt, qt-unixodbc はそれぞれ 6.5.0 に更新されました。

早速、件のプロジェクトを試してみたところ、まったく問題ありません。
あの足掻きは何だったのかというくらい、すんなり動作しました。

これでやっと一区切りというか、ようやく Qt5 の頃に戻った感じです。

安心したいんだけど...

うろ覚えなのですが、過去のバージョンでも Linux 環境では一度はすべて解消してたような記憶もあります。
すっかり安心してたし、急ぐ案件ではないので、しばらく放置してたのですが...

間を空けて Qt6 をアップデートしたら、問題が再発してました。
諸事情により macOS に開発環境を移しても同様の結果でした。

そのうち解消されるだろうと、さらに放置してたのですが一向に改善しません。
特に最近のバージョンでもある Qt 6.4.3 で確認した際は、macOS で前述の 2 つの問題が同時に発現してたので、「もう Qt6 の ODBC は期待できないのかな...」と軽く絶望してました。

とりあえず、私の環境では macOS / Linux どちらも問題ないのは Qt 6.5.0 が最初です。

そろそろ Qt5 は忘れて Qt6 だけにしたいんだけど、もう大丈夫なのかな...
Qt Creator10.0.1になったし、そもそも Qt6 推しだし、大丈夫かな...
大丈夫だといいな。

※追記
  • 2023-05-26 Qt 6.5.1 (macOS: homebrew) 問題なし
  • 2023-10-08 Qt 6.5.2 (macOS: homebrew) 問題なし
  • 2023-11-02 Qt 6.6.0 (macOS: homebrew) 問題なし
  • 2023-11-08 Qt 6.6.0 (Ubuntu: apt) 問題なし

もう大丈夫かな。