全892件 (892件中 51-100件目)
最近 SD Card Reader が使えない日記の参照が増えていたのが気になっていた。実家に寄ってみたら、また「ノート PC の SD Card Reader が使えなくなったので見て欲しい」との事だった。「ディレクトリ名が無効です」、また出たか。前の日記と同じように SD Card Reader のドライバを「SDA 標準準拠 SD カードホストコントローラー」に変更して修復した。Windows 10 1803 へのアップグレードをした直後から症状が出たようだ。前回も同様にアップグレードで起きていた。うーん、Microsoft は前回の問題を全く省みていないのか?
2018.06.20
コメント(0)
仕事を始めた先で新しいソフトウエア開発手法を導入するという流れになった。「何だろうな、合わないな...」という何となくな言葉が思い浮かぶ。もう少し、具体的な言葉にこの感を置き換えられないだろうか。久しぶりにダラダラと日記を書くことになりそうだ。手法が要求している事項: 「チームメンバーの誰もが同じスキルを持ち、誰にでも仕事を割り振ることができて、開発工程の全てを短期間でできる。」... 何だろう、基本的な生産工学の観点無視な手法は。人間で無くても製造装置には能力差があり、できることに違いがある。使用可能な資源割り振りは、基本的な課題のはずだ。そんなの無視で「上手くいきますよ」と... 正直言えばこの時点で手法の有効性に疑問が出てくる。ソフト開発はほぼ人間の手による。お互いの相性、気持ちの持ちよう、疲労度、作業内容の伝達解像度、ほか色々、製造装置には無い特性がある。この特性も加味して仕事の割り振り、進捗管理、打ち合わせ(あるいは議論)を持たないとチームは半年もすれば暗い雰囲気になる。おおよそ最近の手法論ではコミュニケーションをすれば、人間的特性が開発進行に与える影響は軽減されるとの立場を取っている。本当だろうか? 自分も既に 40 才台後半、性格は変わらないし、人との相性も変わらない。色々と高齢者達を話す機会を持った経験からすると、一生変わらない、あるいは加齢に伴う認知能力低下でさらに難しい状態になる。正面切って「開発チーム内のお互いの相性重視でプロジェクトを進めるよ」といった手法論は無いのだろうか?手法が要求している事項: 「要求の受付・変更は 2 週間程度のインターバル単位で行う」。そうですか、外部要因(内部要因も多くある)はほぼ時間軸で無視して上手くいきますよ。ですか。理想論を押し通しだ。現実に目を向ければリリース後に行われる外部の途中評価、徐々に完成・変化する結合対象となる周辺状況は、自分たちのチームとは非同期に変化する。こういった変化を自分たちが決めたクロック・エッジで入力、出力するのか(出力はクロック・エッジには乗せないのかも)。チーム外部とのやりとりに使われる時間間隔はどんなものが有っただろうか、定時 → 翌朝一、午前終わり → {午後一, 定時前}、月→{水|金}、1週間後、最小単位くらいで 3 時間くらいか。2 週間のサンプリング周期では周囲状況に追従することはできない。なんだろう、標本化定理とか制御理論とか難しいことは言わなくても、おかしな想定だと分かりそうなものだ。応答性が悪い人・チーム・組織はどうなるのだろうか?似たような手法を導入して、一度経験したことが有る。恐ろしいことに会社の中で組織ごと浮いてしまう。組織単位で周囲は離れていく。個人は首にできない、一方、組織はリストラできる。組織全体で誰も口にせずとも恐怖感が共有されるのだ。誰かが口にしたときは相当に深刻な状況だ。手法が要求している事項: 「作業内容は 2 ~ 3 時間単位で区切る」、「2 週間単位の大まかな仕事内容は 1 つにする」「2 週間後には完了・動作可能なものになっている」。開発手法を考えた人、何作っていたんだろう? 自分が開発をしている現場では部分ビルドだけで少なくとも 30 分は掛かる。フルビルドで 3 時間だ。その間、「ただ待っている?」そんな段取りはしない。次週から 3 週間後くらい先までの作業予定内容の勉強、前終わった作業結果の再確認をする。終わったのに何故に再確認?単発的なテストは済ませている。その後は 1 日から 1 週間程度の連続稼働テストを実施する。ループ・スクリプトを組み自動実行を続ける。出力結果の確認、メモリリークやプロセッサ負荷に異常が無いかの確認、最も影響が出やすそうな結合対象の状況変化、その担当者の感触の再確認、おおよそ 2 ~ 3 の作業内容を同時に進めている。2 週間で動作可能に持ち込むのも難がある。自分はデバドラ屋だ。デバイスを Read/Write して、DMA を動かして、file operations を実装して、部分部分は動くかもしれない。それは結合相手にとっては何も動いていないのと同じだ。デバイスのデータシート読み、ハードウエア設計部門からの制御指示を熟読し、ステートマシン設計(他色々)、破綻を起こさない排他制御、OS 由来の制約条件、全てを満たすように実装していく。デバイスの Read/Write だけをして、「言われたとおりの動作をしました。ウレシイネ。」なんてストーリーは無いのだ。ここだけ動けばいいや的なインクリメンタルな開発をしていくと、考えもしなかった排他制御矛盾に陥ったり、ステートマシンの遷移不良を起こしたり、リソースの解放不良を起こす。気づいたときには後戻りする方法すら思いつかない状況だ。電池ドライバ屋だったときの思いを重ねると、インクリメンタルな開発で、充電しっぱなしで電池爆発、放電しっぱなしでセット文鎮化なんてとてもできないからな...色々と考えを巡らせてみた。まだスッキリしない。新しい手法を思いついたら人間の現場に持ち込んでメトリック(計測)して評価するなんて、古いのではないか?モデルで表現した(具体的に言えばイベントドリブンで変化するステートマシンで表現した開発者、成果物、外部、内部、を使って表現した)開発現場で有効性と適応できない状況を検証してから、人間を動かすために使って欲しい。摩滅する肉体を持ったもので実験をするなんて勘弁して欲しい。自分が大学で「ソフトウエア工学」を学んだのは 20 年以上前だ。あれから、何らかの進歩は有ったのだろうか?モデルができるなら、開発者そのものを置き換えれば良いって? FPGA の上で「開発者」という回路が動いて「成果物」ができる。ああ、それが一番の願いだ。
2018.05.18
コメント(0)
ゴールデンウイーク中に短期運用に付いた Linux PC のディスク内容を整理する。この PC はもともとファイル・バックアップ兼仮想マシンサーバーとして稼働していた。OS が古くなったのと、電力消費が多いので次第に使われなくなり、半年程度に 1 回電源を入れる以外は使っていなかった。OS が古いまま放置したのは、無償だった VMWare Server を動かすことができるのが古い kernel だったのと、色々と手を入れた iSCSI target の kernel driver を新しい kernel に適応させる修正が面倒になったためだ。ディスクに入っているファイルの殆どがディスクイメージのバックアップ、仮想マシンの仮想ディスク、ISO イメージ、アナログ放送時代の録画データも有ったな...バックアップのうち、複数世代があるものは最新のみ残すことにした。最新と言っても西暦 2012 年くらいだ。ISO イメージは現在稼働中のサーバーへ移動する。Ubuntu 10.04 なんて今後使う?仮想マシンは別のサーバーで稼働を続けている。名前は同じか ~2 なんて名前に変わっている。バックアップイメージをリストアしても現在動いている仮想マシンの機能は復旧しない。むしろ周囲を巻き込み、破壊的な結果になるだろう。それでも維持するのだろうか?アナログ放送時代の録画データは... ちょっと見てみる。時間が過ぎてしまうので後回し。もう動かない仮想マシンのディスクイメージを削除する。qemu-nbd --connect, losetup -P (-P はパーティション認識オプション), mount でマウントしてみて、インストールを試しただけか調べる。500Gbyte くらいは減らしたかな。直近で 500Gbyte を使う予定は無し。今日の作業の結果、今後に変化なし。
2018.05.12
コメント(0)
連休が明け出勤する。勤め先のネットワークが遅くなっていた。自分だけ監視対象になったかな?と思っていたら、周囲の人たちも遅いと言っていた。全体的に遅いのか。みんな一斉に update のせいだろうと、理由を推測する声が聞こえてきた。確かに update のせいなのは間違いないだろう。速度を律速する設備は何だろうか?ネットワーク設備の構成は知らされていない。ヨソ者に簡単に教える情報では無いだろう。単純に考えれば、回線を構成する光ファイバーだったり、メタルのツイストケーブルだったりする。やたらと情報統制が厳しい勤め先だ。本当は L3 ルーターか L2 スイッチにトランスペアレント・プロキシが入っているのでは?と思う事が有る。接続先の TCP port と直接コネクションが確立しているつもりでも、パケットを監視するフィルターを経由したり、送信元を偽装するため VPN を経由して別のプロバイダーから繋いだり、通信量を減らすためにキャッシュを経由している? 目に見えない経由が律速の原因?自営の野良サーバー相手に試せばある程度分かるかも... 自重しよう... 本当に夜に誰か訪ねてくるかもしれない。
2018.05.07
コメント(0)
Android Source Code を構築するための要求事項(Requirements) を見ると 16Gibyte の RAM/SWAP が必要と有る。Android を構築しようとする環境は RAM: 8Gibyte, SWAP: 23Gibyte, CPU: AMD Phenom II X4 945 (4core 3.0GHz) だ。メモリは足りているはず?と思って Android 8.1.0 の構築を arm と x86 ターゲットでしてみる(時間的に直列に)。どちらも "GC overhead limit exceeded." ですか...FAILED: out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/with-local/classes.dex/bin/bash out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/with-local/classes.dex.rspOut of memory error (version 1.3-rc7 'Douarn' (445000 d7be3910514558d6715ce455ce0861ae2f56925a by android-jack-team@google.com)).GC overhead limit exceeded.Try increasing heap size with java option '-Xmx<size>'.Warning: This may have produced partial or corrupted output.[ 2% 310/13030] //art/runtime:libartd clang++ parsed_options.cc [linux]ninja: build stopped: subcommand failed.11:53:25 ninja failed with: exit status 1-Xmxオプションを試してみてと有るので、ヒントを手掛かりに色々と検索して、try and error を繰り返す。pkill java で(あるいは昔ながらの手法通り ps auxww | grep java で PID を検索して kill $PID で) make が終了した後も残存している java process を終了して、次の様に _JAVA_OPTIONS 経由で java の heap 量と Garbage Collection (GC) 方針を設定した。export _JAVA_OPTIONS=-Xmx4400m -XX:ConcGCThreads=2 -XX:+AggressiveHeap -XX:-UseGCOverheadLimit -XX:+UseParallelGClunch aosp_x86-eng; make -j 4 で 03:55:02 でコンパイルが終わる。java process は最大 RSS(実メモリ使用量) 5Gibyte 程、SWAP 最大使用量は約 5Gibyte だった。4400Mibyte と指定したのに 5Gibyte を使用するのは謎だな。#### build completed successfully (03:55:02 (hh:mm:ss)) ####非力な CPU なりのコンパイル時間だ。GC で大幅に構築時間が延びずに済んだ。SWAP を / (binary と data) を格納したハードディスクと別にしていたのが良かったかもしれない。_JAVA_OPTIONS の指定が有ると android studio が起動できなくなった。studio.sh を修正して _JAVA_OPTIONS を export -n _JAVA_OPTIONS で削除するのが簡単だろう。それにしても、5Gibyte のメモリを消費して、2 thread で GC して、java の言語設計と実行環境設計は何か間違っているような... 1995 年に発表された当時、メモリは「高級」ワークステーションで 128Mi ~ 256Mibyte だった。メモリリッチな時代になれば「java のメモリ食いは問題にならなくなるさ」という話だったな。あれから 23 年、もっと酷くなっているのだが...さて、x86 emulator ターゲットの Android ができた。emulator で実行してみる。sse3 が必要とな... Phenom II では実行できないと ... NFS export して別の PC で実行しよう。
2018.05.05
コメント(0)
大規模な make を実施したくなった。こういう時は新しい PC を調達するのが普通だと思う。そこそこ処理能力が高そうな古いマシンを探す。M2A-VM HDMI, AMD Phenom II X4 945 (4core 3.0GHz), 4Gibyte の構成で暫く稼働していなかった。M2A-VM HDMI を 8Gibyte 構成にした時の dmidecode 出力 と lspci 出力 だ。今時 4 core だ。電力効率が悪い。短期運用だから不問にするか。Lubuntu 16.04 x64 をインストールして、暫く動かしてみる。Lubuntu 16.04 のネットワーク設定がおかしく、繋がらない以外の問題は特に無かった。IPv4 のアドレスが設定されない。下に修正後の /etc/network/interfaces を示す。iface 行に下線を付けた dhcp 部分が manual だった。Live boot では DHCP 構成だったのに、何でインストールは手動設定なんだろう。$ cat /etc/network/interfaces# interfaces(5) file used by ifup(8) and ifdown(8)auto loiface lo inet loopbackauto enp3s0iface enp3s0 inet dhcpauto enp4s0iface enp4s0 inet dhcp暫く動かしてみて問題が無かったので 8Gbyte にメモリを増やした。起動しなくなった。メモリを増やした直後に memtest86+ を実施して PASS している。どうも、MBR を読んだか、読んでその直後辺りで起動処理を続けられなくなった様だ。メモリを増やしただけで MBR かその直後の段階の boot loader が壊れるのか? 4Tbyte の HDD を認識しなくなった?(直前までインストール作業が出来ていたのに?) 原因と結果が結びつかない現象に悩む。色々とやってみた結果を先に言えば、起動 HDD の接続先を PCI express に繋がった Marvell 88SE9123 から 32bit PCI bus に繋がった Silicon Image SiI 3114 に変えたら起動する様になった。チップセットの AMD SB600 に接続した場合も起動せず。どれも BIOS 起動処理段階ではハードディスクを認識して型名を表示できている。容量表示も正しい。うーん、PCI express 接続の SATA コントローラーなのに 4Gibyte より大きい領域が有ると DMA 転送できない? 32bit BUS 接続の SATA コントローラだと bounce buffer 経由の I/O になるよな...遅くなる。ここは「動かない」より「動く」選択だ。「色々とやってみた」内容は、MBR を修復してみる → 同様に起動しない、あるいは grub の rescue prompt が出る。再インストールをしてみる → grub の rescue prompt が出る。再インストールをしたのだ。また設定し直しだな... ところで 8Gibyte でメモリ足りるの?
2018.04.30
コメント(0)
ここ 3 週間ほど riset3v IO DATA mAagicTV GT 番組予約ファイル riset3.ri 表示ツール を作っていた(riset3v.zip ダウンロード一式)。mAgicTV GT の録画失敗など色々な事象を何とかしようと、録画予約情報が取得できないか試していた。riset3.ri というファイルに録画予約情報が入っていることが分かってくる。録画開始時刻が取得できれば、録画開始前に色々と仕込める。できたツールで次の様な情報が取得できるようになった。riset3v -f "%s,%e,%N,%T,%t" -t "%Y/%m/%d %H:%M:%S"2018/03/30 07:00:00,2018/03/30 07:45:00,0x7fe0,0x7fe0,"NHKニュース おはよう日本[字]"2018/03/30 10:15:00,2018/03/30 10:25:00,0x7fe1,0x7fe1,"おとなの基礎英語[終] Session96「Review Test」"riset3v -f "%s,%e,%N,%T,%t" -t "%s"1522360800,1522363500,0x7fe0,0x7fe0,"NHKニュース おはよう日本[字]"1522372500,1522373100,0x7fe1,0x7fe1,"おとなの基礎英語[終] Session96「Review Test」"riset3.ri には録画失敗分も含まれている。再放送に備えるような情報が入っている様子。フィルターして整理する必要があることも分かった。ツールには C 言語で書いたソースコードも付けた。Visual Studio Community で構築できる様にするには必要な条件だ。手元では Visual Studio, Embarcadero C++, cygwin GCC, Linux GCC で構築できている。放送局を 16 進数では無く、愛称で表示できるようにとか、色々と改良点はある。録画時刻を知るのが目的なので今のところ機能実装は見送っている。さて、「録画開始前の仕込」を色々と試してみるか。
2018.03.31
コメント(0)
Shift JIS コードで文字列を保存してあるバイナリファイルを読み取るちょっとしたツールを作り始めた。うーん、C 言語で作ろうか。実行環境は Windows10 64bit だ。昔の 16bit DOS コンパイラ Turbo C を引っ張り出す。「64 ビットバージョンの Windows での非互換のため、プログラムまたは機能である ~(以下略)」、「このバージョンの D:\TURBO\TC\TCC.EXE は、実行中の Windows のバージョンと互換性がありません。コンピューターのシステム情報を確認してから、ソフトウェアの発行元に問い合わせてください。」... そうですか。16bit コードは動かないですか。Shift-JIS 関連の関数は実装することにして、実装結果をテストするために 16bit 環境は必要だ。dosbox を使うことにした。Windows, Linux どちらでも動く。Linux で動かすことを選択する。$ sudo apt-get install dosboxインストールするとデスクトップ環境メニューの Games/DOSBox Emulator にインストールされる。ゲームですか...以下の流れは色々と試行錯誤して、それなりにすぐ使える手順として整理したものだ。まず、dosbox 内でドライブとして使うディレクトリを作る。MS-DOS でいう SUBST コマンドでドライブとして認識させるディレクトリだ。ここでは ~/dosbox とする。$ mkdir ~/dosbox~/dosbox 以下に使いたいファイルをコピーする。ファイル名は 8.3 規則に従って無くても良い。従っていない場合、LFN(VFAT) - SFN(FAT) 互換の様にファイル名が短縮される。$ dosbox最低限のツールは Z ドライブに入っている。COMMAND.COM を代表とする各ツールのバイナリは特殊な命令列を emulator call にしている様子。懐かしい COMMAND.COM 似のプロンプトで、ディレクトリをマウントする。ドライブ Z は特殊な Read Only drive の様だ。Z:\>MOUNT C ~/dosbox毎回面倒であれば ~/.dosbox/dosbox-0.74.conf の中の [autoexec] セクションで AUTOEXEC.BAT の様に書けば良い。実行ファイルパスも SET PATH=Z:\;C:\TOOLS の様に書ける。Linux 環境で更新したファイルを dosbox 環境に同期するには、RESCAN を使う。Z:\>RESCANソースコード管理は Git で、コンパイルは dosbox でという作業環境も少しの手間さえ掛ければ可能だ。Mouse Capture/Release をする [Ctrl]-[F10] (Ctrl は右の方が良いかも) を覚えればほぼ困らないはず。tcc 2.01 on dosboxTurbo Debugger (Borland C++ 5.0) on dosbox
2018.03.14
コメント(0)
認識できずに全損したハードディスクを分解してみることにした。分解途中で付けた傷以外にプラッタに目立った傷はなかった。ヘッドとボイスコイルモーターに繋がるコネクタと接触する基板の配線露出部に腐食が見られた。下の画像は分解がおおよそ終わったところ。機構部を分解する前に、基板の付け直しをすれば、もしかしたら復活したかも。確認事項、手順、試みるべきことに反省点が残る。分解途中の画像を見て行く、プラッタには目立った傷が無い。よく見ると傷、指紋、埃も見えるこれらは分解作業で付けたものだ。よく見られるような円環の傷もないし、ヘッドをシークさせた時に付く半月状の傷もない。表から見える基板のメッキ部分がくすんだり酸化か何かで変色していることにもう少し注意深くなる必要が有った。これだけの変色が見られるのだから、内側に有るヘッドとボイスコイルモーターに繋がるコネクタ接触部とスピンドルモーターに繋がる接触部も同様な状況になっていると考えるべきだった。基板の内側、部品面を見てみる。左上のヘッドとボイスコイルモーターに接続する配線の接触部には変色が見られた。接触痕が付いているので基板の付け直しをしても、何も変わらなかった可能性もある。目視では接触痕も酸化していた様には見えなかった。基板を外して付け直す、外したついでに接触部に着いた酸化膜の除去程度なら、実施しても認識しないという状況はほぼ変わらないか、良くなるかのどちらかしかないはず。ヘックス・ドライバでできる作業なので難度も低い。SATA コネクタ、電源コネクタ付け直し、ホスト側コントローラ変更で好転しないなら、次に試すべき作業は、ドライブの制御基板付け直しだったのかも。基板材料(メッキ)を選んだり、ケーブルの接触構造を選択するとき、メーカーでは十分にテストしたんだよな。
2018.03.08
コメント(0)
bash script で CGI を書いて指定時刻に Wake On LAN をする自宅内サービスを作っている。そういえば昔shellshockなんていう話も有った。一応サーバーの bash を確認して問題を起こさないことを確かめる。働いていた時に bash で CGI を書いていると言ったら、「どうやって?」て言われたっけ?環境変数 QUERY_STRING から CGI 変数(正確な言い方はなんだっけ?)を取り出せる仕掛けを作れば、コマンドラインから起動するスクリプトと同じような感覚で書ける。次のコード片は CGI 変数を取り出す部分だ。書いた CGI より抜粋する。(2018/4/5 追記 余計な key="$1" を削除)#!/bin/bash -f# wakeup host at specified time.# CGI vars:# hostname=HostName# wake_second=UnixTimeSecond# wake_time=HumanReadableDateTimefunction uri_unescape() { local b c i l b="" while read do i=0 l=${#REPLY} while (( ${i} < ${l} )) do c=${REPLY:${i}:1} case ${#b} in (0) case "${c}" in (+) echo -n " " ;; (%) b='\x' ;; (*) echo -n "${c}" ;; esac ;; (2) b="${b}${c}" ;; (3) b="${b}${c}" printf "%b" "${b}" b="" ;; (*) echo -n "${c}" b="" ;; esac i=$(( ${i} + 1 )) done done}function query_var() { echo ${QUERY_STRING} | \ tr '&' '\n' | \ grep "^$1=" | \ sed -n -e "s/^$1=//p" | \ uri_unescape}shell_operators='$|&;<>(){}[]`'wake_host=`query_var hostname | tr -dc '[:alnum:]._-' `wake_second=`query_var wake_second | tr -dc '+-[:digit:]'`wake_time=`query_var wake_time | tr -d "${shell_operators}"`あまり込み入ったトリックは使わず、平凡に書いた。uri_unescape が % や + で escape された文字を decode する処理、query_var が CGI 変数名を指定して、値を取り出す処理になる。perl を使えば簡単では?... まあそうなんだ。大よそ動いている指定時刻に Wake On LAN する CGI scriptはまだ改良の余地がある。マシンが稼働していなくても動くように hostname → MAC address の辞書を持たせる。form を付けるcancel 機能を付ける。DoS に耐性を持たせる。仮稼働中をさせて実用に支障が無いか見つつ改良方針を考えないと。本当は RTC の wake 機能を使えば十分なはず。Windows ならタスクスケジューラーだし、Linux なら /sys/class/rtc/rtc0/wakealarm だ。たまに不発になるときの bad knowhow 的な CGI なんだよな...
2018.03.07
コメント(0)
2018/3/5 追記 webdav 構築作業記録のページへ3/3(金) に実家に行って、親の PC と 野良 webdav server の接続試験をする。webdav server を保存先にしてファイルバックアップ作業を始めた。なかなか終わらない。Windows10 のタスクマネージャーにあるパフォーマンス表示を眺めてみると平均で 10Mbits/sec 程度の速度だ。構内ネットが 10BaseT とか 10Base5 が主流だった 25 年前は高速に感じたんだよなぁ。何処で律速されているのだろうか?自宅とプロバイダーの通信速度測定サイト スピードチェック(通信速度測定):光ファイバー auひかり 感の速度を調べると、次の様な結果になった。==KDDI スピードCheck [2018/03/04 00:56:03] ==ご利用サービス:auひかりマンション(タイプV/E/F/都市機構))プロバイダ:au one net接続方法:有線LAN(ケーブル接続)測定地域:千葉県東部(ここには郵便番号が表示されている)測定サーバ:東京 サーバ下り速度:48.01Mbps上り速度:11.72Mbpshttp://spchk.kddi.com/==============================実家と自宅は /18 (16384-2 = 16382 台 だったかな) の同じサブネットなので結果は同じだろう。途中まで光回線でメーターボックス内で VDSL に変換して繋がっている。VDSL 接続としては妥当な速度だ。自宅内で仮想 Windows10 マシン から webdav server 間の速度は 50Mbits/sec 出ている。webdav server も仮想マシンだし、webdav server で共有しているストレージは NFS で別の server が持っているストレージを mount している。複雑な構成なりの速度だ。光-VDSL 回線で律速されている。パソコンの使用感に影響が出るのは困る。少しずつバックアップを進めて、大量転送が続かないようにするか。え、見通しで窓 to 窓の無線 LAN とか、外付けハードディスクを抱えて持って行って、バックアップした方が早いかもって?
2018.03.04
コメント(0)
webdav server を動かし始めた。作業の手順が多いのでwebdav server 設定作業記録を残すことにした。今回設定作業をするのは 2 回目だ。すっかり忘れていたので色々と手間取り、再学習することも多かった。サービスは実家向けなので大々的にみんなに使ってもらう程の設定はしていない。サーバー証明書はいわゆる「おれおれ証明書」だ。実家側で webdav server にバックアップを転送する仕掛けを充実させる必要がある。これからの課題だ。自営の野良サーバーも https プロトコルをサービスするように機能強化する必要がある。Google (chrome) 様のご意向に従わないと。
2018.02.27
コメント(0)
Linux マシンに入れていた 1Tbyte のハードディスク WD10EZRX が全損してしまった。認識しない。2/23(金) の時点で全損状態が始まっていた。始まったときは仮想マシンのウインドウにキーボード押し、マウスクリックのイベントを送っても反応せず、シャットダウンもできない状態になっていた。2/24(土) の時点で電源 Off から On にした時にいわゆる小人さんのテニス音がカッタッ、カッタッと鳴っていた。Indentify ができず認識できない。別の SATA I/F, USB-SATA 変換を通しても同様だったので、プラッタかヘッド損傷だろう。何か擦り付けるような、シャラシャラした音が混じっている。1Tbyte のハードディスクが全損、中に入っていたのは主に仮想マシンだ。71 台喪失する。内訳は、インストールだけ試した: 35 台scankeylx のテストベクタ: 19 台テスト作業のため使用: 10 台開発環境: 5 台実マシンの複製: 1 台仮想マシンのバックアップ目的クローン: 1 台「インストールだけ試した」というのかほぼ半分、「テストベクタ」は一部コピーが存在するはず、「開発環境」はソースコードは git リポジトリにあるので復旧は可能(git 管理下に無かった作業記録は喪失)。認識できなくなる前に気づけなかったのが惜しい。仮想マシンが応答しない状態になる前に、いつもと違う挙動を感じる事が無かった。代わりに使おうとした WD20EARS も使用前に Current_Pending_Sector が Raw 値で 1465、Zero fill した後、全面読み出しを途中までした段階で 437 となり、Reallocation 不可かつ広範囲に損傷有りの状態だった。転用や取り外しを経る途中でフォーマットされていた状態だった。WD20EARS の方はデータ喪失の実害はなし。3 日で合計 3Tbyte の HDD を喪失(あるいは喪失状態が判明)、仕事をやめる前に買った HDD も大分減ったな。
2018.02.25
コメント(0)
Windows10 1709 Fall Creators Update をした後不調になったノート PC が有った。スリープ、休止状態にすると、画面が真っ黒になり電源が入ったままになった。この状態で復帰しない。暫くはシャットダウンを使っていた。色々と弄っているうちに機内モードに入った後、機内モードを解除できない事に気づく。思い当たることがあった USB Wireless LAN adapter Logitec LAN-W150/U2 のドライバが Mediatek から供給されたドライバだと起きることだった。デバイスマネージャーで LAN-W150/U2 のドライバを見てみると Mediatek 供給だった。Update でドライバが更新されてしまった。Microsoft が供給している 2015/04/21 作成のドライバに戻した。機内モードの動作は正常、スリープ、休止状態も問題なし、復帰後も普通に使える。問題を起こすドライバは Fall Creators Update に含まれていない筈なんだけどな。Windows10 で WHQL の活動上手くいっているのかな?
2018.02.23
コメント(0)
VirtualBox 内で linux を使い /dev/hpet を開いて割り込みが入る (ioctl(HPET_IE_ON), poll 待ちが進む または signal が入る) 様にしても、割り込みが入らない状態になる問題を調べていた。原因は VirtualBox の HPET エミュレータが Level Sense Trigger Mode だと割り込みを発生しないことに有った。/src/VBox/Devices/PC/DevHPET.cpp:hpetR3TimerUpdateIrq() (リンク先は行番号なので多少前後するかもしれない) が割り込み発生処理をエミュレートする関数だと思われる。ソースを読むと Edge Trigger Mode で使うと割り込みが発生するように読める。Linux kernel の /dev/hpet ドライバ drivers/char/hpet.c:hpet_timer_set_irq() を読むと Level Sense Trigger Mode を設定している。"we prefer level triggered mode" と有るので好ましいと思って実装したのだろう。Dirty Hack をするならこの辺を Edge Trigger Mode を使うように書き換えれば、本当か確認できるはず。環境適応性を高めて書き換えようとすると厄介だ。ACPI 構成情報からくる(かもしれない)推奨される割り込み設定、動的に IRQ line を探す処理は独占的に使用できる IRQ line を見つける処理に書き換える。module parameter 指定で従来互換(強制 Level Trigger)、強制 Edge Trigger を選べるようにする。え? VirtualBox を修正するのが正しいって?
2018.01.17
コメント(0)
Raspberry pi 3 上で htags (GNU GLOBAL) を使ってソースコードから生成した web ページをそのまま web サーバーにコピーして使おうとした。CGI に関数名を入れて検索したら Pattern not found となった。原因は GNU global のバージョン違いだった。Raspberry pi 3 上の global は 6.5.6、web サーバー上の global は 5.7.1 だった。web サーバー上で GNU GLOBAL 6.6.1 をソースコードから構築し、HTML/cgi-bin/global.cgi と HTML/cgi-bin/completion.cgi の $global_command を構築した global の path に変更して解決する。気づきの始めは gtags で生成するファイルが変わっていたことだ。古い gtags は GPATH, GRTAGS, GSYMS, GTAGS の 4 つの生成していた。対して global 6.5.6 は GPATH, GRTAGS, GTAGS の 3 つのファイルファイルを生成する。古い gtags と互換形式を生成するようなオプションは見つからなかった。サーバー上の GNU GLOBAL を新しくする必要がある。package のバージョンは古いままだったのでソースから構築することにした。Getting GLOBALのページから tar.gz でまとめられたソースコードをダウンロードして展開する。global 6.6.1 をホームディレクトリ以下にインストールする作業を次の様に行った。$ cd work_base_directory$ tar zxvf down_loaded_directory/global-6.6.1.tar.gz$ cd global-6.6.1$ ./configure --prefix $HOME/global-6.6.1$ mkdir $HOME/global-6.6.1$ make -j 4$ make installCGI は HTML/cgi-bin/global.cgi と HTML/cgi-bin/completion.cgi の次の部分を編集して、先にインストールした global の full path にする(例えば $HOME を展開して /home/furuta/global-6.6.1/bin/global の様に書き直す)。my $global_command = '/usr/bin/global';新しい GNU GLOBAL は htags に --auto-completion を付けて web ページを生成すると検索テキストボックスで自動補完が使える。詳細は --auto-completion あるいは --suggest2 オプションの説明にある。GNU GLOBAL がバージョンアップした! オートコンプリートが使えるようになった! サーバーのキメラ化が進んだ!
2018.01.14
コメント(0)
引っ越しの荷物を開けて RaspberryPi3 を再稼働させる。去年の 12月末頃にroot filesystem を格納(リンク先は格納手順)していたハードディスク WD7500BPVT に不良ブロックが「広がっている」ことが分かっていた。「広がっている」というのには背景がある。RaspberryPi3 に接続した時に不良ブロックがあったことが分かっていた。不良ブロックの範囲が小さかったので、不良部分を避けるようにパーティションを切って使っていた。年が明けて RaspberryPi3 と周辺機器を接続して再起動してもエラー多発で起動しない状態を調べ続けていた。ハードディスクから採取可能な範囲でファイルをバックアップ、自作のツールで不良ブロック抽出、不良ブロック狙い撃ちで zero fill、smartctl をしても不良ブロックは殆ど減らず、全領域で zero fill して、smartctl で不良ブロック再割り当て状況を見てみた。 Reallocated_Sector_Ct = 531, Current_Pending_Sector = 65213 となった。数値から見て zero fill で交替処理は絶望的な状況だと分かる。ID#ATTRIBUTE_NAMEFLAGVALUEWORSTTHRESHTYPEUPDATEDWHEN_FAILEDRAW_VALUE1Raw_Read_Error_Rate0x002f198198051Pre-failAlways-38843Spin_Up_Time0x0027201178021Pre-failAlways-9414Start_Stop_Count0x0032001001000Old_ageAlways-6481315Reallocated_Sector_Ct0x0033133133140Pre-failAlwaysFAILING_NOW5317Seek_Error_Rate0x002e200200000Old_ageAlways-09Power_On_Hours0x0032052052000Old_ageAlways-3528710Spin_Retry_Count0x0032100100000Old_ageAlways-011Calibration_Retry_Count0x0032100100000Old_ageAlways-012Power_Cycle_Count0x0032100100000Old_ageAlways-174192Power-Off_Retract_Count0x0032200200000Old_ageAlways-113193Load_Cycle_Count0x0032001001000Old_ageAlways-796096194Temperature_Celsius0x0022124088000Old_ageAlways-23196Reallocated_Event_Count0x0032001001000Old_ageAlways-267197Current_Pending_Sector0x0032001001000Old_ageAlways-65213198Offline_Uncorrectable0x0030100253000Old_ageOffline-0199UDMA_CRC_Error_Count0x0032200200000Old_ageAlways-0200Multi_Zone_Error_Rate0x0008100253000Old_ageOffline-0zero fill 後に残った不良ブロックのマップを見てみた。不良ブロックを避けてパーティションを切って使うと全容量 750Gbyte の 1/3 程度 (250Gbyte) しか使えず、殆どメリットが無いことが分かる。連続した領域では無いので mount の設定も複雑になる。LVM (Logical Volume Manager) あるいは e2fsck -l bad_blocks_to_add_file を使ってまで使う?不良ブロックを避けて使っても、不良ブロックは広がり、使っている領域を壊していくのだ。別のハードディスク WD5000BEVT を使うことにした。野良サーバーの副として稼働していたマシンがあった。既に新しいマシンへ交代していて、万が一と思って残していた。このマシンからハードディスクを取り出す。ああ、こいつも既に傷ついているのか、Reallocated_Sector_Ct = 4, Reallocated_Event_Count = 1, Current_Pending_Sector = 6 だった。4.87 年稼働して無傷を期待するのが無理なのかもしれない。ID#ATTRIBUTE_NAMEFLAGVALUEWORSTTHRESHTYPEUPDATEDWHEN_FAILEDRAW_VALUE1Raw_Read_Error_Rate0x002f200200051Pre-failAlways-703Spin_Up_Time0x0027181176021Pre-failAlways-19414Start_Stop_Count0x0032099099000Old_ageAlways-12405Reallocated_Sector_Ct0x0033199199140Pre-failAlways-47Seek_Error_Rate0x002e100253000Old_ageAlways-09Power_On_Hours0x0032042042000Old_ageAlways-4263310Spin_Retry_Count0x0033100100051Pre-failAlways-011Calibration_Retry_Count0x0032100100000Old_ageAlways-012Power_Cycle_Count0x0032100100000Old_ageAlways-166192Power-Off_Retract_Count0x0032200200000Old_ageAlways-89193Load_Cycle_Count0x0032015015000Old_ageAlways-556130194Temperature_Celsius0x0022121093000Old_ageAlways-26196Reallocated_Event_Count0x0032199197000Old_ageAlways-1197Current_Pending_Sector0x0032200200000Old_ageAlways-6198Offline_Uncorrectable0x0030100253000Old_ageOffline-0199UDMA_CRC_Error_Count0x0032200200000Old_ageAlways-0200Multi_Zone_Error_Rate0x0009100253051Pre-failOffline-0多分最後のお勤めになるだろう。必要なファイルをバックアップした後(多分マシンを交代させるときに既に実施済みなはず)、Zero Fill をして交替処理を促してみる。Reallocated_Sector_Ct =4, Reallocated_Event_Count = 1、Current_Pending_Sector = 0 になった。あれ?交替せずに済んだの?ID#ATTRIBUTE_NAMEFLAGVALUEWORSTTHRESHTYPEUPDATEDWHEN_FAILEDRAW_VALUE1Raw_Read_Error_Rate0x002f200200051Pre-failAlways-703Spin_Up_Time0x0027181176021Pre-failAlways-19414Start_Stop_Count0x0032099099000Old_ageAlways-12405Reallocated_Sector_Ct0x0033199199140Pre-failAlways-47Seek_Error_Rate0x002e200200000Old_ageAlways-09Power_On_Hours0x0032042042000Old_ageAlways-4263710Spin_Retry_Count0x0033100100051Pre-failAlways-011Calibration_Retry_Count0x0032100100000Old_ageAlways-012Power_Cycle_Count0x0032100100000Old_ageAlways-166192Power-Off_Retract_Count0x0032200200000Old_ageAlways-89193Load_Cycle_Count0x0032015015000Old_ageAlways-556130194Temperature_Celsius0x0022123093000Old_ageAlways-24196Reallocated_Event_Count0x0032199197000Old_ageAlways-1197Current_Pending_Sector0x0032200200000Old_ageAlways-0198Offline_Uncorrectable0x0030100253000Old_ageOffline-0199UDMA_CRC_Error_Count0x0032200200000Old_ageAlways-0200Multi_Zone_Error_Rate0x0009100253051Pre-failOffline-0パーティションを切り直して、最新の RaspberryPi3 のイメージをコピーする。やり方は前と変わらなかった。ハードディスク上のパーティションを root filesystem として動き出した。副サーバーで動いていたときの音と変わらないな。可変回転速なのか、アクセスの前後で少し「コー」というこもった音がする。お金に余裕があった頃は、ポンと代わりのハードディスクを買っていたんだよな。
2018.01.07
コメント(0)
実家の Fujitsu LIFEBOOK AH45/DC の SD カードリーダーが使えないので見て欲しいと話があった。見てみると「ディレクトリ名が無効です」とエラーダイアログが出ていた。カードリーダーのドライバを O2Micro Integrated MMC/SD controller から 標準の SD ストレージクラスコントローラー に変更して使えるようになった。変更した後何故か互換性があるドライバに O2Micro Integrated MMC/SD controller が出なくなった。動かないドライバなので気にしないことにする。次のスクリーンショットはわざわざ互換性のチェックボックスを消して出している。始めは少し挿し具合が悪い状態で出てきた「フォーマットしますか?」ダイアログに「はい」と答えてしまったのかと思っていた。手順を再現してもらって「ディレクトリが無効です」と出てきたので、問題の原因を探ることにした。(1) SD カードが壊れた(物理・論理)、(2) カードスロットの接触不良、(3) ドライバまたはファイルシステムに近いところでソフトの不具合SD カードの内容を読み出せるなら、別のストレージへ保存することを優先する。(1) かどうかも見極める必要がある。実家に置いてある PC 周辺機器の中から SDHC に対応している USB 接続のカードリーダーを見つける。USB カードリーダーを使って読み出すことができた。(1) の可能性は無くなった。同時に持ち帰って「ラボ」でブロックレベルでのクローニング、仮想ドライブでの削除ファイルの復活はしなくても良くなった。(2),(3) の可能性を当る事にする。スロットの目視では汚れやピン曲がりは見つからず、スロットに差して抜いたカードの電極にも汚れや位置がずれている接触痕はなし、手持ちの SD カードで試してみても、ダイアログは同様に「ディレクトリが無効です」で、抜いた後の電極に異常は認められなかった。(3) かなぁ、富士通のサイトに行って ドライバを入手してインストールしてみる。対象機種は違うし、どう見てもサポート範囲は Windows7 まで(良くて Windows8.1までだ)。結局は解決せず。SD カード/eMMC メモリには SD Host Controllerという仕様が定められていて、いわゆる標準のドライバが「ハードウエアが仕様に従って作られていれば」使える。O2Micro のドライバのままでは使えない可能性が高い。ドライバを入れ替えてみることにした。ドライバを入れ替えた後、SD カードは普通に読めるようになった。問題を見つけたカードも自分手持ちのカードも普通に読める。書き込みの確認ついでにスクリーンショットも保存できた。まぁ、良くなったのかな。自動再生アプリを Windows7/8 から使っているアプリに戻して操作に戸惑わないようにした。Windows 自身が「常に選択した動作をする」と自分で言っているのに何でFall Creators Update は変えるのかなぁ。Fall Creators Update はスタートメニューから Control Panel のショートカットを消す、それでまず必要になるのか Control Panel の Device Manager だ。なるほど奈落の底に(fall した)沈めた Device Manager を探しに行く Quest Game を作ったのか。
2018.01.04
コメント(0)
自分の所に届く spam mail 楽天カード カード利用のお知らせが大分手が込んできている。1 週間ほど前は To に複数のメールアドレスが並びいかにも spam な雰囲気を出していた。ここ 1 週間で届く同様のメールは To が自分 1 人になった。楽天カードのお知らせページにある「宛先に自分以外の複数の受信者(メールアドレス)が入っているメールは開かない。」という注意条件は満たさなくなった。今はリンク先を Mouse Over で見るといかにも怪しい URL が出てくるので判別できる。楽天カードは作っていないので、本物のメールがどうなっているかはよく分からない。少なくとも署名付きなのだろうか?spam mail の HTML ソースを見ると本物のページを修正して作ったのか、それなりに丁寧な作りだ。おかしい所といえば span lang=EN-US があちこちに見られるところ、<span lang=EN-US><span lang=EN-US>このメ<span lang=EN-US>ールアドレスは配信専用です。お問い合わせの際は</span></span></span> の様に文意と合わない span が有る点だ。フィルターを通して自動生成?署名付きが一番有効な「本物証明」だ。署名を見ない、あるいはもう少し見た目でメールを開いたユーザーが偽物判定できる方法は無いだろうか?ロゴやいくつかの画像リンクは楽天の本物のサーバーを使っている。本物のメールの方に 1x1, 0x0 pixel 画像をちりばめて、不用意にコピーしたりフィルター処理すると穴だらけになる様にする。画像を CGI 経由でアクセスする様にして、path の一部を予測できない UUID にしたり、文字列の一部から写像関数を通して index を計算して、UUID や index に想定以上に多数の IP address からアクセスがあった場合、server から送る画像を「不正メールの透かし」を入れた画像にする。ユーザーが別の経路で入れた「パスワードではない自分専用の符丁(取るに足らない座右の銘や四字熟語)」をメールページの一部に必ず入れるとか。ああ、画像クローラー対策を複雑にしていく web ページとクローラーのイタチごっこを思い出すな...
2017.12.29
コメント(0)
タブレット PC Geanee WDP-081-32G-81BT (Ployer Momo7W 相当?) に Windows10 1709 Fall Creators Update をインストールしようとした。再起動後「インストールを完了できませんでした。このコンピュータに Windows をインストールするには、インストールを再実行して下さい。」という Windows Xp スタイルのダイアログボックスが出てきた。OK を押すと再起動して、同様の状況に戻る。「イヤイヤ、お前さんが自ら Fall Creators Update をインストールしようとしたのではないか...それでこの結果なのか?」途方に暮れる言葉を幾ら発しても状況は変化しない。なんとかする手段を探す。WDP-081-32G-81BT は Ployer Momo7W または Mono8W 相当だということが分かってくる。Momo7W, Mono8W で BIOS あるいは UEFI 起動シーケンスに介入、外部メディアから起動から起動する方法を探すことにした。次の図のような構成で、UEFI(BIOS) メニューに介入できることが分かった。用意する機材は次の通りだ。USB OTG Host ケーブルSelf Powered(AC アダプタ付き) USB HUB と USB HUB の上流を接続するケーブルUSB キーボード(なるべく単機能なもの)USB マウスUSB メモリ(8Gbyte 以上, Windows 10 x86(32bit) インストールメディアとして作成しておく)ノート: USB OTG 規格は Host Mode 動作時に HUB を挟むことを想定せずサポートしていない。WDP-081-32G-81BT は Host Mode 動作時にほぼ普通の USB Host として動作可能だと思われる。WDP-081-32G-81BTを十分に充電しておく。操作途中でバッテリー切れになると状況は悪化するだろう。電源 On 時に USB キーボードの [ESC] キーを連打すると、UEFI(BIOS) メニューが現れる。画像はスキャナで撮っているので白黒になっている。"Boot Manager" が 起動デバイスを選択して起動するメニュー、"SCU" がいわゆる BIOS セット・アップに相当する。この 2 つを使用する。実際自分が行った手順は、念のため scankeylxでプロダクトキーをスキャンして採取している。Ubuntu live の起動手順を書くと長くなるので、ここではメモ程度にまとめておく。-- ここから Ubuntu 起動メモ --Universal USB Installer creator で persistent 領域付きで Ubuntu 14.04 x86(32bit) の起動 USB memory 作成SCU メニューから Boot/EFI Device First → Disabled, Boot/Windows8 Fast Boot → Disabled を設定Boot Manager で USB メモリを選択して起動GRUB command prompt で次の通り入力root=(hd0,msdos1)linux /casper/vmlinuz cdrom-detect/try-usb=true persistent ignore_uuid boot=casperinitrd /casper/initrd.lzbootboot コマンド投入直後は 5~10秒 反応が無いboot 中 kernel の stack dump が出る(そのまま続行)stdin: I/O error も無視scan する device は /dev/mmcblk0 途中で止まるかもしれない。なるべく不要な操作はしない。恐らく検索したキーのうち [TH]X19-98868 と (win8-10) が付いたキーがインストールキーUbuntu のインストールは勧めない。タッチパネルドライバ、 無線 LAN ドライバが無い可能性がある。-- ここまで Ubuntu 起動メモ --話を Windows10 修復の手順に戻す。"SCU" メニューから BIOS セット・アップ相当の設定をする。Advanced/USB Configuration 以下は設定を確認するだけで良いはず。XHCI Controller → EnabledxHCI Mode → EnabledUSB2 Link Power Management → EnabledUSB OTG Support → EnabledUSB VBUS → ONUSB Per-Port COntrol → EnabledUSB Port #[0..3] → EnabledBoot 以下は次の様に設定する。ACPI Selection → Acpi 5.0USB Boot → EnabledEFI Device First → DisabledWindows(R) 8 Fast Boot → DisabledTimeout → 2Automatic Failover → EnabledTimeout を大きくすると [ESC] キーに反応して EFI メニューが出るようになりやすくなるはず。設定が済んだら、Exit/Save Changes をする。トップメニューの "Boot Manager" を選択して [Enter] を押して起動する。下の例では真ん中の "EFI USB Device (TOSHIBA TransMemory-Mx) だ。USB Memory から Windows10 インストーラーが起動する。"トラブルシューティング" を選択して続行する。詳細オプションに進むので 一番下のテキストだけある "その他の修復オプションを表示" を選択して続行する。ノート: Fall Creators Update は自動的に復元ポイントを設定しないので「システムの復元」は使えない。もし、用心して Fall Creators Update を実施する前に復元ポイントを設定しているならば、「システムの復元」の方が良い回復手段だろう。"以前のバージョンに戻す" を選択して続行する。"Windows 10" を選択して続行する。この選択で Windows10 1511 に戻る。ダイアログボタンの "以前のバージョンに戻す" をクリックして最終確認となる。10 分も待たずに戻す処理は終了した。再起動時にキーボード、マウス、USB メモリは繋がったままで良い。再起動が上手くいったところで、USB OTG Host ケーブルを外して充電するためのUSB ケーブル接続に戻すのが良いだろう。再起動すると Windows 10 1511 に戻っていた。なるほど Fall Creator とは Tablet PC を文鎮化して Fall するということか。
2017.12.28
コメント(0)
2019.10.24 追記 玄人志向のサイトに ファームウエアアップデートのお知らせが出ています。v69.02.00.01 から v69.02.00.03 にバージョンアップする様です。ハードディスクケース 玄人志向 GW3.5AA-SUP3/MB を使って外部ドライブを Linux PC に接続してバックアップ先として運用していた。引っ越し後バックアップが進んでいないことに気づく。最新の JMS567 Firmware を書き込んでハードディスクケースの問題は解消した。Update 後、アクセスランプの点き方が変わった感がある。バックアップ元の Windows10 側で使っていた Real Sync 1.93 がエラーで止まっていたので Real Sync の問題として考えていた。何回試してもエラーになるので Linux PC 側で様子を見ることにした。Linux 側で dmesg を見てみるとブロック破損の様な記録だった。ドライブを壊したのかと思い、中に詰めるドライブを換えた。これもエラーでアクセスできない。引っ越しで 2 台壊した? それにしては変だ。3 台目も同様な現象だった。色々と試すうちにハードディスクケースが共通の問題を起こしているように思えた。エラーログを冷静に読み直してみる。コントローラ不調、SATA ケーブルか両端の PHY で問題が有っても出そうなエラー出力だ。コントローラを確認する。Jmicron JMS567 だった。うーん、Jmicron 製チップは壊れたり、不調だったり、いい思い出が無い。バックアップ先に使うハードディスクを収めるケースは Asmedia 製チップを使ったものに換えた。使えない PC 周辺パーツが増えるのか... JMS567 で検索しているうちにファーム書き換えで問題が解消しそうなことが分かってきた。ケースをゴミにする前に試すことにする。チップに書いてある Date Code は 1634、Firmware のリリース年月日は 2016/9/21 だ。ほぼ最新なのでは?と思いつつ、Firmware update をする。Updater が exe なので怪しい挙動をしても良い PC も用意した。Update をしてみると元々の Firmware version は 69.02.00.01 だった。基板に貼られたシールにも同じ値が書かれている。書き込もうとする Firmware は 138.01.00.01 だ。書き換えて書き込み負荷試験をする。dmesg にハードディスク・ケース由来の異常な記録は残らずに動作した。アクセスランプの点き方が変わったような気がする。アクセス中は一定間隔で点滅する。ようやくバックアップ先が安定運用に入る。
2017.12.24
コメント(0)
実家の PC で Windows 10 1709 fall creators update のダウンロードとインストールが始まって失敗していた。"your device needs the latest security updates" というタイトルのダイアログが表示される状態が続いているとのことだった。2017.12.25 別のシステムでスクリーンの scan ができたので貼り付け(白黒)Insider program もあるし 9 月から始まった update のはずなのに各国語のダイアログを用意しない状況で続けているの? Microsoft はどう言う判断で Go サインを出しているのだろう。「設定-更新とセキュリティ-更新プログラムのインストール履歴を表示」で失敗している update を表示して手動でインストールしていく。これで進むかと思ったら "Windows 10 1709 fall creators update" のインストールで 0x80070652 エラーが出た。ああ、最近blog のアクセスが増えている理由なんだ。同じように Windows Defender でフルスキャンを始める(そう言えば Windows10 1709 で UI が変わっている)。もう夜 22 ~ 23 時頃になっていた。スキャンが終わるまで長いなーと思っていたら、裏で "fall creators update" が進行していたのかスキャン途中で「再起動をしますか?」と出てきた。え? update して平気になったの?再起動後 Windows10 1709 に update されていた。色々な設定もリセットされていた。なんというか update というよりはアプリを残したままの再インストールに近い。目について不便な設定を元に戻した。終わってみれば深夜 1 時、体が落ちそうだった。
2017.12.20
コメント(0)
au から VDSL モデム返却の手続きを進めるよう通知がきた。着払いの発送伝票付きだ。返却が必要なのは VDSL モデム、VDSL モデムの AC アダプタ、ルーター だ。付属していた 電話回線ケーブル一式、電話回線スプリッタ(多分ただの分岐)、フィルタ、LAN ケーブルは返却不要と書いてあった。ケーブル類は引っ越しの時に他と混ぜてしまったので、区別か付かなくなっていた。返しようが無かったので助かる。同一契約を継続だったんだよな。古いルーターは Wireless LAN 機能が付いているし、使えていた。新しいルーターにはそれが無い(機能が塞がれている)。確か自分で古いルーターに Wireless LAN カードを差し込んだんだっけ?どうしたかは記憶が不確かだ。今時 PCMCIA の LAN カードが有っても使い道が無いか。Wireless LAN カードも一緒に返却することにした。VDSL モデムは製造から 11 年経過、部品の経年劣化を考えると再利用は多分ない。
2017.12.12
コメント(0)
au からレンタルされた Aterm BL902HW を電話回線に接続して有線 LAN でノート PC と仮接続して設定を始めた。無線 LAN 設定をしようとすると、「無線LANサービスを契約している場合に、選択できます。」現在の状態を見ると「無線LAN未契約」と出てきた。契約書類を見直して見る。平行して有線 LAN 接続のノート PC で au のサイトに行って無線 LAN 契約をする方法を探す。どうも 月 500 円の契約らしい。恐らく不揮発性メモリに「有効/無効」フラグが有るのか、au のサーバーと通信して「有効/無効」を決めているらしい。引っ越して来てすぐに使うつもりがなかった 無線 LAN アクセスポイントとして使える機器を探すことにした。こうやって箱の開梱順が狂い混乱が始まる。Corega CG-WLBARGM がすぐに見つかる。2 - 3 時間ほど費やして不調だと分かる。不調だから実家から引き上げた。引き上げたときに修理した所以外にも問題箇所が有りそうだ。半田付け作業場は開所していない。追加修理をするのは無理だ。NEC Aterm WR8170N を見つける。これを Access Point Mode で使うことにした。マニュアルを見つける。AP モードの場合の初期 IP アドレス (192.168.0.211 か 192.168.1.211) を探すのに苦労する。DHCP server を Linux PC で稼働させた後から、不調に気づいた。BL902HW, WR8170N それぞれ DHCP server を止めてある。有線接続の場合は、DHCP が振りだしたアドレスをクライアント PC が貰いネットワーク設定を構成できている。無線接続の場合は DHCP によるネットワーク設定を構成できない。後から分かったことは DHCP server が副(secondary)しか動いていない場合は、無線 LAN 接続の client はネットワークを構成できない問題が発生する。タイミングに起因している問題が起きているのだろうか?Aterm BL902HW のフロントパネルをよく見てみると併設した Wireless AP の無線 Activity ランプと同期して内部で点滅するランプが有ることに気づく。次の画像 12/13 に確認のため撮った画像だ。有線 LAN packet には同期していない。上の画像では分かりにくいので、暗くしてみて撮影する(撮影日は 12/13)。無線 LAN の回路が存在していて、動作もしている。ソフトの設定次第で使えるのかも。隠しコマンドか何かで使えるようになる?
2017.12.10
コメント(0)
引っ越しに伴い www.ftechworks.mydns.jp サーバーを 12/7(木) に停止します。主な影響はこの blog の画像が表示されなくなる商用電源監視が停止するsccankeylx のダウンロードができないです。引っ越しが完了次第再開を予定しています。解消に時間が掛かる技術的障害が無ければ 12/10(日) を目途に再開します。ご不便かと思いますが、ご容赦願います。
2017.12.06
コメント(0)
パソコンを開き GoogleMap を見る。何故か自分の位置が正確に表示されていることに気づく、PC に GPS アンテナは付いていない。PC のブラウザは Google アカウントにログインした状態だ。どうしてなのかしばらく考えてみた。身に付けている Android スマートホンの GPS 情報から自分のアカウントのステータスとして一元管理されていると気づく。Google Map のヘルプを見ると確かにそう書かれていた。同一アカウントであるスマホの位置情報は PC を使っている人間の位置情報だという推測は概ね正しい。スマホの電池が残っていて、電波が届けば(送れれば)、どこに忘れたか Google Map に表示されるのか。
2017.11.17
コメント(0)
Linux Kernel に HPET (High Precision Event Timer) のドライバがある(リンク先は少し古い kernel 4.1.27 の source だ)。ドキュメントはサンプル兼テストアプリケーションhpet_sample.c だ。Kernel 内のドライバを読み進めていく中で、HPET API の仕様を読解していった。HPET API に読んだ内容を書き留めておくことにした。下手な英語だし、何度か読み直してみて内容も修正が必要だろう。日本語で書けば良かったんだよな... きっと。リンクで辿れるその他、雑多なページは全部日本語なのだし。これらも書きかけだ。何時になったら書き切れるのやら...
2017.10.15
コメント(0)
母親の Windows10 PC をいじっていたら ATTEMPTED_SWITCH_FROM_DPC でブルースクリンなった。状況を聞いてみると前から発生していたそうだ。前にも見たことがある。ディスク・クローニング・ソフトが無いか探してみる。Acronis True Image Home がインストールされていた。Upgrade 前の Windows 7 で動いていたソフトだ。Acronis True Image Home を削除する。1 週間ほど様子を見てもらうことにした。ブルースクリーンは発生していない。同様の経過は 2 度目だ。Windows7 の時にインストールした Acronis True Image Home が問題を起こしているのか試してみるつもりだったのに忘れていたな...
2017.09.30
コメント(0)
fasync_helper() の使い方を調べていた。Linux Kernel 2.6 向けに書かれた "Linux Device Drivers 3rd" 6.4.1 に "It might appear that we’re done, but there’s still one thing missing." から始まる段落に release call back 時(close 時) に fasync_helper(-1, filp, 0); を呼び出すように書かれている。原文は間接的に scull_p_fasync(-1, filp, 0); と書かれている。Linux Kernel 4.1.27 のソースを読んでみるとそのような記述をしているとすぐ分かるのはpipe.c だけだった。いくつかのドライバを読んでみても同様の記述は見つからない。file system の実装が変わって fasync call back を release call back 前に呼び出すようになったのか?ソースを追ってみることにした。起点はfilp_close()とした。system call の入り口からも近い場所なので system call 側に辿るのも容易だろう。次は fput()、task work が介在 init_task_work(), task_work_add() して ____fput(), __fput() が呼ばれる。__fput() の中で file_operationsの fasync が呼ばれていた。if (unlikely(file->f_flags & FASYNC)) { if (file->f_op->fasync) file->f_op->fasync(-1, file, 0);}すこし後で release を呼び出しているので間違いないだろう。なるほど、kernel 4.1.27 ではドライバ側で fasync_helper(-1, filp, 0); を呼び出さなくても良くなったのか。呼んでも害が無いのは変わらない。
2017.09.22
コメント(0)
ZOTAC GeForce 6100-ITX (nVIDIA NF-MCP61) 上で Linux Kernel 4.1.27 x86_64 を動かし HPET (High Precision Event Timer)の動作を確認していた。Kernel source tree にある hpet_example.cを poll command で動作させる(例えば # ./hpet_example poll /dev/hpet 10 10) と ioctl(HPET_IE_ON) で "I/O Error" (EIO) になる。EIO になることは hpet_example を修正して errno を表示する様にたテストプログラムを使って確かめた。EIO が出た時に同時に記録されたと思われる kernel log を dmesg で確認してみる。次の行が残っていた。hpet: IRQ 31 is not free何か変だ。IRQ 31 なんて有っただろうか? PCI MSI だっけ? /proc/interrupts を読んでみる。$ cat /proc/interrupts CPU0 CPU1 0: 44 0 IO-APIC-edge timer 1: 1 2 IO-APIC-edge i8042 7: 1 0 IO-APIC-edge 8: 0 1 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 12: 2 3 IO-APIC-edge i8042 14: 0 0 IO-APIC-edge pata_amd 15: 0 0 IO-APIC-edge pata_amd 16: 4 726 IO-APIC 16-fasteoi parport0, serial 21: 0 511 IO-APIC 21-fasteoi ehci_hcd:usb1, nvkm 22: 35 371 IO-APIC 22-fasteoi ohci_hcd:usb2, snd_hda_intel 23: 72440 61606 IO-APIC 23-fasteoi sata_nv, sata_nv 27: 2292 373747 PCI-MSI-edge eth0NMI: 12 15 Non-maskable interruptsLOC: 339234 251876 Local timer interruptsSPU: 0 0 Spurious interruptsPMI: 12 15 Performance monitoring interruptsIWI: 0 0 IRQ work interruptsRTR: 0 0 APIC ICR read retriesRES: 315720 325854 Rescheduling interruptsCAL: 434 2201 Function call interruptsTLB: 12820 15322 TLB shootdownsTRM: 0 0 Thermal event interruptsTHR: 0 0 Threshold APIC interruptsMCE: 0 0 Machine check exceptionsMCP: 228 228 Machine check pollsHYP: 0 0 Hypervisor callback interruptsERR: 1MIS: 0先に結論を言えばlinux kernel ソースの drivers/char/hpet.c にパッチを当てて解消した。パッチを当てる前は Reset の初期値のままか BIOS が HPET の "Timer N Configuration and Capabilities Register" の Tn_INT_ROUTE_CNF bit field に設定した Interrupt Route の値 (0x1f) をそのまま使って問題を起こしていた。問題は hpet_timer_set_irq() 関数に集中している。パッチを当てて ・有効かつ同じ IRQ を使用しているデバイスに影響を与えない IRQ 番号を使う様にする。・IRQ 番号を再設定するためのビットフィールド計算を正しく行うようにする。という修正をした。おかしな動作を調べた記録に話を戻す。kernel parameter に hpet=verbose を追加する。kernel log に HPET レジスタの詳細が出力されるようになる。[ 0.000000] ACPI: HPET id: 0x10de8201 base: 0xfeff0000[ 0.000000] smpboot: Allowing 4 CPUs, 2 hotplug CPUs-- snip --[ 0.000000] hpet: hpet_enable(846):[ 0.000000] hpet: ID: 0x10de8201, PERIOD: 0x2625a00[ 0.000000] hpet: CFG: 0x0, STATUS: 0x0[ 0.000000] hpet: COUNTER_l: 0x0, COUNTER_h: 0x0[ 0.000000] hpet: T0: CFG_l: 0x3e10, CFG_h: 0xff3efa[ 0.000000] hpet: T0: CMP_l: 0xffffffff, CMP_h: 0x0[ 0.000000] hpet: T0 ROUTE_l: 0x0, ROUTE_h: 0x0[ 0.000000] hpet: T1: CFG_l: 0x3e00, CFG_h: 0xff3efa[ 0.000000] hpet: T1: CMP_l: 0xffffffff, CMP_h: 0x0[ 0.000000] hpet: T1 ROUTE_l: 0x0, ROUTE_h: 0x0[ 0.000000] hpet: T2: CFG_l: 0x3e00, CFG_h: 0xff3efa[ 0.000000] hpet: T2: CMP_l: 0xffffffff, CMP_h: 0x0[ 0.000000] hpet: T2 ROUTE_l: 0x0, ROUTE_h: 0x0[ 0.000000] hpet: hpet_enable(885):-- snip --[ 0.196562] HPET: 3 timers in total, 0 timers will be used for per-cpu timer[ 0.196562] hpet0: at MMIO 0xfeff0000, IRQs 2, 8, 31[ 0.196562] hpet0: 3 comparators, 32-bit 25.000000 MHz counter[ 0.198112] hpet: hpet_late_init(932):[ 0.198115] hpet: ID: 0x10de8201, PERIOD: 0x2625a00[ 0.198118] hpet: CFG: 0x3, STATUS: 0x0[ 0.198121] hpet: COUNTER_l: 0x7e31e6, COUNTER_h: 0x0[ 0.198124] hpet: T0: CFG_l: 0x3e18, CFG_h: 0xff3efa[ 0.198127] hpet: T0: CMP_l: 0x7eaeac, CMP_h: 0x0[ 0.198130] hpet: T0 ROUTE_l: 0x0, ROUTE_h: 0x0[ 0.198133] hpet: T1: CFG_l: 0x3e00, CFG_h: 0xff3efa[ 0.198137] hpet: T1: CMP_l: 0xffffffff, CMP_h: 0x0[ 0.198140] hpet: T1 ROUTE_l: 0x0, ROUTE_h: 0x0[ 0.198143] hpet: T2: CFG_l: 0x3e00, CFG_h: 0xff3efa[ 0.198146] hpet: T2: CMP_l: 0xfbff8c, CMP_h: 0x0[ 0.198149] hpet: T2 ROUTE_l: 0x0, ROUTE_h: 0x0[ 0.198167] Switched to clocksource hpet(CFG_l & 0x3e) >> 9 が Interrupt Route の値だ。0x1f (==31) になる。kernel 起動直後から 0x1f のまま変わらない。注: 厳密には HPET レジスタの Interrupt Route の値と Linux Kernel 内の IRQ 番号が違うこともある。hpet_timer_set_irq() 関数の次の個所で Tn_INT_ROUTE_CNF を書き換えようとしている。この処理では 0x1f だった場合、結果は 0x1f のままだ。if (irq < HPET_MAX_IRQ) { spin_lock_irq(&hpet_lock); v = readl(&timer->hpet_config); v |= irq << Tn_INT_ROUTE_CNF_SHIFT; writel(v, &timer->hpet_config); devp->hd_hdwirq = gsi; spin_unlock_irq(&hpet_lock);}ここを修正して ~Tn_INT_ROUTE_CNF_MASK で and した後、or で更新値を合成する処理にした。仕様書では Read Only になっている可能があり、書き込んだ値を読み直すと値が違うことがあると書かれている。nVIDIA NF-MCP61 のチップセットでは R/W 可だった。パッチも Read only だった場合は考慮していない。この修正をしても、IRQ route 初期値が 0x1f になっているとそれが有効だと信じてそのまま IRQ route として使うので HPET は使えない。パッチの大部分は IRQ 初期値あるいは他に選択可能な値で失敗した場合、さらに他の IRQ が使えるかどうか調べる処理だ。他への影響を考えると、望ましくない可能性もある request_irq() を使って成功するかどうか試す、成功だったらすぐに free_irq()でハンドラを外す処理を追加した。IRQ route を探す処理では acpi_gsi_to_irq(), irq_get_trigger_type() を使って request_irq() を使う前に問題なさそうなことは調べる様にした。パッチを当てた kernel で hpet_example を試してみる。$ sudo ./hpet_example poll /dev/hpet 10 4-hpet: executing poll/dev/hpet: hpet_poll: info.hi_ireqfreq=10, info.hi_flags=0x0/dev/hpet: hpet_poll: expired time = 100035 us/dev/hpet: hpet_poll: revents = 0x1/dev/hpet: hpet_poll.read: data=0x1/dev/hpet: hpet_poll: expired time = 99900 us/dev/hpet: hpet_poll: revents = 0x1/dev/hpet: hpet_poll.read: data=0x1/dev/hpet: hpet_poll: expired time = 99886 us/dev/hpet: hpet_poll: revents = 0x1/dev/hpet: hpet_poll.read: data=0x1/dev/hpet: hpet_poll: expired time = 99934 us/dev/hpet: hpet_poll: revents = 0x1/dev/hpet: hpet_poll.read: data=0x1動作した。LOW level active で IRQ 16 番で他の PCIe デバイスと割り込み線を共有していた。時間精度が気になるなら、IRQ 番号を強制指定できるような ioctl() call を用意した方が良いかもしれない。なぜ Tn_INT_ROUTE_CNF (Interrupt Route) の値が 0x1f だったのか、調べていない。仕様書では 0x00 だと書かれている。BIOS で設定したのか? HPET が有る(そして BIOS で有効になっている)別のマザーボードでは kernel の修正なしに hpet_example は動作する。ZOTAC GeForce 6100-ITX は古いマザーボードだ。今時こんな問題に当たる人も居ないか。
2017.09.20
コメント(0)
linux kernel 4.1.27 x86_64 の hibernate の挙動を観測していた。echo disk > /sys/power/state の動作だ。途中奇妙な動作を見付けた。"Disabling non-boot CPUs ..." と kernel log が表示された後、20ms も経たないうちに "Enabling non-boot CPUs ..." と出てきた。[ 3556.082919] Disabling non-boot CPUs ...[ 3556.084199] kvm: disabling virtualization on CPU1[ 3556.084222] smpboot: CPU 1 is now offline[ 3556.096523] PM: Creating hibernation image:[ 3556.100006] PM: Need to copy 192567 pages[ 3556.100006] PM: Normal pages needed: 192567 + 1024, available pages: 822765[ 3556.100006] PM: Hibernation image created (192567 pages copied)[ 3556.100006] PM: Restoring platform NVS memory[ 3556.100006] PCI-DMA: Resuming GART IOMMU[ 3556.100006] PCI-DMA: Restoring GART aperture settings[ 3556.100006] Enabling non-boot CPUs ...[ 3556.100006] x86: Booting SMP configuration:[ 3556.100006] smpboot: Booting Node 0 Processor 1 APIC 0x1[ 3556.086190] kvm: enabling virtualization on CPU1[ 3556.116269] cache: parent cpu1 should not be sleeping[ 3556.116409] CPU1 is upシリアルコンソールでリアルタイムで見ている。printk の時刻が進まなくなっている状況では無い。こんなに慌ただしく、non-boot CPUs を disable/enable する様な処理があるのだろうか?探してみることにした。探した過程は説明を省略、申し訳ない。create_image()の処理だと分かる。disable_nonboot_cpus()を呼び出している。確かに "Disabling non-boot CPUs" だ。kernel log の流れが合っているか追っていく、swsusp_arch_suspend() はアセンブリ言語で書かれた関数だ。hibernate_asm_64.S:swsusp_arch_suspend() (x86 アーキテクチャの場合は hibernate_asm_32.S:swsusp_arch_suspend()) だ。追うと swsusp_save() にたどり着く。swsusp_save() の実装にメッセージ "PM: Creating hibernation image" .. "PM: Hibernation image created" が見つかるので追跡は合っている。create_image() の後ろの方でラベル Power_up: が見つかる。ここから続けて syscore_resume(), local_irq_enable(), enable_nonboot_cpus() が並ぶ、"Enabling non-boot CPUs" だ。ログの前後を読むと周辺デバイスの動きも慌ただしい freeze 直後に thaw だ。snapshot を撮る確実な方法と、それをディスクに書き出す確実な方法なのだろう。
2017.09.05
コメント(0)
今まで MSDN professional subscription に入っていた。licence 切れの通知が来る。今の状況では負担が重い。Visual Studio で何か作ってきたかというと、何も作っていない。scankeylx のために開発用途 Windows licence を買っていたようなものだ。これから買い続ける必要が有るのか?と自問する。Windows 10 の後は、サイクルリリースになり、本当にバージョンアップしないのかなぁ...
2017.07.08
コメント(0)
dion (au one net) ホームページ公開代理サービスが 2017/10/31 に終了する。4 ヶ月前になってようやく redirect 設定をすることにした。au が提供している リダイレクト設定を設定してみた。粗いリダイレクトだった。http://www.h5.dion.ne.jp/~afuruta をhttp://www.ftechworks.mydns.jp/~afuruta/にリダイレクトする設定をした。以下の URL をアクセスすると、http://www.h5.dion.ne.jp/~afuruta/index.htmlhttp://www.h5.dion.ne.jp/~afuruta/scankeylx/scankeylx.htmhttp://www.h5.dion.ne.jp/~afuruta/scankey/scankey.htm全て http://www.ftechworks.mydns.jp/~afuruta/ に転送された。ページ構成を作り替えるのなら、これで良いかもしれない。なるべくそのままの構成を保ちたかった。.htaccess は無視される様だ。次の設定を htdocs 以下に配置しても効果は無かった。RewriteEngine OnRewriteCond %{HTTPS} offRewriteCond %{HTTP_HOST} ^www.h5.dion.ne.jp$ [NC]RewriteRule ^(.*)$ http://www.ftechworks.mydns.jp/$1 [R=301,L]dion web redirect で検索した得られた情報も .htaccess は無視されると言うことだった。ローカルネットで試した設定なので、内容の問題は無さそう。結局 META tag を使い ページリロードを機能を使うことにした。http://www.ftechworks.mydns.jp/scankeylx/scankeylx.htm の <HEAD> </HEAD> 囲み内に <meta http-equiv="refresh" content="0; url=http://www.ftechworks.mydns.jp/scankeylx/scankeylx.htm"> を入れる。他のページも同様の処置をした。この設定でいいのだろうか?とも思う。公開終了したら、META tag を入れたページは消えてしまうのだ。アクセスできなくなるのは変わらない。検索エンジンか気を利かせて http-equiv="refresh" の意図を結果に反映するだろうか? google は 301 response を推奨しているのだ。ページの内容を読み直してみる。そもそも実行環境を作れないソフトも多いのか。
2017.07.03
コメント(0)
野良で公開 web サーバーをサービスしている仮想マシンを更新した。OS は Fedora から Ubuntu 14.04 に変えた。Fedora は security update の観点から運用難が続いていた。更新後のサーバー構成も大きく変えた。以前は {外部公開本番, 待機} の 2 台構成だった。更新後は {外部公開本番, 公開前確認, 内部編集, 待機} の 4 台構成になる。公開前確認 と 内部編集の 2 台を加え wiki によるページ作成を進めようとしている。HTML 手書きから、もう少し手軽にまとまったページを作れる環境作りだ。当面は今まで通りのサービスが障害無く使えること目標にする。4 台の仮想マシンのうち 1 台は 1 年半 併走状態で様子を見てきた。多分大きな問題は無いはず。環境は作った。何か落ち着いて書ける様な状況ではなくなりつつある。
2017.06.30
コメント(0)
サーバー再構築作業にて 自宅内で運用している git repository を git fsck で検査する。dangling commit, blob が出てきた。自分が最初から作ったリポジトリに 1 つ、他を上流とする 5 つくらいのリポジトリ。git gc で消す。自分が最初から作ったリポジトリの head (最も新しい commit を含む branch) に特に異常は見られない。他を上流とする 5 つくらいのリポジトリは追跡を諦めた。何か歳を食ったのかな、多分自分が若ければ git repository 構造の勉強も兼ねて dangling commit, blob の状況を詳細に調べたのかもしれない。あるいは dangling commit, blob を作る様な状況を追求したかもしれない。git show commit-id 位しかしなかった。git gc うん、スッキリした。何か忘れたかもしれないけれど。
2017.06.19
コメント(0)
devuan で運用している VirtualBox の仮想マシンを runlevel 0 に移るとき(仮想マシンサーバーが shutdown する時)に init script から shutdown する方法を調べて実装していた。ある程度実装した段階で /etc/init.d/vboxdrv を読み直すと、次の様な記述が見つかった。# enter the following variables in /etc/default/virtualbox:# SHUTDOWN_USERS="foo bar"# check for running VMs of user foo and user bar# SHUTDOWN=poweroff# SHUTDOWN=acpibutton# SHUTDOWN=savestate# select one of these shutdown methods for running VMs(パッケージをインストールした段階では存在しない) /etc/default/virtualbox ファイルを作成して、仮想マシンの所有者を SHUTDOWN_USERS、シャットダウン方法を SHUTDOWN に設定すればいいのか。シャットダウンを行う次の様なコマンドラインが呼び出される。環境変数 VBOX_IPC_SOCKETID を user name として扱っている様に読める。# vboxmanage controlvm ${VMNameOrUUID} poweroff|acpipowerbutton|savestateドキュメントに書かれているかな... まだ記載されていない。どうしてだろう? /etc/init.d/vboxdrv:stop_vms() を読んでみると、仮想マシンが完全に shutdown したかどうか同期する処理が見当たらない。多分この「緩い」実装が UnDocumented の理由だろう。shutdown をしたならば単純に 30 秒 sleep するだけだ。環境変数 VBOX_IPC_SOCKETID もドキュメント記載なし。/usr/lib/virtualbox/VBoxXPCOMIPCD と /usr/lib/virtualbox/components/VBoxXPCOMIPCC.so に文字列が見つかるので参照しているのは間違いないだろう。危なっかしい shutdown だ。途中まで実装したスクリプトの実装を仕上げることにした。vbox-poweroff を /etc/init.d/ へ、vbox-poweroff.conf を /etc/default/ へ配置し # update-rc.d -f vbox-poweroff remove; update-rc.d vbox-poweroff defaults にてインストールする。特に何も設定しなくても、だいたい上手くいく様にしてある。VBOX_POWEROFF_MACHINES="auto" で動いている仮想マシン全てを対象にする。 VBOX_POWEROFF_MACHINES="user1:machine-name1 user2:machine-name2" の様な列挙記述で特定の仮想マシンに限定。VBOX_POWEROFF_WAIT_TIME に仮想マシン終了待ち時間を指定。仮想マシン側では /etc/acpi 下のスクリプトを修正してなるべく早くシャットダウンする様にする。UPS を使い始めて 6 年半の間懸念事項だったんだよな。
2017.06.15
コメント(0)
apache2.2 から apache2.4 への移行作業で Virtual Host 毎の独立性を高めようと、httpd.conf を分割し Virtual Host 毎に分離していた。LoadModule directive の context が server config, virtual host となっていたので Virtual Host 毎に設定できるものだと思った。複数の <VirtualHost></VirtualHost>の中に LoadModule を書いて(実際には IncludeOptional *.load 相当で書いてある) apache2 を起動したら次の様な警告が大量に出た。AH01574: module actions_module is already loaded, skippingAH01574: module alias_module is already loaded, skipping...お隣の Virtual Host でロード済みの module を再ロードすると警告が出る。警告なので無視しても害はないのかな。Virtual Host 毎に module を使う/使わないを設定できないのか。module に対する parameter (directive) は VirtualHost 毎に独立している様だ。例えば Alias は Virtual Host 毎に設定出来る。全ての module で同様かは確かめていない。Virtual Host 毎に欲しい module を書きたい。mods-available/*.load を次の様に書き換える。多重ロードになる場合、警告が出ない様にした。<IfModule !alias_module>LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so</IfModule>継ぎ接ぎ感... なるほど apache だ。
2017.06.12
コメント(0)
サーバー再構築作業をする 1 日だった。httpd.conf を apache 2.2 系から 2.4 系に書き換える。設定ファイルの分割(本当にメリットあるのかな...) 1 つの httpd.conf ファイルで設定していたのを色々と分割するのが新しい習わしなのか。{conf|mods|sites}-{available|enabled} に分割して書くのも VirtualHost を使い出した途端に破綻している気がする。Options directive 書き換え、Options option1 を Options +option1 の様に +- 符号を付ける。付ける(親ディレクトリ設定に付加|削除)/付けない(そのディレクトリに新規設定)で意味が変わる。前にも書いたな...Order, Allow, Deny を Require に書き換え。互換 module も有る様だ。書き換えよう。どの VirtualHost も同じ設定を使っていた。これも VirtualHost 毎に変える(変えられる)様にファイル分割する。<VirtualHost></VirtualHost> コンテキストで使える directive かどうか一つ一つ調べて時間が掛かる(おおよそ予測できる仕様だ)。ファイル分割すると見通し悪くなるな。この先も管理者は一人のまま、ファイル変更でお互い編集合戦になることは無いのに。
2017.06.07
コメント(0)
Linux server 構築作業を主にする。LSB の 20.3. Comment Conventions for Init Scripts を見て真面目に init script の書き方について勉強すればもう少し早めに解決したかもしれない。vncserver 用の古い init script をそのまま /etc/init.d ディレクトリへコピーして chkconfig vncserver on をしてしまったのが、問題を起こした発端らしい。次の様なエラーがでた。chkconfig --list で見るととの runlevel も off のままだ。insserv: warning: current start runlevel(s) (empty) of script `vncserver' overrides LSB defaults (2 3 4 5).insserv: warning: current stop runlevel(s) (0) of script `vncserver' overrides LSB defaults (empty).他の init script の Default-Start と Default-Stop をコピペしてきても直らない。全部をコピペして、Provides を直しても直らない。/etc/rc[0123456S].d/* ディレクトリの下に KNNservice と SNNservice (自分の場合だと K01vncserver と S01vncserver) synbolic link が何かの矛盾を抱えて残っているのがエラー原因だった様だ。該当する K01vncserver と S01vncserver symbolic link を消す、他の古い init script を含めて正しく書き直す、chkconfig vncserver on をして正しく動作する様になった。こんなことがあっても SysV init script だね。
2017.06.05
コメント(0)
Windows10 PC がスリープしなくなった。席を離れても ディスプレイは On のまま、スリープに入らない。原因を特定できていない。直近の変更を列挙しておく、・ATOK2017 インストール ・SMB/CIFS 1.0 protocol support (元々有効だったのを再有効化) ・samba nt pipe support = no以前使っていた スクリプト と 現在のマウス座標を調べるコンソールアプリ(Delphi Source と EXE)を復活させて、離席と思われる状況で sleep する様にした。powercfg で見ても特に変なもが見当たらない。何が起きているのか...
2017.06.04
コメント(0)
I-O DATA MagicTV GT の BS と CS の番組表が更新されなくなった。「番組データベースの初期化」で解決しなかった。mAgicガイドDigital/GTの番組表が正しく受信されない に有るとおり C:\Users\ユーザー名\AppData\Roaming\I-O DATA\mAgicTV\iodbad フォルダを消せば解決するのは、以前試してみて分っていた。確か「おまかせ録画設定が消えた」様な...今回は「おまかせ録画設定が消えない様にする」期待を込めて、iodbad フォルダ内の Setting.mdb ファイルを残して他(自分の所だと 00000000 フォルダ, 00000136 フォルダ、GGuideinfo.mdb)は消すことにした。目論見通り、「おまかせ録画設定」は残った。おまかせ録画設定も、「負荷が軽くなるだろう」という期待を込めて不要項目は削除する。説明が面倒だと、フォルダ以下全部消してになるのかな。
2017.05.31
コメント(0)
家庭内・野良 web page サーバーの更新作業を再開した。3 月頃に既に下の図の段階 2 までは進めていた。更新した副サーバーは順調に稼働している。 少し落ち着いてきたこともあり、段階 3 を始めた。運用離脱した副サーバーを仮正サーバーとして一時的に運用する準備だ。ケース、周辺機器の配置の都合もあり運用離脱したマシン(赤)をそのまま正サーバーとせず一時的な仮運用をする。 更新作業前は(そしてこの更新作業中も)脆弱性対応に難が出てきている。新しいサービスの実験もパッケージ導入では済まなくなってきている。正・副相互の依存性も軽くする必要がある。スッキリ一新? 古いファイルとシステムが仮想マシンやパーティションの片隅に溜まる雪だるま方式なんだ。
2017.05.30
コメント(0)
samba の脆弱性 CVE-2017-7494が公開されていた。対処したサーバー群は常用で 12 台、臨時稼働で 3, 4 台だ。簡単な対処法は /etc/samba/smb.conf(典型的な設定ファイルパス) の [global] section に nt pipe support = no を設定すことだ。nt pipe support = no について調べてみる。副作用があるような記述は見かけない。設定してみる。サーバーにアクセスできなくなった。アクセスした PC に「アクセス許可がありません」と表示される。# smbpasswd -x user-name; # smbpasswd -a user-name でも改善しない。nt pipe support = no をコメントアウトすると問題は出ない。強すぎる副作用だ。状況を色々と見てみると \\server だけでアクセスすると、共有名のリストを得ることができない。共有名を付けて \\server\share でアクセスすると共有したディレクトリをアクセスできる。smbpasswd で user-name に対してパスワードを設定して、 /home/user-name が存在するなら、典型的な場合だと \\server\homes でアクセスできる。[homes] セクションに valid users = %S を付ける。あるいは [共有名] セクションに valid users = user-name を付けると、状況が変わるかもしれない。\\server で共有名の一覧ができなくなったので不便になった。仕方がないか。\\server\share でアクセスでき、この状況で感じることは少しアクセスに僅かな遅延を感じる程度か。たまにアクセスするだけの仮想マシンなので感じ方が正しくないかも。最新の samba ソースを持ってきて、コンパイル and インストール? それは、それで地獄だった。
2017.05.26
コメント(0)
PIC のアセンブラ MPASM 5.66 で生成したバイナリが MOVWF PCL を実行したところで、暴走していると思われた。シミュレーターで追いかけてみると MOVWF PCL 実行直前の PCLATH:W の値と全く関係のないところへ PC がジャンプしていた。意図する実行場所は DT directive で生成した RETLW 命令だ。シミュレーターの特異な動作に何がいけないのか分らなかった。休みを入れて .lst ファイルを見て生成したバイナリを見る。DT directive で RETLW 命令 (0x34xx) を生成していないことが分った。DT の data に対して Flash Program Memory, EEPROM 領域のアドレスを保持しているラベルを直接書くと RETLW 命令を生成しない現象が起きる。LOW や HIGH 演算子を付けて書けば、RETLW 命令を生成する。MPASM のマニュアルに書かれている "Each expr must be an 8-bit value." と書かれている条件に抵触したのだ。状況を再現するため短いプログラム(project 一式ダウンロード)を作ってみる。; Test MPASM DT directive. LIST PROCESSOR 16F690 #include "P16F690.INC" __config _FCMEN_OFF & _IESO_OFF & _BOD_OFF & _CPD_OFF & _CP_OFF & _MCLRE_ON & _PWRTE_ON & _WDT_OFF & _INTOSCIO __idlocs 0xff00DEEPROM CODECONFIG_00 DE 0x00VECTOR CODERESET GOTO START ;0x00 NOP ;0x01 NOP ;0x02 NOP ;0x03 RETFIE ;0x04PROG0 CODESTART SLEEP GOTO RESETTABLE1 DT A'A', CONFIG_00 DT A'B', LOW CONFIG_00 DT A'C', HIGH CONFIG_00 DT A'D', START DT A'E', LOW START DT A'F', HIGH START DT A'G', 0x001 DT A'H', 0x100 ENDDEEPROM は (0x2100) から始まる EEPROM 領域だ。アドレスは linker script(MpasmDt_16f690.lkr) で指定している。アセンブルして .lst ファイルを読んでみる。アドレスのラベル CONFIG_00, START を LOW, HIGH 演算子無しに書いた所(A'A' と A'D' の行)は ???? になっている Linker に対して address の全 bit を fixup する様に指示している。0002 00026 TABLE10002 3441 ???? 00027 DT A'A', CONFIG_000004 3442 34?? 00028 DT A'B', LOW CONFIG_000006 3443 34?? 00029 DT A'C', HIGH CONFIG_000008 3444 ???? 00030 DT A'D', START000A 3445 34?? 00031 DT A'E', LOW START000C 3446 34?? 00032 DT A'F', HIGH START000E 3447 3401 00033 DT A'G', 0x001Warning[202]: Argument out of range. Least significant bits used.0010 3448 3400 00034 DT A'H', 0x100LOW, HIGH 演算子を付けた所(A'B', A'C', A'E', A'F' の行)は 34?? となっていて RETLW 命令の literal 部分を fixup する様になっている。要注意なのは 8bit で収まらない定数(A'H'の行)に対して警告が出て、アドレスのラベルには警告が出ないことだ。条件によっては 8bit に収まるから? LOW, HIGH 演算子無しにラベルを使う場合に警告しても良いと思う。シミュレーターの Program Counter が DT directive で生成した ???? の位置(RETLW 命令ではない何か別の命令)を指さずに予測不能な位置を指してしまった理由は不明だ。MPLAB X IDE のシミュレーターの作りはどうなっているのだろう? RTL から生成した C 言語か何かのソース?それとも仕様から手で書き起こした?
2017.05.26
コメント(0)
windows10 上の firefox の動作に引っ掛かりが出てきている。重いのとは少し違う。スクロールが途中で止まる。クリック可能な領域の反応が無くなる。少し調べてみるとグローバールネットとルーティングしているルーター (192.168.0.1) の port 5432 に対して firefox.exe がアクセスしている。windows の netstat -b にて次のような表示が現れた。[firefox.exe]TCP 192.168.0.168:62959 192.168.0.1:5432 TIME_WAITTCP 192.168.0.168:62960 192.168.0.1:5432 TIME_WAITTCP または UDP port 5432 は PostgreSQLで使うポートだ。firefox 内部で使っているのは SQLite だったような。ルーターに PostgreSQL なんて機能は無いし、なんで接続しようとするのだろう。変なソフト食べたのかな? Addon に異常なものは見つからない。処置: アンインストール。
2017.05.23
コメント(0)
PIC マイコンを使ったガスコンロ点けっぱなし監視基板のファームデバックを続けている。なかなかバグが取れない。ステートマシンと割り込みで取り込んだ ADC データがメインループに渡る所がうまく動作せず、リブートする。リブートするのは意図した動作だ。自己監視をする処理を組み込んである。プログラム領域のワード数を増やさない様に BANKSEL を減らせそうなところは減らしていた。これが問題を起こしていた。状態変数を保持しているレジスタに BANKSEL していなかったので状態が更新されず、ADC データ取り込み処理が機能不全を起こしていた。これが自己監視系で異常と判定されリブートする。PIC を使っている時点で BANKSEL(と PAGESEL)の悪夢は初めから分かっていたではないか...
2017.05.20
コメント(0)
気温上昇とともに PC のファンがうるさくなりだした。CPU のクロック周波数を見ると、上限で張り付いたままだ。CPU 利用率が 10-20% でもクロック周波数が下がらない。何かおかしい。コントロールパネルの電源管理で「省電力」にすると、クロックが下がる様になった。しばらくすると、電源管理のプロファイルが「バランス」戻り、クロック周波数が固定される。ASUS AI suit 3 で色々と設定するとどうも様子が変わる。タスクトレイから AI suit 3 を消しても、「バランス」に戻る現象が発生する。タスクスケジューラを開いて、タスク スケジュールライブラリ/ASUS/ASUS AISuiteIII と タスク スケジュールライブラリ/ASUS/ASUS DIP AwayMode を無効にした。トリガーも念のため無効にする。ログオン、スリープ状態から復帰、いずれの事象が有っても電源管理プロファイルは「省電力」のままになった。「バランス」ってクロック周波数固定だったんだっけ?
2017.05.20
コメント(0)
PIC マイコンファームのデバックを続ける 1 日だった。動いている実感には遠い。どのステートマシンも何かしらの問題が有る。どこを着手しても何かの改善はある。同時に新しい問題が見つかる。今のところ MPLAB X IDE のシミュレータで気付ける範囲なのが救いか。
2017.05.15
コメント(0)
PIC のコードをデバックしていた。エミュレーター上で reset vector 0x0000 番地からコードが進まずループする。いくら step 実行しても Program Counter は 0x0000 から変化しない。何が起きているのか?生成した ROM コードのバイナリを眺めると、0x0000 番地に配置されたコードが GOTO 0x000 (0x2800) だった。GOTO START とソースに書いたコードに対する機械命令だ。MAP ファイルを見ると START 番地が 0x800 だった。単一の GOTO 命令では分岐できない距離だ。Linker Script (.LKR) ファイルの通りにオブジェクトが配置されていない? Linker Script HelloWorld_16f690.lkrは次のようになっている。CODEPAGE NAME=pcvector START=0x000 END=0x013 // interrupt vector.CODEPAGE NAME=page0 START=0x014 END=0x7fd // code area.CODEPAGE NAME=.cinit START=0x7fe END=0x7ff // not needed.CODEPAGE NAME=page1 START=0x800 END=0xfff // code area.page0 を 0x14 から始める様に指定している。START 番地は 0x014 になるつもりだった。これに対し、MAP file は HelloWorld.X.production.map は次のようになっていた。 Section Info Section Type Address Location Size(Bytes)--------- --------- --------- --------- --------- pcvector code 0x000000 program 0x00001c page1 code 0x000014 program 0x000a2c .cinit romdata 0x0007fe program 0x000004 page0 code 0x000800 program 0x000ff6 .idlocs code 0x002000 program 0x000008.config_2007_BUILD/DEFAULT/PRODUCTION/_EXT/41 code 0x002007 program 0x000002 eedata code 0x002100 program 0x000024 gpr0 udata 0x000020 data 0x00004bgprnobnk udata 0x000070 data 0x000004 gpr1 udata 0x0000a0 data 0x00002eReset 直後の飛び先がある page0 を 0x014 から始めようとしたのに 0x800 から始まる様になっていた。 .LKR の指定を無視して配置が行われている。linker のマニュアルを見ても、このような配置換えを抑止する方法は見つからず。どうも生成した ROM code が section に収まりきらないと配置換えが起きてしまう。サブルーチンを見つけて、PIC の ROM page に柔軟に割り付ける様な賢い文法や機能は MPASM と MPLINK に見つからない。見つけられないだけ?Assemble, Link のコンソール出力を眺めても section オーバーフローのエラーは出ていない。.map ファイルを見るか、チップに書き込む前のバイナリを見ないと問題に気づかない。IDE で開発しているのにテキストエディタでファイルを開いたり、閉じたり...
2017.05.12
コメント(0)
scanleylx を r1704b にバージョンアップした。不良ブロック回避処理がデグレードしていて、回避が上手くいかず処理が終わらなくなる問題が発生していた。これを修正した。Free Pascal の system call error 取得処理がどうなっているのか正しく理解せずに修正をしたのが原因だ。言い訳をするなら、Free Pascal の方も問題有りだと思っている。libc 互換ユニットを廃止して baseunix, unix, pthreads などに再実装した。この変化を強制するほどのメリットがあったのだろうかと思う。追従する書き直しで、自分が混乱してしまった。不良ブロック回避処理も大幅な見直しが必要かもしれない。背景をまとめず並べてみる。1 ドライブ 数 Tbyte に大容量化、再試行をしたところで救える見込みが無い SSD、最近のハードディスクは不良ブロックが広がりやすい傾向がありそうな感があること、Linux Kernel のエラー処理、BlockIO-SCSI-(S)ATA 変換処理... 一つ一つは何でもなさそうだな。scankeylx の前身 MS-DOS で動く scankeyには検索開始点を指定できる機能が有った。自動的に不良ブロックを避けるアルゴリズムを実装した時点で廃止した機能だ。アルゴリズムを複雑にしないための機能選択だった。いまのところ、どうするかは見通しは無い。
2017.04.27
コメント(0)
全892件 (892件中 51-100件目)