29-May-2022
[うむむ…]

作業中の物置的な何か。(2)で作ったOpenWrtのconfig.buildinfoでビルドし直しても、何故か構築がうまくいかなくて一体自分は何をやっていたんだろうかと途方に暮れています。

さらに面倒なことに、Windows機と(マシン一覧にスペックを書いていませんが一時期MINECRAFT用にも使っていた)Linux機のネットワーク周りの調子がおかしくなってしまい、NICを入れ替えていたのですが…同じRTL8111を載せているカードにもかかわらずマシンとの相性があるのか、片方はこっち、もう片方はこっちとマシンを選ぶ事態に。結果だけさらっと書くとそういうことになるのですが、安定して動く組み合わせを見つけるのが大変でした。

これと平行して、A8-7600化したWindows機の調子がなんとなく悪いのでAthlonX4 845に戻しています。とはいえ、これもこれでメモリとの相性が悪いところがあるため、適当なSocket FM2(+)なCPUに置き換えることを考えています。GeForce GT1030を載せているので、Kaveri/GodavariにこだわらずRichlandでも良いかもしれません。使っているメモリもDDR3-1600と遅い以上、極端な性能差にはならないでしょうから。※最初に入手したA8-7670KはA6-7470Kが載っていた妻のマシンに入っているため、簡単には取り戻せない状況にあります。

同じA88M-G/3.1を使っていてもWindows機は04-Dec-2016、OpenBSD機は25-Aug-2017と結構時期が開いていると思ったら一年も開いていないのでマシンの老朽化は二台とも着実に進みつつあるという見たくない現実を直視しないといけないようです。ああもうなんてこったい…という訳で、本当になーんにも物事が進んでいないという困った状況です。イマドキの世代でちゃんと動くマシンの1台でもあれば多少は改善するのかもしれませんが、そんなお金は無いのです。57.3kg(21:05)

22-May-2022
[作業中の物置的な何か。(2)]

OpenWrtの構築はBuild system setupBuild system usageにしっかり書かれているのでここで何かを書く必要は無いと思います。

昨日作成したOpenWrtのイメージにmmdvm-openwrtを組み込んだものを作りたいので、こちらも書かれた手順通りに作業。

全体的な手順の流れとしては、こうなりますかね。

その他何か必要なこと、としては…

となるでしょうか。

ビルド時のmake[2] package/indexでWARNING: Applying padding in /home/uaa/openwrt/bin/targets/x86/legacy/packages/Packages to workaround usign SHA-512 bug!というメッセージが表示されたのは気になりますが、config.buildinfoopenwrt-x86-legacy-generic-ext4-combined.vmdkは出来上がっているので置いときます。一応MMDVMHostは起動しているようなので、あとはJumboSPOTをこの仮想マシンに繋いで動かせるかどうかを確認すれば良さそうです。58.6kg(21:05)

21-May-2022
[作業中の物置的な何か。]

VMware上で、OpenWrt-21.02を動かしてみようとちょっと足掻いてます。なんとなく動く物ができたので、config.buildinfoと、出来上がったopenwrt-x86-legacy-generic-ext4-combined.vmdkを動かすためのVMXファイルを転がしておきます。

VMXファイルの作成はvmxMaker0.1.2.lzhを使いました。ただし、生成される仮想マシンのバージョン(virtualHW.version)が3と古いので4以上にしないとVMware Player 16では動作しません。virtualHW.versionの値と対応するVMware製品の一覧は仮想マシンのハードウェア バージョン(1003746)を参照すれば分かりますが、3も4も今となっては非常に古いです(この世代の仮想NICはvlanceで、vmxnet3の対応は6(VMware Workstation 6.0.x)以降のはず)。

仮想マシンの世代が古いため、OpenWrtはGeneric x86/Legacyにしています。起動時にタイマーの検出か何かで引っかかるのが気になりますが、これを回避するためにはカーネルオプションにnoapicを追加する必要がありそうです

あとは起動後にuci delete network.lan; uci set network.lan=interface; uci set network.lan.device=eth0; uci set network.lan.proto=dhcp; uci commitでeth0にDHCPでアドレスを割り振るようにし、再起動後にeth0に割り当てられたIPアドレスにwebブラウザでアクセスしてLuCIの動作が確認できればおしまい。58.2kg(21:25)

15-May-2022
[OpenBSDでmrefd(M17リフレクタ)を立ち上げる]

無線機無いしあったとしてもどう変更申請書くんだよ(仕様書の和訳が要るのでは?)という状態ではあるのですが、ソフトウェアを試すことに対しては免許が要らないのでまずは手を動かしてみます。

mrefdは基本的にxlxdのコードに由来しているようなので、考え方はxlxdのインストールと似てはいるのですが、

  1. bash rconfigでconfigure.h, configure.mkを作成
  2. CXX=c++ gmakeのように使用するコンパイラを指定してからmake
  3. dashboard(ref-dash)を別途インストール

という流れになるでしょうか。

あまり細かいことを書かなくても分かると思いますが、rconfigは必須となる項目(M17-で始まるリフレクタのコールサインと、IPv4 Listen Addressを設定しておけば十分です)を埋めておかないとWrite configuration files and quitできません。

これを書いている時点(mrefd-0.3.6)のMakefileでは、make installで以下のファイルを配置します。

OpenBSD標準のディレクトリ構成と違いますがその辺りは無視するとして(下手に変えると面倒です)、systemd用の設定ファイルを勝手に突っ込んでsystemctlを呼ぶというのは流石に面倒なのでこれは潰してからgmake installする方が良さそうです。なお、Makefileに関するPRで、mrefdの作者はDebian系以外は対応しないとコメントしていますので、systemd非採用のLinux distro(Slackware/void/Obarun)で構築する場合も注意してください。

また、/usr/local/etcに配置されるblacklist, whitelist, interlink関連のファイルはシンボリックリンクなのでこれも注意が必要です(これも意図的にこうしていると作者は言っています)。

ref-dashの設定は、xlxdのdashboard2と大体同じです。include/config.inc.php.distをconfig.inc.phpにコピーし、

辺りを設定すれば足ります。自分の場合、xlxdの時と同様に$PageOptions['ContactEmail']にURLを記述してこれに対応できるようindex.phpに手を入れ、$PageOptions['PageRefreshDelay']を10000から60000に増やしています。

あとは/etc/rc.localに


if [ -x /usr/local/bin/mrefd ]; then
	echo -n ' mrefd'
	/usr/local/bin/mrefd &
	top | grep mrefd | awk '{print $1}' > /var/run/mrefd.pid
fi

を追加すればとりあえず動く感じです。xlxapiのようなものがM17には今のところないようなので、$CallingHome['HashFile']に関する問題も気にしなくて良さそうです(という訳で、どうやって稼働中のM17リフレクタをM17 Reflectorsに伝えるのでしょうかね…?)。

MMDVMHostは比較的Linux以外の対応に寛容なようですが、xlxd/mrefdについては塩気が強いです。今後の状況次第ではOpenBSD上での動作を諦める可能性も考えておく必要があるのかもしれません。56.8kg(19:30)

08-May-2022
[流石に参りましたね…]

24-Apr-2022に書いた、i5-4690+H81MHV3がメモリを選ぶのか手元のDDR3メモリでは何を使ってもmemtest86+で必ずエラーが出てしまうという事態のその後。なんとなく、メモリの問題というよりも長時間動作させた場合の安定性に難があるような感じ。

tp55064526.jpg tp55074527.jpg tp55074528.jpg

マザーボードの動作確認を販売店にお願いし、マザーボードの動作には問題がないとの回答を得たのでメモリを買い替えようかな…と相談したところ「むしろ他を疑った方が良いのでは?」とのアドバイスがありました。中古で買ったCPU、これは流石に動作の確認は取れているだろうと思っていたのですが念のためCPUの動作確認もCPUの販売店にお願いすることにしました。※マザーボードとCPUを買ったお店は異なっています

こちらは保証期間の7日間が過ぎてしまっていたものの、とりあえずの動作確認はしてもらえました。とはいえ、memtest86+での長時間動作ではなくPassMark Memtest86(Free)の4-passで問題無しとの回答でした。こちらと同じ手法での再テストをお願いしたところ時間が無いという理由でテストを拒否されてしまったので(送料の都合もあり)同じ販売店でCore i3-4130を購入し、以下のメモリでテストしてみました。

tp55084529.jpg tp55084530.jpg

…どちらも12時間以上放っておいても全く問題が無かったので、i5-4690の問題と考えるしかなさそうです。マジか。

この件、お店のチェックが甘いと言うことは非常に簡単なのですが(そりゃあお金を返してもらえるなら返してほしいです)、それに対してチェック体制をどう強化すると良いかという提案をしづらいところでもあります。お店の立場で考えるに、全ての買い取ったCPUに長時間動作のテストを行うというのも難しい話でしょう。

既に動作の確認が取れているシステムでCPUのみ交換するようなケースであれば、おそらく保証期間内に問題を見つけて対処することはできたと思われます。しかし、新調したマザーボードに部品箱に眠っていたメモリと適当な中古のCPUで、という組み合わせで起きた今回のトラブルは…どうやれば7日という制限時間内にCPUが原因であると突き止められるのか、自分には全く方法が分かりません。※電源を交換しても問題が解決しなかったため、電源の問題ではないと考えています

オーバークロックに伴う殻割や電圧上昇等により痛め付けられている個体が出ている可能性が高そうだという理由でi5-4690Kを敢えて避け、i5-4690を選んでいたのですが、それでもこのような事態に遭遇するのは複雑な気分です。その一方で、長時間の連続動作を行わないと問題が分からないような呪われし品をどうやって作り出したのかについては興味があり、元のi5-4690の持ち主に詳しくお伺いしたいところです。56.8kg(18:55)