C++ ときどき ごはん、わりとてぃーぶれいく☆

USAGI.NETWORKのなかのひとのブログ。主にC++。

Azure DevOps ちほーの git サーバーへ git@ssh しようとしたら Unable to negotiate で diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 を提案されたら思い出すメモ

Azure DevOps git ssh Unable to negotiate diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 ~/.ssh/config ssh.dev.azure.com KexAlgorithms

状況

git clone git@ssh.dev.azure.com:v3/my_team/my_project/my_repos
Cloning into 'my_repos'...
Unable to negotiate with 40.81.25.218 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

エラーメッセージ訳:

40.81.25.218:22 との交渉はダメでした。鍵交換方式が合いません。 diffie-hellman-group1-sha1, diffie-hellman-group14-sha1 とか試してみたらいいかもね。

解決方法

~/.ssh/config にそういう事を言う git サーバー用の接続設定を特殊化します。今回の例だと ssh.dev.azure.com に対して特殊化します:

Host ssh.dev.azure.com
  User git
  Port 22
  HostName ssh.dev.azure.com
  IdentityFile ~/.ssh/id_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes
  KexAlgorithms +diffie-hellman-group1-sha1

ついで設定もありますが、今回の解決方法の要は KexAlgorithms を Host/HostName に対して設定している部分です。 "Kex" は "Key-eXchanging" とかそんなノリでしょうね。😅

ちなみに、 Azure DevOps の場合は残念ながらいまだに ECDSA とか使えず RSA 鍵を使わなければならないので IdentityFile の特殊化も事実上必須です。かなしい。

Reference

WSL 環境で git commit したら gpg が failed してしまった時に思い出すメモ

GPG_TTY WSL GPG failed trouble-shoot solved Git

状況

git with GPG on zsh on Arch Linux on WSL:

> git commit -m "neko nyan ko"
error: gpg failed to sign the data
fatal: failed to write commit object

git が gpg で死んでいる。 gpg で死んでいるので gpg --list-keys をとりあえず確認するが、鍵は一見正常に扱える状態に見える。さてなんじゃろう？

> echo "hoge" | gpg --clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

hoge
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

簡単な文字列を gpg へ投げると容赦無く死んだ。

解決方法

GPG_TTY=$(tty)

これだけだと、直後はまだ:

> echo "hoge" | gpg --clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

hoge
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

さらに何かよくない深刻化した事態が脳裏をよぎる。しかし大丈夫、稼働中の gpg プロセスをすべて kill してから試すと、 tty なパスフレーズ入力を経由しつつ:

f:id:USAGI-WRP:20200220040206p:plain

期待動作してくれるようになる:

echo "hoge" | gpg --clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

hoge
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEnbin1TDZDg++OLb7iLhqD0jAIdYFAl5NhZgACgkQiLhqD0jA
IdaXEBAAp6CO9J61DuTdCA32sn6M+sZSjXlWmJH06gecgw3eeynVTevPUtFmRZx6
jcvjDzHKxvlQRar2zMh6B9/ZN65OdjO/gJQIarz8anZNoGer6OWWFBDB0vb91ROD
ZlfopI6XgGbbEufOrB3MBtFQkT7YS5RrZd8Gm7GEFhV3bCYxnh/RRkhXCH+zhLPP
OnkBbgG9muSe1VYOHqo8Z2CRpp9KWRnGwThyFkHrWgF9/rplWc/lWqpjxgY1UsP9
0z60HmADtuvM+S1xciOu+2IFo+BGPb2bLhwUNAMlRSFzvLyEb55MAnBRrI7Qeu0Y
WgCvyRpSwt7Pmtn2CXqYlfg7mMNgks657DLp98tdF/pIy8bPWMT2N3IkECER5UjI
mNpuNgOZVUiqUglO+yLx+H7p0RF7bMfzUHts3aszdkuHoNuKp+xRq/EO5cPB+3ID
bigzdCb/eyHvu+WV+o1vLo6BTNiX3V+PoMT7HP1DhWYDB3z7b/7iJ/pAGCXLi4QL
QZLwyRq7fU0wMalL/qmAyhNtvxJGOXKN9iybzyglIj+EIe4nRawdKqrmEvnSSnPQ
A4YyRd7x4VN8apnpxwcqkV97kQnpACOPmsfpuzfr+O+LdwKGV4J0NWe9YP3sIx+N
7g2OgKLJqQ8L7zeYp3rABG++rlXruxlcEmZdcQY+1Z4ja39GHrw=
=EKCe
-----END PGP SIGNATURE-----

解決😃

Azure DevOps の SSH public key に ecdsa-sha2-nistp521 な鍵を追加しようとしたら invalid key される問題(未解決問題)

つらい Azure DevOps ECDSA invalid Microsoft SSH public key

Azure DevOps に ECDSA-521 な公開鍵を登録しようとしたらイヤイヤされた😅

f:id:USAGI-WRP:20200218122002p:plain

つらい。

Visual Studio Developer Community にも「なんでや…」な感じのスレッドがありました:

「なんでや…」が続くスレッドに Burak Oezhan がこの記事よりたったの 6 日前に "気づき" を投稿していました:

f:id:USAGI-WRP:20200218122426p:plain

ECDSA 鍵を扱う機能自体は有効なんだ。フロントエンドが送信された鍵を阻んでいるだけさ。 フロントエンドを通すために "ssh-rsa" を "ecdsa-sha2-nistp521" の前の行に追加するんだ。

あるいは別の方法として、 単純に AAAA より前の全てを削除してもいい。鍵自体は AAA... から始まる部分だ。

何れにせよ、フロントエンドはチェックを飛ばしてキミの鍵は有効になるだろう。

…と思ったんだが…、このフロントエンドのチェックを迂回する方法では鍵のフィンガープリントも正しく表示され機能しそうに思えたものの、残念ながらコードを push/pull しようとしたらダメだった。

なるほどー、と思い私も "ssh-rsa" 行を追加する方法を試してみたところ、確かに鍵の登録は一見正常そうに動作したものの、 push/pull はできないという残念な状態も再現されました。

つらい。

Azure DevOps 採用するのやめたくならないうちにはやくサポートして欲しい。

事前情報で確認する OLYMPUS OM-D E-M1 Mark Ⅲ vs. Ⅱ 購入可否を検討するための資料メモ

Camera Olympus OM-D E-M1 Mark Ⅲ diff Mark Ⅱ

OM-D E-M1 Mark Ⅲ が今月末に発売予定で公式やキタムラほか購入予約も始まりました。既存の、特に OM-D E-M1 Mark Ⅱ からの更新を検討したいユーザー向けに diff 的な表示があると嬉しいです。公式にはないので検討のため作りました😆 ちなみに、新規に Ⅲ を検討する場合は公式のエモい機能説明と、マイクロフォーサーズ(MFT)初めての場合はMFTと他のシステムの違いやメーカーによる癖の違いをお好みで調査すると👍と思います。

diff

諸元

# 注目対象 Mark Ⅱ Mark Ⅲ Note
1 DSP TruePicⅧ TruePicⅨ PCやスマフォだと"CPU"相当の部品。クロック、バス、命令セットなど多くは公開資料が無いが、M1XまではⅧ。Ⅸの採用はM1 MarkⅢが初。
2 USB * Type-C
* データ通信のみ 		* Type-C/PD
* 本体へ給電可
* バッテリー充電可 		Ⅲからは専用充電器を旅先へ持ち歩かなくてもよくなり、給電/充電をスマフォやNintendo SwitchとUSB給電器を共有できる。携行性/機動性をちょい旅で活かしやすくなる。静物撮影でもⅢからはバッテリーを気にせず集中しやすくなる。
3 手ぶれ補正 * 5軸+電子
* 6.5段(本体6段) 		* 5軸+電子
* 7.5段(本体6段) 		M1Xで採用された"これ以上は地球の自転が影響する"らしいハイテックギミック。つよい。主に手持ち撮影とハイレゾ撮影に影響。
4 ハイレゾ撮影 * 50MP(三脚必要)
* 25MP(三脚必要) 		* 80MP(三脚必要)
* 50MP(手持ち可)
* 25MP(手持ち可) 		Ⅱから搭載された超解像ハイテックギミック。手ぶれ補正の強化により50MPまでなら手持ち可能に進化。静物なら80MPでとても綺麗に撮影できる。すごい。
5 データ接続性 * USB 3.0
* IEEE802.11b/g/n
(O.I.Share:アドホックのみ) 		* USB 3.0
* IEEE802.11a/b/g/n/ac
(O.I.Share:アドホックのみ)
(Capture:インフラストラクチャー可)
* Bluetooth 4.2 BLE 		Ⅲから無線LANでもPC(Capture)と繋げられる。USBびよーんしなくても小物のパーフェクトな撮影ができる。便利。Bluetoothにも対応したのでO.I.Shareのためにわざわざスマフォのネットワークを切り替えてアドホック接続する必要も無くなる。快適。
6 物理ボタン類(変更点のみリスト) * 露出補正(Fn2表示あり)
* Home(Fn1表示あり)
* MENU: 背面右下
* INFO: 背面右上 		* 露出補正(Fn2表示なし)
* ISO(Fn1表示なし)
* MENU: 背面左上
* INFO: 背面右下
* ジョイスティック 		Fn1/Fn2の主機能と表示がちょっと変わった。どうせカスタムするのでわりとどうでもいい。MENU/INFOの位置が大移動して、ⅡでINFOのあったところにⅢではジョイスティックが付いた。ジョイスティックの搭載はM1Xから継承した形。使ってみないとわからないけど、たぶん便利なんだろう。
7 プロキャプチャー シャッター前14フレーム シャッター前35フレーム 誰でも簡単よゆーで動物撮り。動物を狙う前提がある時には便利。不意打ちだとモード切り替えできないので対応できないのは仕方ないか。
8 シャッターカウント 200,000 actuations 400,000 actuations 毎日シャッター数百回みたいなスーパーヘヴィな使い方でなければ良い意味でどうでもいいの域。50シャッター/dayで使っても18250シャッター/year。Ⅱでも11年弱保つ。Ⅲだと22年弱保つ。それだけ使い続けるにしてもシャッター寿命前にオーバーホールに出すと思う。
9 Live ND なし あり M1Xで実装され、Ⅲにも継承された。物理NDフィルターに頼らずにボディー内蔵機能のみで減光し、スローシャッターをサポートする機能。物理NDフィルターよりノイズも乗りにくく手間もないのでスローシャッター撮影が捗る。あったらあったで嬉しそうな機能。
10 星空AF なし あり Ⅲからの追加機能。星空専門の人はNikonの専用機とか使っちゃうだろうし、そもそもMFTは暗いシーンにセンサーサイズで云々はさておき、手軽に手持ちスナップ感覚で星空を綺麗にMモードでもなく撮影できるのは純粋にカメラをもっていて写真を撮る楽しみ方が増えて嬉しいかな。"ちゃんと"星空撮りたい時もMやリモートでがっちりくまなくても楽できるのは楽で良さそう。
11 顔優先/瞳優先AF (基準値) (基準値に比べると向上) にんげんに興味ないのでよくわかりません。ウサギ、ネコ、イヌ、ゴリラ、ハシビロコウの顔認識ができるようになったら考慮したいと思います。
12 動画 * 4K Cine * 4K Cine
* OM-Log400 (Flat profile) 		M1Xから追加された動画撮影時のLog撮影モードがⅢにも継承。Log撮影は対数でデータを記録する事で整数のリニアー記録よりもダイナミックレンジを広げる手法。3DCGではZバッファーのダイナミックレンジを上げるために応用されたりもするアレと同様の応用で、動画では対数記録されたデータを最終的にグレーディングと呼ばれるチューニングされたリニアーへの再変換を噛ませて使う。映像作品主体の人にはたぶん嬉しい機能追加。
13 ハイスピード撮影 なし 120FPS 動きのある被写体を撮影するひとには楽しみのオプションが増えるのかな。
13 重さ 574g 580g 6g 重くなる。にんにく1欠片分くらいですね。
14 大きさ 134.1ｍｍ（W）×
90.9ｍｍ（H）×
68.9ｍｍ（D) 		134.1ｍｍ（W）×
90.9ｍｍ（H）×
68.9ｍｍ（D） 		外接直方体的には変わらないみたい。

外観

オリンパス公式の外観画像を並べて主な変化どころにオーバーレイマーカーを入れてみました。本項の画像は OLYMPUS 製品紹介 OM-D E-M1 MarkⅡ 製品外観 および OLYMPUS 製品紹介 OM-D E-M1 MarkⅡ 製品外観 から引用しています。引用元の画像の著作権はオリンパスイメージングに帰属します。

前面と上面右手側

f:id:USAGI-WRP:20200215122645p:plain

  1. ロゴ位置: Ⅱ は左上面、Ⅲは前面
  2. ホットシューのレール: Ⅱは黒塗装、Ⅲは金属のグレー無地っぽい
  3. 上面右手 Fn2 ボタンの表示: ⅡはボタンのそばにFn2表示あり、ⅢではFn2表示なし(ボタン上の表示は露出補正のまま変わらず)
  4. 上面右手ダイヤル: Ⅱには無かったバルブモードが、ⅢではB表示で追加

背面

f:id:USAGI-WRP:20200215122658p:plain

  1. MENUボタン位置: Ⅱでは右下、Ⅲでは左上へ大きく移動
  2. INFOボタン位置: Ⅱでは右やや上、Ⅲでは右下へ移動
  3. 右上 Fn1 ボタンの表示: ⅡはボタンのそばにFn1表示あり、ⅢではFn1表示なし。ボタン上の表示もⅡではHome、ⅢではISOへ変更
  4. ジョイスティック: Ⅱにはなし、Ⅲはあり(ⅡのINFOボタン位置にⅢのジョイスティックが配置、MENUとINFOの大移動はこの変更も要因として大きそう)

お買い得？

わたしは Ⅱ から Ⅲ へ更新します。理由は次の通り:

  1. Ⅱはそろそろオーバーホールしようかなと思っていたので、そこそこお金をかけるならⅡを下取りでⅢを入手するのはちょうどよいタイミングだった。
  2. メシテロや作業ログで頻繁にⅡの撮って出しを O.I.Share 経由でしているので、ⅡのWLANのアドホック接続切り替えはそこそこのストレスでした。ⅢではBTで接続できるし、PCともWLANで接続できるのでとても楽になります。
  3. DSPがⅧからⅨにアップグレードというのは、諸元の差分的にもおそらくそれなりに基本的な処理性能も向上していて、動作のちょっとした重さが軽快方向へ改善され無意識的な部分まで含めてストレスが軽減されるだろうなーと期待しています。
  4. USB給電/充電できると旅先へ専用充電器をもっていってACを1つ占拠させなくてもよくなるので楽でいいです。PC接続で撮影する場合もバッテリーが無くなりそうになっても一旦OFFして予備バッテリーへ交換するよりもケーブルをつなぐだけでよくなるのは楽でよいです。
  5. ハイレゾ80MPは欲しい機能です。小物撮影では事実上一般的には目視不可能なレベルの微細構造を確認しやすくなります。よほど目的がある場合を除き三脚や一脚は持ち歩かずカメラは peek design の capture で機動性を重視する事が多いので、50MPでも手持ちハイレゾできるのは魅力が大きいです。風景もハイレゾ撮影すると無理なく極めて美しく、文字通りの超解像が得られてよい機能なのです。

と、いうわけでⅡからⅢで改善されそうなストレス、楽しくなりそうな機会の向上を中心にⅡの下取りで更新できるなら人生を豊かにする意味では間違いなくお買い得と思います。

基本性能は変わらないので費用対効果は薄いだとか、他社の数年でのカメラの進化と比較するとどうとか、今回のⅢの発表には否定的な意見も散見されますが、M1 Mark Ⅱを実際にホビー用途ですけれどメインで使って人生を楽しんでいる私としてはそれほど悪い更新ではないと思っています。もちろん、ユースケース次第で、私と同様のケースが多勢になるとも思っていませんが、今回のⅢは私を含めた他人の感想文よりも、この記事で示したようなdiffあるいは公式サイトの発信する魅力に強く惹かれるかでそれぞれに判断が賛否両論になるのだろうな、と思います。否定派を否定するつもりもありません、実際ハードウェア的な進化はDSPの更新は大きいと私は推量するものの（DPSの詳細仕様は公開されていないのでThreadripper2990WXと3990Xくらい違うのか、とか客観的に判断できない）、カメラの光学系とADC系までの電気系は据え置きなわけで"進化速度"を費用対効果でみれば極めて薄い事も事実です。

私はそれでも、MFTシステムとOLYMPUSのOM-Dシリーズで得られる絵の方向性がCanonやNikonより好きですし、動画メインでPanasonicを使いたいというお気持ちもありませんし、OM-DとM.ZUIKO DIGITAL PRO系の防塵性やSSWFもとても気に入っていますから、先に上げた理由を中心に、豊かな人生の楽しみの投資として十分に価値のある事と判断しました。

で、どこで予約したの？

今回は「カメラのキタムラ」で予約してみました。

公式のお買い替え応援キャンペーン/下取お申し込みでOM-D E-M1 Mark III 限定特別割引クーポンをプレゼント！も検討しましたが使いませんでした。下取り指定のデジタルリユース/KAIMASUというサービスは私はよく知りませんでしたし、そこでのⅡの買取上限価格は61,000円、Ⅲ発売記念キャンペーンで査定額+3000円、フォトパス経由のⅢ購入クーポンが15,000円、そしてオリンパス公式通販のⅢは217,800円です。つまりこのルートでは最良ケースで 138,800円 の出費になります。

カメラのキタムラの場合、Ⅱの下取り最高額は80,500円(買い取りでも72,450円)、Ⅲは私が予約した時点で 196,020円 でしたから、最良ケースで 115,520円です。ついでにTポイントも使える＆たくさん貰えます。Tポイントは後ほど出前館で美味しいお弁当に変えられます。…実際の査定額はわかりませんけどね😅

カメラのキタムラには大昔まだデジタル化が先鋭化する以前の時代はリアル店舗で楽しませて頂きました。それからしばらくデジタル化に出遅れてこの世から消えてしまうのかなと思っていた時期もありましたが、規模は縮小しつつも全国にリアル店舗もまだまだ構えているようですし、最近は復活しつつあるのかな。なんだか懐かしいので今回は横並びの売価からキタムラを選んでみました。

参考

AMD Ryzen Master vs. Microsoft Windows 10 WSL2 ( Hyper-V; Virtualization-Based Security(VBS) )

AMD Ryzen Master WSL2 Hyper-V VBS Virtualization Based Security Microsoft Windows 10 HYPERVISOR_ERROR problem

※この問題は本質的には未解決です。

もんだい

Ryzen Master は WSL2 を使用可能な Windows 10 環境で起動しません😂

f:id:USAGI-WRP:20200204195022p:plain

Ryzen Master can only run with Virtualization Based Security (VBS) disabled in the Windows operating system. Please disable VBS and re-start Ryzen Master. Virtualization-Based Security (VBS)!

訳:

Ryzen Master は Virtualization Based Security (VBS) を無効化した Windows じゃないと動作しません。VBSを無効化して Ryzen Master を再起動してね。 Virtualization-Based Security (VBS)!

無慈悲なエラーです😂 ここでいう VBS はこの問題への対処の上では事実上 Hyper-V と大雑把に読み替えてOKです。(正確にはそれぞれ別の機構ですが、この問題をユーザーが必要とする視点で考える上では"すなわち"的に結びつけてOKです。)

昨年末からわたしもWSLをWSL1からWSL2へ以降していました。1つ前のメモ CPUとMBの間にゴミが詰まっていてもPCは動く事がある。但し今回はメモリーの不調の原因でした。のメモ の事があり、モニタリング用に Ryzen Master を起動してこの問題へ対処する必要が生じている事に気づきました。既にWSL2をWSL1へ戻したくはありません…。

バイナリーパッチによる対策方法

根本的で本質的な解決とは言えませんが、 Ryzen Master の実効バイナリーへバイナリーパッチを充てて問題を解決できます。

↓Twitter に居るギークのひとり TOM_RUS の投稿より (†1)

Like this in version 2.1.0.1424

f:id:USAGI-WRP:20200204202338p:plain

↓Twitter に居るギークのひとり steeve の投稿より (†2)

Current status: reversing @AMD's Ryzen Master tool to make it work when Hyper-V is enabled...

f:id:USAGI-WRP:20200204203007p:plain f:id:USAGI-WRP:20200204203000p:plain

Found the culprit...

f:id:USAGI-WRP:20200204202908p:plain

0x0F84 is a conditional jump if zero to current program count + 0x000000F7. Basically, if the sub_14003CA80 method doesn't return 0, don't jump (continue), and display the nag screen. We're going to turn that into a unconditional jump (never display the nag screen).

f:id:USAGI-WRP:20200204202838p:plain

Now a unconditional jump (jmp) is 0xE9. One byte instead of two (0x0F84). No problem, we're just gonna pad it with a nop instruction (0x90). Let's patch it out.

f:id:USAGI-WRP:20200204202801p:plain

Success! For those who have a Ryzen CPU and WSL2, load "AMD Ryzen Master.exe" in you favorite hex editor, go at 0x014E67 and replace "0F 84" with "0x90 E9".

f:id:USAGI-WRP:20200204202813p:plain

私も試してみたのですが…

f:id:USAGI-WRP:20200204231737p:plain

問題の箇所はいまのところバージョンや実行環境が変わってもIDAでデバッグ実行すればすぐに見つかるものの…

f:id:USAGI-WRP:20200204232115p:plain

oops! 使用中に不意に緑画面で HYPERVISOR_ERROR が発生しました。これは HYPER-V とか VT-x とか今回の問題への関連性の疑いがとても強いBSOD(緑だけど)状況なので、少なくともいまは WSL2 と Ryzen Master の同時使用は諦める事にしました😅

この問題は Ryzen Master 側のソフトウェア開発に起因する課題のようですが、どうやら長年といえる程度にはAMDからは現実的な対応がされないまま、AMD公式フォーラムでの回答(†3)も

(意訳) 「Ryzen Master が Hyper-V/WSL2 と共存できるようにしたいけど、今のところ Ryzen Master を使いたい時は Hyper-V (VBS) を無効化してね。」

となったまま進展していないようです。WSLのイシュートラッカーでもAMDがどうにかしてくれるようにMicrosoftぱわーを借りられないか的な叫びが…ちょうどさきほど追加されていました(†4)…。

注意

この記事の内容を元にバイナリーパッチを施した Ryzen Master を実行して起こるあらゆる事態は実行した人の自己責任です。よくわからない場合はどちらかを諦めつつAMDの対応を祈って待ちつとしましょう…。AMDのフォーラムの関連スレッドへ👍しつつ…。

参考

CPUとMBの間にゴミが詰まっていてもPCは動く事がある。但し今回はメモリーの不調の原因でした。のメモ

AMD Ryzen Threadripper 2990WX ASRock X399 Taichi memory trouble resolved CPU contamination professional work failed tsukumo

Threadripper のメモリー回りがシビア過ぎるせいだと思って半ば諦めていたメモリー認識の問題が解決したメモです。

状況

  • PCの電源をONすると、ランダム発生っぽい感じでメモリーが1枚認識されなかったり(†1)、本来のメモリー性能を発揮できない認識になったり(†2)する
  • たまに期待動作する
  • このPCはツクモ店頭で部品単位で店員さんと相談しつつ購入し、組み立てはツクモのひとにお金を払って代行して貰いケースに収まった状態で自宅へ発送して貰っていた
    • これまでCPUクーラーの取り外しまでは何度かしているけれど、交換するようなCPUではないし、"CPUの物理的なインストールは正常にできているのでPOSTをクリアーできている…"と思い込んでいたため、CPUを取り外して確認した事は無かったのです…

(†1),(†2): CMOSクリアー、BIOSアップデートなどを行い再起動すると抽選が発生。使用開始直後はだいたい期待動作していたが、数ヶ月、1年、…と時の経過に比例してメモリーのXMP設定や調整でPOST死したり、メモリー3枚しか実用可能な認識状態にならない率が高まり、最近ではすべてのメモリーを認識し、XMPのSPEC通りの設定で動作する事は稀なほどになっていました。そのため、期待動作したら電源を落とさないように使っていたのですが、今朝はいよいよ期待動作しなくなったようでした。

(†1): BIOS(UEFIだけど)の"メイン"ほかではメモリーが1枚認識されていない扱いになる状態でも↓のメモリーのprofileを読み出す画面では認識できている謎の状態になる。認識されなくなるスロットもランダムっぽく変わるが、発症するとリセットしただけでは認識がおかしくなるスロットも変わらなくなる。

f:id:USAGI-WRP:20200204093917j:plain

(†2): XMP 設定にするとメモリーエラーが発生してPOST死したり、細かいメモリー設定のチューン、ダウンクロック、昇圧などを安全な気がする程度の範囲してもPOST死したりする。発症中はJEDEC#1から2133MHzのprofileを自動認識させた場合のみPOSTを抜けるようになる。

PCの構成

  • CPU: AMD Ryzen Threadripper 2990WX
  • MB: ASRock X399 Taichi
  • RAM: G.Skill F4-3200C16D-16GTZRX (合計4枚、32GB)

試したけれど無駄だった事

  • 「メモリー部品の不良」や「MBの不良」を疑い、
    • 差し替えたり
    • memtest したり
    • BIOS アップデートしたり
    • BIOS をデフォルトへリセットしたり
    • CMOS クリアーしたり
    • GPU 抜いてみたり変えてみたり、CPUとMB以外の部分を分解/再実装したり取り替えてみたり…
    • メモリーに関係しそうなチューニング向けの設定をいじってみたり...

解決に至った答え

同様の症状を相談した ASRock のフォーラムで mhp 曰く、

Problem was solved when I re-seated the CPU on the MB. Thanks a lot to xhue for the advice! I couldn't find a bent pin but probably there was a pin (or more) not touching where it should :)

訳:

CPUをMBに再装着してみたら解決したよ！アドバイスありがとう xhue ！ 曲がったピンは見つけられなかったけど、たぶんどこかのピンが接触不良だったに違いない😂

さらに、このスレッドには同様の症状が同様にCPUの再装着で解決できたという報告が追加で寄せられていました。

「なるほど、そういう事もあるかもしれませんね…」と薄い期待を懐き、一応ほかにもう手も無いので試してみる事にしました。（私の場合はCPUをMBへインストールしたのはツクモの組み立て代行のプロフェッショナルでお金払ってやってもらった信頼の仕事…だったはずだから、まあその手の問題ではないでしょうけど…と思いながら。）

↓CPUオープン…んむむむむー？？？！

f:id:USAGI-WRP:20200204100355j:plain

CPUに何かが付着しているか、あるいは端子のめっきが剥がれているか破損している？？？などと思い、よーく観察すると、どうやら「付着」の方らしい気配。（精密工作用のルーペを使用した目視による判断）

f:id:USAGI-WRP:20200204112027p:plain

↓ピンセットでつまんで、とりあえずCPUをスライド・インする橙の枠部分へ移動してみたの図:

f:id:USAGI-WRP:20200204100719j:plain

"ちょうど Threadripper 2990WX の端子1つ分ほどの大きさで、金属光沢を感じる、とても薄い何か"でした。目視ではそれ以上の事はわかりません。これが食べ物だった場合は異物混入として原因特定可能な程度に製造者（会社）が分析を試みてくれたりもしますが、これは組み立てを担当してくれたツクモさんに報告しても原因特定を目的とした分析まではたぶんしてくれないかな。謎の物体は謎の物体のまま。

f:id:USAGI-WRP:20200204112115p:plain

ともかく、この謎の物体を除去したところ、これまでのメモリーの不調が完全に解消されました。めでたしめでたし。

f:id:USAGI-WRP:20200204105352j:plain

↑XMP自動設定でも試した限りでは100%正常に期待動作するようになってくれました。もちろん、挿したすべてのメモリーが認識されています😃

だそく

ツクモさんには状況の報告を優しくしつつ、分析用にほしければこの謎の物体もキープしてあるので送りますよと連絡します。プロもミスはします。ただ、このミスは丁寧に仕事をしていればおそらく状況発生しなかったようにも思います。AMDの出荷時に既に謎の物体が付着していた可能性もあるかもしれませんが、ピンセットで特に苦労もなくつまめる物体が出荷前の洗浄工程以後に付いたとは…考え難いかなって思います。

CPUとMBの間に謎のゴミが挟まって、一見動作するけれど何かが極めて気難しい"不調"な動作になる。そういう事が起こる驚きと知見の取得の楽しさに比べれば、ツクモさんのミスへの負の感情はほぼありません。

この件で、ツクモさんや担当してくれた方を中傷したり、謝罪を要求したりはしませんが、さすがにプロの仕事で相応の代金もとってやって頂いていた事でしたから、私個人としてのツクモさんへの信頼低下はさすがにどうしようもありません。ツクモさんは好きなお店のままですし、今回の件の社内での情報共有と再発防止も図られるでしょう（たぶん）。

Insider で Windows 10 19041.1 に update して WSL2 に Arch 環境を作り直したメモ ( 昨夜まで WSL1/Ubuntu を使っていました )

WSL2 Arch Linux install setup

f:id:USAGI-WRP:20200113163753p:plain

↑ WSL2 で Arch linux が動いていて Windows Terminal (Preview) から使える様子。

手順メモ:

  1. Windows 10 19041.1 (執筆時点) 以降のバージョンへアップデートする (執筆時点ではまだ Windows Insider の登録と設定が必要。説明略 -> https://insider.windows.com/ )
  2. WSL2 を使用可能、標準に設定 ( https://docs.microsoft.com/windows/wsl/wsl2-install )
    • Tips: dism.exe は管理者権限で実行する必要がある。 sudo とか choco してないとめんどくさいかも
    • Tips: dism.exe の実行例をそのまま実行すると dism.exe は処理を返さないので、いつまでもコマンドの処理が終わるのを待つ必要はなかった
    • Tips: sudo dism ... を2つ実行したら処理が返ってこなかろうが、 restart する…のだけど、念のため手作業で可能な限り動作中のアプリを終了させてから restart した方が安全。
      • 私はなぜか TaskManager が終了できないけど強制的に終わらす？とか出て、状況確認＆手動で終わらせようとNoしたら…Noしたのに…なぜか更新しています画面に遷移してエターナル更新終わらない状態に突入されました。その後、PCをメインボードレベルからリセットしてやり直しました。
    • Tips: wsl --set-default-version 2 が期待動作すれば、そこでWSL2準備は完了です
  3. https://wiki.archlinux.jp/index.php/WSL_%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB を読んで「めんどくさいな」とか「Archのビルドマシーン必要なのか」とか少し不安を覚えます。覚えるだけでいいです。
  4. https://github.com/yuk7/ArchWSL/ を発見して「ありがとう♡」と思いつつも一応 Arch には Windows Store 事件もあったのでそれとなく中身には気を付けつつ使わせて頂きます。
  5. おまけ: Windows Terminal の設定で標準で起動するタブを Arch あるいは他の何かに変えたい場合は
    • profiles.json に globals.defaultProfile を追加して、値に profiles[n].guid の文字列値と同じ値を設定します。( n は出したいのプロファイルのものを目grepして探してください )