全884件 (884件中 101-150件目)
lubuntu をインストールした環境に vnc4server, gnome-terminal をインストールした。デスクトップは LXDE だ。lubuntu のデフォルトの通りだ。この環境にリモートから VNC server に接続し、gnome-terminal を起動するとターミナル window 内に shell(command) prompt が現れない。色々と調べていくうちに lxsession を正しく ~/.vnc/xstartup から起動すると問題を解消できることが分かった。元々の xstartup に書かれた通り /etc/alternatives 以下に繋がるシンボリックリンク x-window-manager で LXDE を起動すると問題が起きる。入力メソッドの設定、DBUS の設定も含めて、VNC server の画面に LXDE を使う xstartup を作成する。#!/bin/sh# Uncomment the following two lines for normal desktop:# unset SESSION_MANAGER# exec /etc/X11/xinit/xinitrc[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresourcesxsetroot -solid greyvncconfig -iconic &# start ibus ans setup input method.export GTK_IM_MODULE=ibusexport XMODIFIERS="@im=ibus"export QT_IM_MODULE=ibusibus-daemon -d -xif test -z "$DBUS_SESSION_BUS_ADDRESS" ; then eval `dbus-launch --sh-syntax --exit-with-session` echo "D-BUS per-session daemon address is: \ $DBUS_SESSION_BUS_ADDRESS"fi/usr/bin/lxterminal -t "$VNCDESKTOP Desktop" &/usr/bin/lxsession -s Lubuntu -e LXDE &先に terminator を使って解決済みだったんだ... VNC server で LXDE がちゃんと動くようになったのだから、これで良し。
2017.03.19
コメント(0)
Windows10 でエクスプローラがクラッシュ(突然止まる)する現象が出始めた。用で外出していた時に Windows Update が勝手に掛かって、再起動後に起き始めた現象だ。イベントビューアーで見ると Comppkgsup.dll で問題が起きた記録が残っている。ネットを検索すると、最近 2, 3 日中に増えた現象だということも分かった。該当 Knowlege Base は KB4013429 だと思われる。Comppkgsup.dll を含んだ更新だ。Comppkgsup.dll を古いバージョンに戻すのが解決手段として挙げられている(Microsoft の正式な見解としては見つからず)。大丈夫かな? KB4013429 のファイル更新リストは 180621 行, 約 7Mbyte の CSV ファイルだ。現象が出る条件はおおよそ、「大量の画像、動画ファイルがあるフォルダーを大アイコン(サムネイル)で表示しようとする」だ。フォルダーにある動画ファイルを別フォルダーにコマンドラインで移したら、該当フォルダーを見ることができるようになった。cygwin などの便利なコマンドライン環境が有れば可能な操作だ。move コマンドでもある程度は可能だろう。*.mpg, *.mpeg, *.mov, *.wmv, *.mp4, *.flv, *.avi など拡張子で選択するパターンで移した。不思議なのは、先の操作で動画ファイル移した先のフォルダーは何事もなく表示できることだ。ファイルがどっかに消えた?あるいは、「たくさんの」という状況で異常を起こす条件が成立しているかも。画像や動画がいっぱいのフォルダーって... それはその...
2017.03.17
コメント(0)
リリースノートなので文体を変えます。Windows プロダクトキー検索ツール scankeylx r1703a (2017/3 版)をリリースしました。scankeylx r1703a ダウンロードmd5sum: e71be430674277a1719dbd59e4e3c373sha1sum: a5ec2e7b50e772d9208f0f28af596c448ea49b20Lubuntu 16.04.1 i386 で実行したスクリーンショット前回のリリースと変わった主な点は次の通りです。Ubuntu と Lubuntu の両方に対応しました。Ubuntu では負荷が高く動作が重くなってしまう環境でも Lubuntu を使うことで軽快に操作できます。32bit(x86) と 64bit(x86_64) の両方に対応しました。Ubuntu が 64bit 版に主流を移しつつある状況に対応しました。実験的に Raspberry Pi3 対応版を付けました。ARMv7 アーキテクチャをターゲットとするコードをソースコードから生成できます。開発環境を Lazarus 1.6.2/Free Pascal 3.0.0 へ移行しました。最新版のコンパイラを使うことでオブジェクトコードの質が向上し検索速度が向上しました。x86 依存コード部分をプラットホーム非依存コードで置き換え可能としました。稀な動作不具合を解消しました。排他制御失敗、繰り返し使用でファイルディスクリプタがリークしてしまう問題を解消しました。RaspberryPi3 で実行したスクリーンショット検索できるキーの種類、整理した結果の簡潔さは前回リリース r1512a と比べ大きな変化は有りません。機能の変化が無いのに対し、動作環境を増やしたため、ソースの修正量、確認作業量が大きくなりました。Ubuntu と Lubuntu 16.04 に対応したことで、しばらくは大規模修正をしなくても使えると期待しています。今後ともよろしくお願いします。
2017.03.11
コメント(0)
【重要なお知らせ】楽天ブログ 完全SSL化について と 【楽天ブログ】SSL化に伴う変更点 が実施された様だ。こちらで気づいた具体的な変更点は、blog にでている画像が proxy 経由で自営サーバー(野良サーバー)から取得される様になったこと。"pproxy.rakuten.co.jp" が自営サーバーのログに残る様になった。この blog の画像は 2014/2 辺りの日記以降で楽天のサーバーに upload された画像から、自営のサーバーに格納している画像に変っている。 恐らく多くの人が気にしていないか、気づいていないはず。3 枚の画像を確認した限りでは proxy で画像ファイルサイズ、exif 情報を変える様な加工はしていなかった。技術的には可能なはず。少し皆さんと距離が遠くなったかな。まぁ、うん。気にしないで...
2017.03.08
コメント(0)
VirtualBox 5.1 で Lubuntu 16.04 x86_64(amd64) を動かしてみる。おそらく Ubuntu にも当てはまるだろう。VirtualBox の仮想マシン設定のうち要点を挙げる。General/Type:" Linux"General/Version:" Ubuntu (64-bit)"System/Enable EFI(special OSes only): チェックを消す64bit OS であっても、UEFI は使わない。UEFI を使おうとしても仮想マシンの画面が真っ暗、異常表示、仮想マシンそのものが Abort してしまう。ISO イメージから起動する設定が終わったら、Start で起動する。すぐさま、仮想マシンのウインドウをフォーカスし [Shift] キーを押し続けて GRUB に割り込む。一番初めの ISO イメージからの起動は [Shift] キー押し続けは不要かもしれない。以降、正常起動できる設定が終わるまで、 再起動時は「[Shift] キー押し続け」をして kernel parameter を設定する。ISO イメージから起動した場合は、言語選択("English" を推奨する。日本語だとインストーラーの「進む」ボタンが画面外になり押せない)をして、"Try Ubuntu without installing" に選択を合わせる。[F6] を押して、kernel parameter から quiet splash を削除し、その場所に vga=791 nomodeset xforcevesa を追加して、[Enter] を押して起動する。どうしても日本語でインストールを進めたい場合は、起動した後、次の様にして 1280x1024 の画面サイズにする。画面解像度 1280x1024 の xorg.conf を使う操作である。$ cd /tmp$ wget http://www.ftechworks.mydns.jp/blog/virtualbox/xorg-1280.conf$ sudo cp xorg-1280.conf /etc/X11/xorg.conf$ sudo service lightdm restartインストールが終わったなら再起動する。先と同様に再起動直後より [Shift] キーを押し続けて、GRUB に割り込む。"Ubuntu" を選択した状態で [e] を押す。kernel parameter から quiet splash を削除し、その場所に vga=791 nomodeset xforcevesa を追加して、[Ctrl]+[x] を押して起動する。起動したならば次のコマンドを投入して /etc/X11/xorg.conf と /etc/grub.d/10_linux を入れ替える。自分のサイトからのダウンロードになっている。どちらもテキストなので処置前に確認してほしい。$ mkdir workdir$ cd workdir$ wget http://www.ftechworks.mydns.jp/blog/virtualbox/xorg.conf$ wget http://www.ftechworks.mydns.jp/blog/virtualbox/10_linux$ cat xorg.conf # 内容確認$ sudo cp xorg.conf /etc/X11/$ diff 10_linux /etc/grub.d/10_linux # 内容確認$ sudo cp 10_linux /etc/grub.d/$ sudo update-grub$ grep nomodeset /boot/grub/grub.cfg$ syncxorg.conf は VESA ドライバを使う様に書かれている。10_linux は以下の太字部分を追加する修正だ。ダウンロードしなくてもその場で修正できる。vt_handoff="1"GRUB_CMDLINE_LINUX_DEFAULT="nomodeset xforcevesa". "${datarootdir}/grub/grub-mkconfig_lib"以降は起動時に GRUB に割り込まなくても普通に起動する。運用で次の点に注意が必要だ。VBoxAdditions をインストールしてはいけないKernel または GRUB を Update すると 10_linux ファイルのマージあるいは修正に手動対応が必要になるかもしれない。方針は GRUB_CMDLINE_LINUX_DEFAULT="nomodeset xforcevesa" を残すUEFI を使わず何だか古臭いやり方だ。これが一番確実に動作している。UEFI を使うやり方も模索してみると、起動の度に起こる問題が変わったり、正常動作したりで状況を整理できなかった。VirtualBox が動的にパッチを当てたり、ハードウエアのエミュレーションを変更するためのフラグ管理が破綻しているか、何かの変化履歴が影響していそうだった。
2017.03.04
コメント(0)
Asrock J3160-ITX でフロント(拡張) USB 2.0 と USB 3.0 ポートで High Speed Device を認識しない原因は、USB 3.0 ポートの USB3_3_4 と USB 2.0 ポートの USB_5_6 ピンヘッダーが排他利用なのに両方使おうとしたのが原因だった。J3160 (J3710-ITX) マニュアルの PDF Page 9, 製本ページ 4 に "USB3_3_4 is shared with USB_5_6." と書いてあった。隣同士にあるピンヘッダだ。USB 2.0 ポート USB_5_6 からケーブルを外すと USB 3.0 ポート USB3_3_4 で High Speed device を認識する様になった。両方に拡張コネクタを繋ぐと配線は二股になり、片方はスタブになる。信号反射かインピーダンスが下がりすぎて信号レベルを維持できなくなったのだろ。電源も交換した。もう少し安定性を見よう。
2017.02.22
コメント(0)
x-アプリ 6.0 の負荷テストで GDI オブジェクトを使い果たしてアプリケーションが停止する現象が発生した。大量の画像(x-アプリではフォト)を一覧表示しているときに発生する。出先で見たユースケースではない。タスクマネージャーで GDI オブジェクトの数が 9,999 になっていた。Microsoft TechNet: Windows の限界に挑む: USER オブジェクトと GDI オブジェクト – 第 2 部 によればアプリケーションが使える GDI オブジェクト数は 10,000 だ。派手なアニメ表示の方がリソース管理より大事なのかな。普通のミュージック表示の負荷テストでは、考察が必要な状況になっている。20,000 曲を登録した時点で、画面崩れ、画面チラツキがほぼ発生しない状況になった。登録を増やすと現象は出にくくなる。登録が少ない方が起きやすい理由を考えて試す必要が有る。20,000 曲の半数以上の音楽データは sox で正弦波を生成し mp3 フォーマットで格納、アルバムアートは 120 ~ 640 ドットの正方形 png, gif, jpeg ビットマップ、アルバム名、タイトルは UTF-8 のランダム文字列だ。ある意味、整いすぎている。
2017.02.19
コメント(0)
実家の Windows10 PC から Windows7 だった時にインストールした Acronis Trueimage をアンインストールして 1 ヵ月ほどたっていた。様子を見に実家に行く、Windows Event Viwer で「突然シャットダウン」記録を見てみる。少なくとも直近 3 日間で記録は無かった。以前は 1 日に 2, 3 回あったので、頻度は減っていた。使わなくなった訳では無く、使用していると思われる記録も脈々と付いていた。夜になって父が帰宅してきたので使用状況を聞いてみる。ブルースクリーン頻度は減ったとの事だ。状況が良くなっている。Acronis Trueimage が無くても Windows7 にはバックアップと復元機能があり、スケジュールもできる。困ることは無い。Disk to Disk のコピーが出来ないくらいか。やって良かった。少し気になるのは Trueimage をアンインストール後ライセンスが外れたので、自宅に持ち帰り仮想マシンに同様に Windows 7 にインストールして Windows10 に upgrade した状況ではブルースクリーンにならないのだ。何かが違う。現象再現は頑張らなくても良いか...
2017.02.17
コメント(0)
x-アプリ 6.0 を Windows10 でテスト開始、負荷するデータは x-アプリ 5.0 と可能な限り同じにしてみる。画面がちらつきだして描画崩壊が始まった。現象再現に成功する。出先で見たのは PC 固有の問題ではなく、x-アプリについて回るというのも確かな事だと分る。問題再現したのだから、解決手段の有効性確認をしやすくなったのと同時に、解決が難しいのも確かな事になった。固有事項の解消は答えになりそうに無いのだ。程度問題を見極める必要がある。x-アプリ 6.0 の方が悪い様だ。アプリケーションの応答が無くなる。Window message を妨害しているのかな。他の window に対する操作も応答を失うことがあった。まさか message loop 処理に時間が掛かる処理を入れ込んでいるのか、処理が間に合わなかったら変なメッセージの捨て方をしているのか?気持ちは x-アプリ 5.0 を何とかして使う方向に傾く、もう少し負荷テストをしてみて見極めるか。
2017.02.13
コメント(0)
Windows10 テスト環境を増やす必要が有ったので休眠中の PC とマザーボードを探す。その辺に置いておける筐体に入った PC を優先することにした。実家から引き取った EPSON DIRECT AT-930C (CPU: Pentium4, RAM: 1Gbyte) と IBM Think Centre 8183-A6J (Pentium4, RAM:512Mbyte) だ。どちらも CPU アップグレードにより Pentium4 だ。8183-A6J の方はメモリ不足、起動してみて装着容量が足りないことを思い出した。PC3200(とこれより速度が遅く互換が有る) メモリの手持ちも容量アップを狙える物はい。そもそもインストールメディアから起動しても、青 Windows アイコンが出て暫くするとリブートしてしまう。不足要件を示すメッセージが出ないのか...AT-930C の方は、要件は満たしているはず? こちらもインストールが進まない。どちらも、Windows Xp 向けの機種だ。調べてみると Pentium4 は CPU の要件(必要命令セット)を満たすかどうか種類によってまちまちだった。満たしていないのだろう。AT-930C の HDD をテスト用に入れ替えている最中に、マザーボード上のコンデンサが膨らんでいるのを見つけた。液漏れは起こしていない。触診で分る膨らみも僅かだ。この状態で電源を入れると動く、コンデンサの容量はまだ抜けきっていないのだろう。常用するなら要修理だ。実家で母親が使っていたマシンだ。「思い入れがあるのなら、HDD をバックアップすればそれで十分ではないか。何もせずとも、既に新しいマシンへデータ移行は済んでいるのだ。」、と思いつつ今後の処遇を悩む。修理したとして Windows10 は動かないのだ。使う機会は scankeylx テストくらいだ。そっ閉じ、と言うわけにも行かず、入れ替えた HDD を元に戻す。
2017.02.12
コメント(0)
x-アプリ 5.0 を Windows 10 にインストールして動かすことができた。テストデータを読み込ませて動作試験を開始する。動かし始めてすぐに画面が崩れ出した。激しいちらつきは無いものの、問題ありだということが分かった。画面の崩れ方は出先で見た状況と似ている。x アプリ以外のウインドウ描画も異常になるのも一緒だ。x-アプリ 5.0 を使う判断は x-アプリ 6.0 と比較して悪い状況の程度が許容出来るかどうかか。うーん、手間が増えたなぁ。x-アプリ 5.0 で上手くいくなら後の作業は、x-アプリ 5.0 に集中して行えばよい。程度比較となると 6.0 も動かしてみる必要がある。x-アプリ 6.0 で起きていた画面チラツキと崩壊問題は 5.0 から続いていた問題だということも分かった。開発元は分かっていたのか、それとも分かっていない(テストしていない)のか。脈々と受け継がれる「先送り」か。ソフト開発の仕事をしていた時の経験に重なるものが有る。請負先には bug track system があった。処置の選択肢に「先送り」が有る。開発責任者の決済で選択できる。「先送りの受け継ぎ」に情報の欠落がある。「先送り」にされた問題は前任者が入れた問題か、あるいは再テストしていた問題かだ。おおよそ、前任者は請負か派遣で来た人だ。シリーズ物の年次毎のリリースが終われば、人は入れ替わる。ちゃんとした資料が残っていないことが多い。先送りするので決済を行う「開発責任者」(つまり偉い人)向けのパワポ資料は残っている。コードを弄っていない人が「それが分る」様に書かれているのだ。リリースに向けた「政治」でもある。何となく致命的な本質は隠してあるのだ。添付資料に書かれた再現手順や、問題解析の内容を読むに何かボケた所があるのだ。おおざっぱな説明とコードは一致していない。問題発生までの状態変化も解決を困難にしている様々や周辺状況は押さえていない。前任者は入れ替わっているのだ。再現手順、おおよそ目星を付けていたコードの位置、ログ出力の記録などは手に入らない。前任者が几帳面で bug track system に作業記録を詳細に残してくれている?まず期待できない。記録を成果物として数え上げ、報酬に反映する様な仕掛けは絶望的に無いのだ(何処かの国では「働き方改革」とか頑張っている様だけれど、そもそも現場的に報われない)。「先送り」再テストをしようにも、政治によって嘘でないくらいに弱められた再現手順で「再現せず」になるのだ。白状しよう自分もこんな引き継ぎをしたことがある。もっとテストをするか...
2017.02.12
コメント(0)
x-アプリ を試すため、アルバムアート入り mp3 ファイルを大量生成する必要がある。アルバムアートを入れる意図は画面チラツキと崩れの原因がアルバムアートの表示に有るのではと思っているためだ。CD から取り込んだ事を模擬するため、アルバム名、曲タイトルも ID (tag) に入れる必要もある。ファイルの羅列ではなく、何かのグルーピングも問題に関係している可能性が有る。genTestCD0.sh (bash script) を書いてアルバムアート入り mp3 が出来るか試してみた。gnuplot, sox, eyeD3 の組み合わせだ。「アート」の部分がダサイな、方眼紙に落書きした様なできばえになってる。テストデータだ気にしてはいけない。可変部分をシェル変数で穴埋め式にして、ループで回せば大量生成出来るめどが出来た。
2017.02.12
コメント(0)
昨日の続き、x-アプリ 6.0 が不安定な動作をするので旧バージョンが安定して使えるのか実験する必要がある。旧バージョンの x-アプリ 5.0 を探す。x appli 5.0 でネットを検索すると出てくる。「うーん、なんか怪しい様な」。ダウンロードも何故か遅い。ファイルを拾ってみて、署名を確かめてみる SONY の署名は壊されていない様だ。まぁ、多分確かな物なのだろう。インストーラーを起動すると「このプログラムは互換モードでは実行できません。Windows の互換モードを解除してから再実行して下さい。(エラーコード: 5217)」と出てきた。ある程度は予想できた状況だ。それにしても、ずれたメッセージなのは相変わらずだな。インストーラーの exe ファイルのプロパティを開いて互換性設定をしても、このダイアログが出る。本当の Windows バージョンを何とかして取得しているのだろうな。先のダイアログの前に出る前に UAC ダイアログが出る。この UAC ダイアログにダウンロードしたファイルから展開されたインストーラーが何処にあるかヒントが出ていた。%ALLUSERSPROFILE%\Sony Corporation\Sony Packaging Manager\PackagingTemp\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} だ。恐らく多くのユーザーで %ALLUSERSPROFILE% を展開したパスは C:\ProgramData\Sony Corporation\Sony Packaging Manager\PackagingTemp\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} となるだろう。xxxx の部分は実行毎に変る 16 進数の値だ。GUID を生成しているのだろうな。「互換モードでは実行できません」というずれたメッセージが出ている間にこのパスを辿ってファイル群を拾う。拾ったファイル群にインストーラーがいくつか入っている。手当たり次第に実行していく、次は実行したファイルのメモCommon\DirectX\DXSETUP.exeCommon\Driver\setup.exeCommon\OpenMG\setup.exeCommon\Wmf\umdf.exe このコマンドを実行するための十分な記憶域がありませんCommon\Wmf\wmfdist11.exe このコマンドを実行するための十分な記憶域がありませんCommon\Wmf\WMFDist11-WindowsXP-X86-ENU.exex-APPLICATION\Japanese\Patch\SetupReg.exe 正しくインストールされなかった可能性が有りますx-APPLICATION\Japanese\PrimoSDK\Redist_Win8\pxhpinst.exe 何も起きていないかも?x-APPLICATION\Japanese\PrimoSDK\Redist_Win8\pxsetup.exe 何も起きていないかも?x-APPLICATION\Japanese\PrimoSDK\Redist_Win8\cdr4.inf 右クリック→インストールx-APPLICATION\Japanese\PrimoSDK\Redist_Win8\cdral.inf 右クリック→インストールx-APPLICATION\Japanese\x-Suite\setup.exe 管理者として実行 → 失敗x-APPLICATION\Japanese\x-Suite\main\setup.exe (上と同様)管理者として実行 → 失敗x-APPLICATION\Japanese\x-Suite\JRE\jre.exe 恐らくインストール済みなので飛ばすか、途中でインストール中止x-APPLICATION\Japanese\setup.exe 多分これが本体一通りインストールが終わったら再起動する。再起動後、%ProgramFiles(x86)%\Sony\x-APPLICATION\x-APPLICATION.exe (多くの環境では C:\Program Files (x86)\Sony\x-APPLICATION\x-APPLICATION.exe のはず) のプロパティを開いて、互換性設定をする。ノート: イコライザーを使う場合は、Windows 8 互換設定はしない。互換モードでこのアプリケーションを実行する→チェックを付ける互換モードは "Windows 8" に設定管理者としてこのプログラムを実行する→チェックを付ける必要であれば全てのユーザーの設定を変更でも同様にする「管理者として実行する」理由は CD 取り込みの時にエラーになってしまうのを回避するためだ。x-アプリを起動するとすぐにアップデートするか聞いてくる。これは「後で」で回避する。x-アプリの設定をいくつか変更する。不意のアップデート回避と、安定性のためだ。ツール→設定→ソフトウエアのアップデート→ x-アプリ起動時に、アップデート情報を自動的に確認する→チェックを消すx-アプリの ツール→設定→画面の表示→画面表示の切り替え時のアニメーション効果を有効にする→チェックを消すお願いだ。安定していて欲しい。
2017.02.11
コメント(0)
PC のセットアップを頼まれる。出向いた先で Windows 10 上で x-アプリ(ジュークボックス、携帯プレイヤー同期アプリ)をインストールする。x-アプリ でファイルの取り込みが進んだところで画面がちらつき始めた。描画も正しくなく、画面全体を細かく長方形に切り刻み、モザイクに再構成した様になってしまった。4, 5 時間で終わるつもりの作業が x-アプリ不調のため、12 時間ほど掛かり、未解決のまま作業を切り上げることになった。x-アプリかぁ。まぁ、何だ。何かと絡みが有ったソフトだな。「x-アプリ はこのソフトになる前のシリーズも含め、今だとまともな負荷テストの体制が出来ていないのかなぁ。」心に浮かんだ最初の感想だ。画面のチラツキ方からして、GDI コンテキストを使い果たしたか?(今時そんな問題起こすの?)、Window message を妨害したか?(他のウインドウの描画まで破壊するなんて、何をしているのだ?)、(枠が付いている) Window アプリのふりをして DirectX 経由で全画面をコッソリ支配しているのか?(タチが悪すぎ)、他の Window まで影響を与える様な狂ったパラメータで API を呼んでいる?(普通はある程度チェックするだろうに)。どんな作り方をしているのか分らないソフトだ。おおざっぱな原因しか思いつかない。出向いた先で何か改善出来る調整をして見る。・Windows と x-アプリのアニメーション停止→効果無し・x-アプリのDirectX 使用を停止→効果無し・x-アプリの互換設定を Windows8 と 管理者モード にする→効果無し(再現環境を作っている途中の感触からすると、却って悪化するかもしれない)・DPI スケーリングを 100% にする→効果無し作業の合間、窓から見る空模様も不安定だった。30 秒も経たないうちに見通せた景色は、白く閉ざされ、10m 先も見えないほどの雪が降り、10 分ほどで止む。こんな繰り返しだった。「x-アプリの作りが悪いと思われる状況で、改善策など無いだろうに...何をしようとしているのだ。」心の中で自問している。解決するなら、ソースを直すしかないだろう。そんなの出来る立場じゃない。僅かな可能性としては旧バージョンを見つけ出し、何とか動かしてみることだ。セットアップを頼まれた PC の隣にある Windows Xp の PC で動いているのだ。だとして、出先ですることじゃないよなぁ...もう 22 時を過ぎる。さて、一旦は敗北宣言をしよう。取りあえず、再現調査をすると言って帰ることにした。靴を履き、お邪魔した家の玄関の扉を開けて出るところで、頭の中は再現環境の構築方法を考え始めていた。「同じ環境作れるのかな...音楽・映像データ 100Gbyte 相当」。退職直前に、似た様なテストデータ群生成スクリプトを仕事で書いていた。「あぁ、持ち出していたならなぁ...」、「いやダメだよ。仕事の成果物は全て捨てて出直す覚悟だったんだ。始めから書き直し、超える必要があるんだ。」
2017.02.10
コメント(0)
Free Pascal 3.0.0 向けに書いたソースを実行していたら sem_trywait() が -1 を返した。セマフォを即時で獲得できないことは有る。-1 を返すことは想定できる事態だ。この時 C 言語で言う(厳密には libc) の errno を調べる関数 fpgeterrno を呼び出し、帰ってきた値が ENOTTY "Inappropriate ioctl for device" だった。「は?何が起きているのか?」Free Pascal RTL(Run Time Libraries) の sem_trywait() 関数は直接 libc (glibc) の sem_trywait() を呼び出すように作ってある。glibc の実装を見る限り、sem_trywait() が -1 を返すときは errno は EAGAIN になる。なんだな、sem 引数のチェックはしていないのか...何か複雑なことが起きている?この事象を見るのは 2 回目だ。1 回目は sem_trywait() が EAGAIN 以外を返した事だけ確定していた。sem_trywait() の実装は何かの間違いが起きるような複雑さは無い。だとすると、fpgeterrno が怪しい。単純化したコードを実装してみて、逆アセンブルと Free Pascal の RTL ソースコードを眺めてみる。fpgeterrno の実装を見てみると errno を格納している変数を指すポインタを返す __errno_location() を使っていない様に見える。なんだか怪しいな。Free Pascal の sem_t 構造体の定義も、メンバーは十分なサイズとアラインメントを確保するだけのダミー(ブラックボックス)として扱っていなかったしなぁ...
2017.02.08
コメント(0)
Lubuntu 16.04 live を i815 chipset mother board の on board video で動かせないか作業を続けた。色々と調べてみると、まず /usr/lib/xorg/modules/drivers/intel_drv.so が必要だ。Lubuntu 16.04 には存在する。vesa ドライバではビデオメモリ容量の認識が正しくないらしく、上手く動作しない。ディストリビューションによっては intel_drv.so が無い。USB memory に persistent 領域 casper-rw を設けて、パッケージを次のようにしてインストールしても色々と無理が出てくるらしく、デスクトップ画面は出ない。driver だけではなく xserver 自体が入れ替わって API が整合しなくなる。# apt-get update# apt-get install xserver-xorg-video-allintel_drv.so が有っても xserver 起動中に Segmentation fault が発生する。例えば次のような記録が /var/log/Xorg.0.log に残る。[ 292.536] (EE) Backtrace:[ 292.537] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x52) [0x80247ae2][ 292.537] (EE) 1: /usr/lib/xorg/Xorg (0x800a6000+0x1a5f42) [0x8024bf42][ 292.538] (EE) 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb77c0c20][ 292.538] (EE) 3: /usr/lib/xorg/Xorg (DRILock+0xf4) [0x80214e54][ 292.538] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb6bb1000+0x13a98) [0xb6bc4a98][ 292.538] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb6bb1000+0x14f7b) [0xb6bc5f7b][ 292.538] (EE) 6: /usr/lib/xorg/Xorg (AddScreen+0xed) [0x800e0e1d][ 292.539] (EE) 7: /usr/lib/xorg/Xorg (InitOutput+0x3e7) [0x80127327][ 292.539] (EE) 8: /usr/lib/xorg/Xorg (0x800a6000+0x3ec01) [0x800e4c01][ 292.539] (EE) 9: /usr/lib/xorg/Xorg (0x800a6000+0x2897a) [0x800ce97a][ 292.540] (EE) 10: /lib/i386-linux-gnu/libc.so.6 (__libc_start_main+0xf7) [0xb729b637][ 292.540] (EE) 11: /usr/lib/xorg/Xorg (0x800a6000+0x289b8) [0x800ce9b8][ 292.541] (EE) [ 292.541] (EE) Segmentation fault at address 0x248[ 292.541] (EE) Fatal server error:[ 292.541] (EE) Caught signal 11 (Segmentation fault). Server abortingアクセラレーションが関係する問題を指摘するページを見つける。persistent 領域の /etc/X11/xorg.conf (casper-rw を loopback mount すると ${mount_point}/upper/etc/X11/xorg.conf) を次のように書いて、アクセラレーションを無効にしてみる。 Option "NoAccel" "True" と Option "DRI" "False" が肝だ。Section "Device" Identifier "Configured Video Device" Driver "intel" Option "NoAccel" "True" Option "DRI" "False"EndSectionSection "Monitor" Identifier "Configured Monitor"EndSectionSection "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device"EndSectionデスクトップ画面らしきものが、5 ~ 10 秒に 1 回程度、チラッと出るようになった。[Ctrl]+[Alt]+[F4], [Ctrl]+[Alt]+[F7] をキー入力して仮想コンソール画面 ~[F4] に切り替えた後、デスクトップ画面 ~[F7] にすると、安定してデスクトップが表示された。やや難ありの状態だ。何か設定を詰めれば改善される?scankeylx を古い環境で動かしたいだけなんだ... 何もしないで動くディストリビューションと版を探した方が速いかも。
2017.01.30
コメント(0)
2017.1.31 追記: 継続調査の記録 intel_drv.so と xorg.conf についてLubuntu は軽量で古い(厳密に言えば少ない資源の) CPU や マザーボードでも動作するのが利点だ。scankeylx の動作環境として Celelon 950MHz, 512Mibyte, i815 chipset のマザーボードでテストしてみる。16.04, 16.10 ともグラフィックス画面が出ない。kernel parameter に forcevesa nomodeset を追加するだけでは効果なし。キーやマウスを触ると USB memory のアクセスランプが点滅するので UI に関係する process が動いているのは確かだ。[Ctrl] + [Alt] + [F4] でコンソールを開いてログインとコマンドを入れることができる。デスクトップ関係のプロセスも存在する。「動く」古い版を探すか、kernel parameter をもう少し編集するか、2017.1.30 以下削除 再検証してみて、効果なし一応次の様にして起動できる。・quiet splash を削除・vga=791 を上記削除箇所に追加・--- に続けて forcevesa nomodeset を追加難度が高いな。i815 chipset は一時期「これしかない」と言うくらいに普及した chipset だ。発売開始より 16 年経過している。Linux ではサポート難か。
2017.01.28
コメント(0)
実家で起きている Windows10 の blue screen 問題を調査するため、仮想マシンを作って再現試験をすることにした。インストール履歴を合わせるため、Windows7 professional x64 → 嫌疑のあるソフトをインストール → Windows10 へ upgrade の順で進める予定だ。Windows7 を一通り update する。途中でメモリ不足だと表示された。仮想マシンに割り当てたメモリ量は 2048Mibyte だ。Windows7 のシステム要件は x64 で 2Gibyte だ。足りているはずなのに。仮想マシンのメモリ割り当てを 4Gibyte にして再試行する。Windows Update の記録を見てみると失敗となっていた。慌てて「インストールの中止」をしたのが原因?中止をした後も、指示を無視してインストールを続けて、インストール済み個数が増えていた。Windows update にやり直し分も含めて 1 日以上か... 遠いな。
2017.01.25
コメント(0)
何か現実で見た覚えがあるから、夢で見たのだろうか? 1/22 の起床時に頭に残っていた夢の記憶を書く。VR(Virtual Reality) 向けのクッションの形をしたコントローラーだ。外観はインテリアとして使われるクッションそのものだ。上の下手な絵で書かれた 1 本の食パンの様な形をしていた。どこを触っても、押された位置と圧力情報が入力される。フィードバックは内部の任意の位置が固くなる事だ。アプリの反応を思い出してみると、傾きも検出していたように思う。アプリは VR の子猫だ。目の前の映像はクッションではなく、ゴーグルによって子猫になっている。触ってなでると、気持ちよさそうな表情を見せる。クッション内の固い部分は子猫体内にある骨格や軟骨に皮膚の上から触れるような感覚がある。VR 内の子猫が気持ちよさそうに首を傾けると、その通りに固い部分が変化し触覚が変るのだ。実現性、他のデバイスに比べた優位性はどうだろう?多難なのかもしれない。どうやってデバイスドライバを書いたらよいのかとかは考えていなかったし...アプリが VR の人間とそれに適合したコントローラーだったら...
2017.01.24
コメント(0)
OS キャッシュを通さず SONY MicroSD card SR-16UY の速度を測ったのに続けて、OS キャッシュを通しての速度を測ってみる。Random write のプロットはほぼ OS が管理している cache に格納する動作になった。(rw1), (rw3) の方は書き込み長 1Mibyte まて TAT は 1ms または 2ms となった。タイムスライス間隔なのかもしれない。このことからすると、先のランダム読み出しで 2 筋現れる傾向は OS の動作も原因の可能性有りと考える必要がある。(rw2) の方の筋は cache に書き込んですぐ userland に戻った場合のプロットと言える。デバイスにアクセスしない場合は 2us で処理を終えている。 500,000 IOPS だ。SR-16UY のアクセス時間に対して十分に短いと言える。(rw4)稀にアクセス時間が 10 秒を超えるケースが散見される。組み込み Linux の root file system に使った場合、アプリが稀に応答しなくなる現象が有る可能性を念頭に置くか、書き込みは別スレッドにするなどの工夫を必要とする。Random read のプロットは(rr1), (rr2)の筋がはっきりと出ている。(rr1) の方は MicroSD から読み出している動作だと考えられる。OS のキャッシュを使わない O_BLOCK を付けた 条件で測定したアクセス時間よりも長くなっている。まるで書き込みをしているかの様な access 時間だ。例えば 1Mbyte で 200ms なので 5Mbytes/sec。先行して発行された write access に伴う wear leveling を読み出し要求があった block を積極的に使って行っているのだろうか。ランダムに read したブロックがすり減り (wear) 度合を平均化するのに丁度良い block とは限らないと思う。MicroSD 内で動いているアルゴリズムはどうなっているのだろうか。(rr2)の筋は OS の cache read だろう。転送長 1kbyte 付近でアクセス時間は 1us を切っている。(rr3) に要注意あるいは、組み込み Linux の root file system として使った場合、致命的な不具合を起こす傾向が現れている。read access 時間が 100 秒に迫る結果がいくつかプロットされている。ランダムアクセステストの生データ調べてみると、アクセス時間が 200 秒を超える場合が 5 回あった。下の表をクリックするとテキストでアクセスできる表を表示できる。Linux は Userland process が 120 秒以上割り込み不可状態を維持すると(see. /proc/sys/kernel/hung_task_timeout_secs)、hung_task_panic が 1 の場合 panic してしまう。panic が起きなくても、プロセスが 100 秒以上止まるのだから、ハングアップと思われてしまうような処理遅延、取りこぼしが起きる。高負荷でしか起きない現象か?自分の経験からすれば、このような傾向を示す Flash memory storage は低負荷でも何かの拍子で access time が 100 秒以上になってしまう事が有った。「何かの拍子」と言うのが厄介だ。アクセス順に付けた index をキーに先の生データを精査しても、アクセス時間を長くしてしまう規則性を見いだせない。MicroSD で access time が異常に長くなる傾向が有る品種は結構ある。SR-16UY も root file system を格納する用途は想定していないと思われる。テストしてみてふるい分けるしかない。そうだ、MicroSD に書き込んですり減らすのが目的ではなく、使うことが目的なんだよな...
2017.01.20
コメント(0)
久しぶりに MicroSD card を買ったので速度測定をしてみる。SONY SR-16UY だ。まぁ、何だ、自分自身にとっての「解禁」(あれから 1 年経ったんだよな)という背景もある。パッケージは MicroSD の大きさと対比してかなり大きい。うーん、販売店さん扱いたがらないだろうな。浜田電機で買ったときはコンテナボックスに放り込まれてた。MicroSD - 標準 SD Card アダプタが付いている。印刷が不鮮明に感じる。より鮮明なマーキングができているメーカーもある。はげ落ちるような様子は無いので、性能には全く関係がないか...アダプタの端子面を見てみる。母材の表面仕上げの目地が分る程度の金メッキだ。メッキが薄くて不具合を感じたことも無いのでこれで良しなのかもしれない。一部の端子は引っかかりを防ぐために角丸め(斜めカット)を入れてある。細かい改良はある。MicroSD カードを見てみる。マーキングのフォントに入念な模造品対策が有るようには見えない。"16 GB" の辺りくらいか。MicroSD の端子メッキは厚い様に見える。くすみ、地の模様は認められず。恐らくは OEM メーカー、仕上げを入念に選定・指定していると思われる。性能を見ていこう。性能測定に使ったツール ssdtest 2.00 (ソースコードダウンロード)は自前の物だ。Linux で性能測定をするため ext4 でフォーマットしなおしている。/dev/sdc としてカードが認識されたとして次のようにファイルシステム作成、マウントを実施した。# mkfs.ext4 -L SR_16UY_91726340 /dev/sdc1# mkdir -p /mnt/sdc1# mount /dev/sdc1 /mnt/sdc1USB bus の転送性能を上げるため、USB Mass Storage Class プロトコルで 1 度に転送するセクタ数を 2048 (1Mibyte) にする。接続は Super Speed だ。# echo 2048 > /sys/block/sdc/device/max_sectorsテストとグラフ作成は先の ssdtest 2.00 ツールを使って次のようにした。# cd ${work_base_directory}/ssdtest_2.00# ./ssdtest_light_usbmems.sh /mnt/sdc1# cd log-SR_16UY_91726340-170114134639-12519m# ../plotlogseq_uhs1.sh -L "SONY_SR-16UY_91726340"# ../plotlogmix_uhs1.sh -L "SONY_SR-16UY_91726340"# ../htmlplot.sh -L "SONY_SR-16UY_91726340" > index.htm結果のグラフを見ていく。(sw1) Sequential write の結果は ほぼ 10Mbytes/sec 出ている。パッケージに示された性能通りだろう。(sw2) 突発的な転送速度の低下がある。他の SD card でも見られる現象なので大きな問題にはならない。(sw3) 辺りで連続的な速度低下現象になり掛かっている。これも高頻度で起きていないので、問題とは考えていない。動画録画、連続撮影で 6Mbytes/sec (48Mbits/sec) 程度に抑えて使うなら、ほぼオーバーランで録画・撮影が途切れる心配は無いと言える。事務で出先のプレゼン用にフォルダ毎コピーして MicroSD に格納する様な作業で、偶に異様に待たされる様なことは無いだろう。(sr1) Sequential read の結果はほぼ 60Mbytes/sec 出ている。パッケージに示された 40Mbyte/sec は余裕でクリアしている。余裕分を含んでいるのは、書き込み量が増えてきた場合でも表記性能を維持するためだろうか?MicroSD にあるファイルを丸ごと PC にコピーする作業もスムーズであろう。O_DIRECT を付けた(すなわち OS のキャッシュを無効にした) Random access test 結果を見ていく。write のグラフに興味深い傾向が有る。(attl1) 転送長が 512 byte (1 block) の時だけ突出して access time が短い場合が観測されている。Erase block 単位で書き込んでいる最中に追加で書き込み要求が来た場合、「追加で差し込んでいる」のだろうか?それとも、ベンチマーク対策で 1 block write request だけは cache 書き込みで complete して、Flash memory への書き込みは後回しなのだろうか?この場合の電源断対策はできている? (attl2) TAT(Turn Around Time) は 2.5ms 程 IOPS 換算で 400 IOPS となる。MicroSD ならまずまずの性能だろう。(attl3) アクセス時間の分布からみて、内部の Erase Block は 256Ki byte か。(attl4) 書き込み時間のブレが大きい感が有る。10Mibyte 連続書き込みをしても、ランダムアクセス中ならば 10 倍以上の性能差ブレがある。組み込み Linux の root ファイルシステムを配置するには少々不向きか(調査結果は別に纏めよう)。Random access test の read を見ていく、(attl5) read の TAT は 550us ほど、IOPS 換算で 1800 IOPS だ。まずまずの性能だろう。(attl6) 内部構造あるいは処理由来の筋が出ている。Weare leveling の統計処理か、Error Collection 処理か。(attl7) read 時でも書き込みに相当する時間が掛かるケースが多く見られる。random access test は read/write 混在で行っている。先行した write が完了するまでの待ちなのか。だとすると、Flash memory 書き込み完了前に complete している (USB の CSW 返信が起きている) ことに、それとも read 時でも wear leveling あるいは scrub (エラー訂正が多い場合に書き戻しをする) を積極的に行っているのか。(attl8) 先の (attl7) とも関係する事で、read request を効率的に行おうとすると 1 度に 500kbyte 読んでも 応答時間に 10 倍の差が出る事があり、動画・音楽再生をアンダーラン無しに行おうとするには、より長く先行読み出しをする必要がありそうだ。SD card driver(MMC) ドライバが良くできていれば、先行読み出し長を長くすれば動画・音楽再生でアンダーランを起こしにくくなるだろう。ドライバに busy polling, udelay(), mdleay() 等の CPU 空走ループがある場合は、長い転送はかえって状況を悪化させる。ここまでのテスト結果からすると、動画撮影の記録、デジカメ撮影画像の記録、プレゼンなどで出先へファイルを持ち出す/出先からファイルを持ち帰る場面で満足のいく性能(使用感)が得られそうだ。高音質 MicroSD だと何か違うなかなぁ...2017.1.20 追記: OS の cache を通してアクセスした場合の結果
2017.01.17
コメント(0)
qemu-nbd (Network Block Device mount/unmount) にある vhd ファイルが 136Gbyte まで(137Gbyte までとも言われる)の容量に制限される問題は最新の QEMU では解消されていた。ソースを弄らず解決できる。QEMU のダウンロードページに示されている通りに、QEMU のソースリポジトリを git clone して build する。install するつもりが無い場合は prefix は適当に --prefix=/usr/local で良い。raspberry pi3 上では libfdt-dev が無いので $ sudo apt-get install libfdt-dev をしてから $ ./configure --prefix=/usr/local; make -j 並列数 する。他に無いライブラリが有ったとして $ sudo apt-get install 無いライブラリ-dev でインストールしていけば良い。raspberry pi3 上では make -j 4 でも 2 ~ 3 時間はかかるだろう。block/vpc.c:vpc_open() 関数内の次のあたりが、vhd ファイルを CHS 制限付きで開くか、32bit sector (約 2Tbyte 制限)で開くか決めているロジックに見える。use_chs = (!!strncmp(footer->creator_app, "win ", 4) && !!strncmp(footer->creator_app, "qem2", 4) && !!strncmp(footer->creator_app, "d2v ", 4) && !!strncmp(footer->creator_app, "CTXS", 4) && !!memcmp(footer->creator_app, "tap", 4)) || s->force_use_chs;構築したバイナリはインストールしなくても、そのまま $ sudo ./qemu-nbd -c /dev/nbd0 virtual-pc-hdd0.vhd の様にして実行できる。NBD (Network Block Device) の問題だけ解決したかったのでインストールはしなかった。ソースは 2 日読んだ。解決はビルド 3 時間だった。
2017.01.05
コメント(0)
2017.1.5 追記: 最新の QEMU を build して解決したqemu-nbd で VHD ファイルを mount すると BIG Drive (136Gbyte) の制限が掛るので調査を始める。一通り global に掛けてみてソースコードの構造を大まかに把握できるようにする。野良サーバーにリモートでログインして、http で global で作ったページを実家から読める様に仕立てた。実家から野良サーバーの web ページを読み始める。block/vpc.c が VHD ファイルの仮想ドライバだと読めた。マクロに VHD_CHS_MAX_C, VHD_CHS_MAX_H, VHD_CHS_MAX_S がある。BIG Drive 制限に関係しそうな定数だろう。何度かザット読み流してみて、「思い当たる」定数、関数、データ構造を頭の中に整理せずに散らかしておく、自分の頭にいきなり深く理解出来るような良さは無い。多分何かのオプションを使えば簡単に制限が外せるような仕掛けがあるかも。
2017.01.02
コメント(0)
管理組合の用で持ち歩いていた USB プラグ型 MicroSD card reader を見せたら珍しがられた。そんなに珍しいものだった?上の画像を撮影した年月日は 2009/3/27 だ。 7 年以上前だ。自分にとってはよくある PC 接続ガジェットだった。全ての人に勧められない。小さい子供がいる家庭では飲み込み事故の危険がある。珍しく思った人は、形と機能をみてその利便性は直ぐに理解していた。パッケージに書かれている通り、USB 接続口からの出っ張りが気にならず、無理な力が掛かりにくい。Micro SD が丁度良くプラグの口に入る。知られていれば買ったのかなぁ。チューインガム、あるいは消しゴム形状の USB メモリが多く出回ると、それで USB メモリはそういう形の物だと思われてしまうのだろうか?
2016.12.27
コメント(0)
Free Pascal で書いた scankeylx のソースをデバッグしていた。デバッガで追いかけると malloc() で SIGSEGV (segmentation fault)だ。そうか、Free Pascal でもアロケーターは malloc(), free() なのか。厄介だな。多分別の所の書き間違いが原因だ。気のまぐれで例外を raise しているところから逆アセンブルを見ながら追いかけ始める。何か奇妙な動きだった。補足した例外を再生成せずに raise e; として投げてしまっているのがダメだった。まだ自分には Object Pascal の挙動で知らない所があるのか。raise Exception.Create(...); の様にして例外を再生成して SIGSEGV は発生しなくなった。try CallMethodMayRaiseException; ... except on e:Exception do begin CleanUpMess; raise e; (* This will cause SIGSEGV or some strange exception in memory allocator (ex. malloc()). *) (* So It should be written as follows. *) raise Exception.Create(...); end;end;もう一つ別の問題(というよりは怪しいところ)も見つける。opendir(), readdir64_r(), closedir() を libc で提供している関数群を直接使うようにした。ちゃんと動く様になったんだよな... きっと...
2016.12.23
コメント(0)
メインから退いた Windows Vista マシンのマザーボードとハードディスクを使い勝手が悪いケースに移し終える。退いたマシンにはバックアップを保持する目的がある。HDD 3 台、SSD 1 台を抱えている。収入があったときには、HDD も SSD もそのままにして、単に新しい HDD を買っただろう。今はそうも行かない。3Tbyte 1 台を捻出する事にした。バックアップ保持の目的と相反する。ダウンロードしたファイルを消していく。手元に残る複製数は 4 から 3 へ減る。仮想マシンイメージを別マシンへ移転する。移転先で仮想マシンが動くところまで確認。この 1 年、自分が使える時間は大いに増えた。消したファイルを 1 年で何割見ただろうか? 容量で測るなら 1% も見ていない。 移転した仮想マシンを何分動かしただろうか? 全部で 1 時間にも達していない。複製を持ち続けることが目的化している。作業中に移し替えで問題が発生していないか、動作確認を進める。不調だ。(1) ログオンすると「タスクスケジューラーエンジンは動作を停止しました」。(2) Explorer から DLL 呼び出す(例えば フォトビューアー を起動する)と、explorer.exe が強制終了してしまう。(3) Microsoft Security Essentials の更新がいつまでも終わらない。(4) Windows Update もいつまでも終わらない。(1) は修復方法見つからず、(2) も修復していない。(3) は Microsoft Security Essentials を再ダウンロード、インストールして解決した。更新情報を配布しているサーバーアドレスが変ったのか? (4) は「Windows Vista Windows Update 終わらない」で見つかる情報を元に対応、個別に updater を適用するのも同様に時間が掛かり 1 日以上必要だった。修復できない不調はそのままかな...
2016.12.19
コメント(0)
今年 7 月まで現役だった Windows Vista PC のマザーボード、ハードディスクを別の使い勝手が悪いケースへ移し替える。性能に全く変化がない作業だ。「移し替えたら何かイイこと有るのだろうか?」作業の手を鈍くする魔法の言葉が頭をめぐる。「うん、あるさ、きっと...」一応、待機系サーバーの組み直しを考えている。待機系とは言うものの、常時 4 ~ 6 台の仮想マシンを稼働させていて、外付け HDD が 4 台、内蔵 HDD が 2 台の大所帯を mini ITX ケースで抱えている状態になってしまった。配線が多く、安定性に難がある。mini ITX ならではの低消費電力も、多数の AC アダプタと USB-HDD bridge, USB HUB で帳消しだ。メインで使っていた使い勝手が良いケースで再構成しようというのが、目論見(のはず)。こんなことが始まったきっかけ?そう言えばまだ書いていなかったか...
2016.12.18
コメント(0)
2017.2.21 追記 Acronis Trueimage アンインストールでブルースクリーン頻度低減実家に出向いて Windows 10 に upgrade した FMV AH45 の調子を見に行く。相変わらず BlueScreen が頻発する。色々とドライバを入れ替えて様子が変らない。何か情報が足りていない気がする。Windows 10 のあっさりしたブルースクリーンではなくて、レジスタダンプがゴチャゴチャ付いた画面相当の情報が欲しいのではないか? BlueScreenView で今度見てみるか。そもそも、正解を知らない。どうすれば知ることが出来る? Windwos10 をクリーンインストールしてみる。新しい SSD か HDD を取付けてみて、Windwos10 をインストールしてみる。デバイスマネージャーでインストールされたドライバを見てみる。ほぼ強制的な upgrade キャンペーンから半年、Windows update では何も解決しなかったな。
2016.12.10
コメント(0)
Raspberry Pi3 上で Free Pascal 3.0.0 と Lazarus 1.6.2 を動かしてみた。ソースを取ってきて構築する。Raspberry Pi 3 に Free Pascal 3.0.0 と Lazarus 1.6.2 をインストールする に詳細な手順と制限事項をまとめておいた。パッケージを上書きしてしまうと何かと苦労しそうなのでインストール先はホームディレクトリ /home/pi の下にしてある。Raspberry Pi3 以外のターゲット、PC 上の Ubuntu 14.04, Ubuntu 12.04 でも大きな手順の変りはないので参考にできるはず。scankeylx の開発環境を FPC 3.0.0 ベースにするので自分も使う。ARM ターゲットでも FPC 2.6.4 に比べ FPC 3.0.0 はオブジェクトコードの質が良くなっている。一目で「無駄だなぁ」と目立つ部分は無い。さて、環境弄りから開発作業に戻らないと。
2016.12.09
コメント(0)
scankeylx を Raspberry Pi3 で動かしていたら、Desktop の右上に温度計が表示された状態でハングアップしていた。Desktop(Keyboard, Mouse), VNC, SSH 接続, ping 全て応答なし。USB 接続したハードディスクを直接スキャンしている状態ではない。次のようにして、仮想ストレージをマウント(厳密には block device として attach している)してテストしている。nbd は Network Block Device だ。# modprobe nbd# qemu-nbd -c /dev/nbd0 virtual-storage-file.vhd高圧縮率でデータパターンが単純な範囲の検索速度は 200Mbye/sec に達する。再起動してログに残っていないか見てみる。 sudo journalctl --system で見ても何も記録なし。systemd-journald はいまいち信用できないなぁ。Kernel log はやっぱりシリアル出力なのか。nbd に big drive (136Gbyte) の制限がある模様、250Gbyte や 500Gbyte の仮想ドライブを attach しても容量は 10 進数表示で 136.9Gbyte, 1024 単位で表示して 127.5Gibyte になる。Kernel source を見てみるか。2017.1.5 追記: 最新の QEMU を build して解決したうーん、ARM ターゲットのサポートをどうするべきか。scankeylx はオーバーヒートで壊す恐れがあるアプリ?
2016.12.07
コメント(0)
scankeylx を x86_64 (64bit) 対応にする作業のうち、「コンパイルできない」、「実行結果が異常になる」などのソースコードの記述に由来する問題は解消した。Raspberry Pi3 (ARMv7) 環境ではまだ要修正だ(放置しても大きな支障はない)。64bit 対応すると実行速度が 1 割ほど低下する。scankeylx は複雑な演算はしていない。8bit と 16bit 単位の文字・パターン検索・操作が主なので CPU の語長が 32bit から 64bit になることは大きなメリットにもマイナスにもならない。厳密にいえば CPU - Memory 間のバンド幅は大きい方が良い。生成されるオブジェクトコードの質なんだろうな...気になるので良いオブジェクトコードが生成される様にソースを弄っていた。Free Pascal Compiler(FPC) 2.6.2-8 ではどうにもならない。最も高頻度に回るループ内側の処理を抜き出してみる。FPC 2.6.2-8 で次のようなオブジェクトコードになった。r14d から eax に比較毎にレジスタ間転送が行われている。色々と書き換えてみて消せなかった。eax を使うのはソース上では cardianl 型変数を使っているからだ。byte 型変数にするとさらにコードは悪化する。FPC 2.6.2-82944: 0f b6 03 movzbl (%rbx),%eax2947: 41 89 c6 mov %eax,%r14d294a: 44 89 f0 mov %r14d,%eax294d: 83 f8 30 cmp $0x30,%eax2950: 72 dc jb 292e <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xe6>2952: 44 89 f0 mov %r14d,%eax2955: 83 f8 73 cmp $0x73,%eax2958: 77 d4 ja 292e <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xe6>295a: 44 89 f0 mov %r14d,%eax295d: 83 f8 39 cmp $0x39,%eax2960: 0f 86 f7 02 00 00 jbe 2c5d <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x415>2966: 44 89 f0 mov %r14d,%eax2969: 83 f8 44 cmp $0x44,%eax296c: 72 c0 jb 292e <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xe6>296e: 44 89 f0 mov %r14d,%eax2971: 25 df 00 00 00 and $0xdf,%eax2976: 41 89 c6 mov %eax,%r14d2979: 44 89 f0 mov %r14d,%eax297c: 83 f8 44 cmp $0x44,%eax297f: 74 25 je 29a6 <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x15e>2981: 44 89 f0 mov %r14d,%eax2984: 83 f8 4c cmp $0x4c,%eax2987: 0f 84 1d 07 00 00 je 30aa <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x862>298d: 44 89 f0 mov %r14d,%eax2990: 83 f8 50 cmp $0x50,%eax2993: 0f 84 f3 03 00 00 je 2d8c <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x544>2999: 44 89 f0 mov %r14d,%eax299c: 83 f8 53 cmp $0x53,%eax299f: 75 8d jne 292e <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xe6>29a1: e9 45 06 00 00 jmpq 2feb <SKLXTHSEARCH_TTHREADSEARCH_$__SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x7a3>うん、コンパイラを変えよう。Ubuntu 16.04 で FPC 3.0.0 を使ってみる。ソースを書き換えて byte 型変数を使ったところで、「こんなオブジェクトコードになるはずだよな」に近いコードになった。FPC 3.0.0 e0: 44 8a 33 mov (%rbx),%r14b e3: 41 80 fe 30 cmp $0x30,%r14b e7: 72 e3 jb cc <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xcc> e9: 41 80 fe 73 cmp $0x73,%r14b ed: 77 dd ja cc <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xcc> ef: 41 80 fe 39 cmp $0x39,%r14b f3: 0f 86 8a 02 00 00 jbe 383 <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x383> f9: 41 80 fe 44 cmp $0x44,%r14b fd: 72 cd jb cc <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xcc> ff: 44 88 f0 mov %r14b,%al102: 24 df and $0xdf,%al104: 41 88 c6 mov %al,%r14b107: 41 80 fe 44 cmp $0x44,%r14b10b: 74 1f je 12c <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x12c>10d: 41 80 fe 4c cmp $0x4c,%r14b111: 0f 84 7f 06 00 00 je 796 <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x796>117: 41 80 fe 50 cmp $0x50,%r14b11b: 0f 84 7e 03 00 00 je 49f <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x49f>121: 41 80 fe 53 cmp $0x53,%r14b125: 75 a5 jne cc <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0xcc>127: e9 9f 05 00 00 jmpq 6cb <SKLXTHSEARCH$_$TTHREADSEARCH_$__$$_SEARCHMAIN$PBULKBUFFER$$BOOLEAN+0x6cb>普通にレジスタ割り付けができて、ほぼ冗長な転送を消す最適化が行われていた。ff..104 の間の演算に冗長な部分が残る。演算結果を al に必ず保持する強いルールがある?Ubuntu 16.04 でコンパイルしたコードは Ubuntu 12.04 では動かない。もう一つ壁を乗り越えないと。
2016.12.03
コメント(0)
scankeylx を ARM ターゲット(Raspberry Pi 3) で動かそうとしている。基本的なスキャンは動作しだした。Raspberry Pi 3 の Linux には /proc/scsi/scsi ノードがない。え?そもそも Raspberry Pi 3 に SCSI ってあるのかって。USB 接続のストレージ(記憶装置ドライブ)は SCSI デバイスになる。/proc/scsi/scsi から接続したストレージの型名などを採取して、表示し、検索対象のストレージを選択しやすいような UI を作っていた。これが出来なくなった。Raspberry Pi 3 は小型の組み込み機器だ。ストレージを探すほど大量のデバイスを繋ぐ状況はほぼないだろう。USB ポートに繋いだ USB メモリと、USB ハードディスクを区別できればよいのだ。容量表示で十分だ。ノードが無い場合を致命的なエラーにしなければキー検索をできることも分かった。非常に簡単な修正だ。例外を捕捉して「握りつぶせば」良い。問題が起きないよう、変数初期化、リソース解放を丁寧にするコードを追加しても 10 行ほどしか増えない。下した結論は /sys/class/block/sdx/device/* 以下のノードを使うことにした。最も面倒な対応だ。model, vendor, vpd_pg80, vpd_pg83 の 4 つのノードから情報を採取する。model, vendor はテキストだ。簡単? 実装を始めてみると、エラーが起きた場合の「耐性」に作りこみが必要だ。vpd_pg80, vpd_pg83 は Linux Kernel ソースコード読むと INQUIRY で PageCode 80h と 83h を使って得られた結果だとわかる。SCSI 仕様書を見ながら実装開始、構造体を作り丁寧にフィールドを拾っていく。SCSI 仕様から実装するの大変なんだよな。仕様の版が上がるたびに発生する変更を上手く捌き、デバイスが誤解や先行実装により仕様から外れた挙動をする場合を想定する必要がある。気付けば 3 重ループくらいでパーサーを書いている。
2016.12.01
コメント(0)
scankeylx を Raspberry Pi 3 (ARMv7) アーキテクチャ上でコンパイルして動かしてみることにした。/dev/sda や /dev/sdb を開こうとして "Not a directory" (ENOTDIR) エラーになった。うん、確かに /dev/sda は directory ではない。何で分ったようなエラーになるんだ?他のツール dd だって open 出来ているし。暫く悩んでいた。また変なメモリ破壊とか...色々と悩んで、strace で様子を見ることにした。open() system call のトレースに O_DIRECTORY が付いていた。え?ソース書き間違えた?ソースは O_DIRECT と書かれている。何かが違う。Free Pascal の RTL (RunTime Library) ソースコードを見ても、変な再定義は無し。x86 上の fcntl.h, ARM 上の fchtl.h, ARM64 上の fcntl.h を見比べてみる。O_DIRECT と O_DIRECTORY の値が違っている。x86 上の O_DIRECT の値 040000 を使うと ARM 上では O_DIRECTROY になる。最も良い解決は Free Pascal の RTL source を修正することなんだよな、きっと...O_DIRECT を再定義する定数を用意して、解決するか試してみる。あー、PowerPC とか SPARC も違いがあるのか。対応するコードは書いてみたけれど、試すことができない。ARM 上の動作は意図したとおりになった。アーキテクチャ毎に Linux kernel system call の定数が変るなんて有るんだ。うぅ、まだ動かないねぇ。
2016.11.30
コメント(0)
scankeylx 64bit 対応とマルチプラットホーム化を続けていた。なんとなく体温が高い状態だ。14 時頃に 36.8 ℃だった。今日も外には出ず。ノート PC のメモリ買い出しは別の日にするか...(こんな時に限って円安進行なんだよね)ちまちまと libc unit を使っている部分を書き直していた。コンパイルが通るようになる。ソースが荒いところを直していった。未使用のユニットとシンボルを削除、スコープ限定子を使い曖昧さを無くしていった。こうやって見直してセルフコードレビューをする。git commit と push を済ませて実行させてみる。SIGSEGV 例外、スタックトレースを追ってみると、どうも Free Pascal の文字列操作に関係する組み込みライブラリで発生している。スタックの底は FormCreate だ。メモリに意図しない書き込みをしていると予想する。SIGSEGV になる命令ではなく、遥かに遠い場所で問題を起こしている可能性が濃厚だ。マズイ、一番デバックがしにくい出オチだ。何かしたら例外発生なら、追い込みやすい。何もしないで例外だ。git の diff を見ていく、どこに誤りがあるのか。debug branch を切って revert をしてみる。まぁ、敗北感というか。一人で git 開発なのにブランチツリーが分枝しだす。結局深夜を回るデバック作業になった。もう寝よう。SIGSEGV の解決は翌日 11/28(月) になった。逆アセンブラレベルでステップ実行をしていると localtime_r() を呼び出した後、ローカル変数の値が期待とは違う値になっていた。奇妙に意図的な値で違う。なんで?意図する構造とは違うメモリ書き込みをしている。localtime_r() に何か見落としがある。/usr/include/time.h を読み直してみる。マニュアルページと違う。__tm_gmtoff, __tm_zone メンバが追加されていた。man localtime_r の struct tmstruct tm { int tm_sec; /* seconds */ int tm_min; /* minutes */ int tm_hour; /* hours */ int tm_mday; /* day of the month */ int tm_mon; /* month */ int tm_year; /* year */ int tm_wday; /* day of the week */ int tm_yday; /* day in the year */ int tm_isdst; /* daylight saving time */};/usr/include/time.h の struct tmstruct tm{ int tm_sec; /* Seconds. [0-60] (1 leap second) */ int tm_min; /* Minutes. [0-59] */ int tm_hour; /* Hours. [0-23] */ int tm_mday; /* Day. [1-31] */ int tm_mon; /* Month. [0-11] */ int tm_year; /* Year - 1900. */ int tm_wday; /* Day of week. [0-6] */ int tm_yday; /* Days in year.[0-365] */ int tm_isdst; /* DST. [-1/0/1]*/#ifdef __USE_BSD long int tm_gmtoff; /* Seconds east of UTC. */ __const char *tm_zone; /* Timezone abbreviation. */#else long int __tm_gmtoff; /* Seconds east of UTC. */ __const char *__tm_zone; /* Timezone abbreviation. */#endif};time.h が正しいのだ。修正して __tm_gmtoff, __tm_zone がそのメンバ名に相応しく動作することを確認する。余計にいじったところを元に戻す。debug branch を伸ばす。man page を信じるなんて魔が差したな... Use the Source, Luke!
2016.11.27
コメント(0)
scankeylx 64bit 対応とマルチプラットホーム化を始める。頭痛でボーっとしている時ほど面倒なことを始めてしまう。i386 専用のアセンブラコードを使わない代替コードは直ぐに用意できた。ソースレベルでの最適化は十分ではない。検索速度が 1 割低下する。いずれは x86_64 向けのアセンブラコードを追加するのかな... 検索結果に相違が無いか確認する。バグを見つけて修正、結果に相違なし。lazarus の project/compiler options/Build modes によるコンパイル条件切り替えの方に手間取るくらいだ。調べてみると project/compiler options/Build macros/Conditionals の中に簡易 PASCAL コードを書いて CustomOptions+='-dCOMPILE_CONDITION'; の様に書く。参考: Macros and Conditionals, "Changing compiler options with conditionals", "Conditionals syntax"。なんだ、意外に順調?だとしてなんでマルチプラットホーム化を今までしなかったのか?(多分開発経緯を忘れているな...)ここまでは i386 アーキテクチャ上で緩やかな移行作業だった。ソースコードを x86_64 に持っていく。やることは git clone 位だと思っていた。躓きだした。そうだ、i386 以外では unit libc が使えない。libc が持つ定数、型、構造体、関数を多く参照している。頭が痛いのは i386 上て LARGEFILE (と 2Tibyte 越えのボリューム・ファイルシステム) を扱うため、64bit 対応化 systam call や libc の section 3 関数を使っていることだ。section 3 関数を使う理由は他にも有った。/usr/include と Free Pascal の RTL を睨めっこする作業が始まった。いくら見ていても埒が明かない。単体テストコードを投入して様子を確かめる。型の確認、関数名の確認、構造体のメンバサイズがどの様になるか、libc で提供している引数と system call 界面のパラメータの差を確認、面倒な作業が始まる。ああ、statfs64() は system call 界面では buf のサイズを示す引数が増えて 3 つなのか。Kernel source code まで見ていた。libc と dynamic link する関係は保てているだろうか? objdump -T の結果を見て奇妙な不安が過る。一部の関数でも static link すると、open source に必ずする必要がある。「なんで、ソースコード公開義務を不安に思っているのだろう?」、「将来的な軸足の置き方に自由がほしい?」、「だってディスク全面を舐めるプログラムがソース非公開なんてあり得ないだろう...」、「GPL を心配したところで結論は変わらないではないか。」こんなことを悶々と思うと頭痛が増す。コード修正は収拾が付かなくなっていた。build break で commit しよう。ゴチャゴチャの状態でも「戻れる」、「途中から始められる」ポイントがある方が重要だ。昼寝だよ、本当に今日必要な作業は。
2016.11.26
コメント(0)
scankeylx のサポート依頼のメールを受ける。ubuntu 16.04 x86_64 で使用を試みた様だ。ubuntu 14.04 i386 までを実行環境としている。一応状況確認のため、ダウンロードから始める。ubuntu 16.04 から x86_64(amd64) がメインのターゲットだ。しかも i386 バイナリは「態と」と思えるほどどうやってダウンロードしたらよいか分からなくなっている。サポート作業量を考えると x86_64 ターゲットでビルドした方が良い。付け加えるならば、i386, x86_64, arm(ある程度の有名プラットホーム) 向けにバイナリを用意した方が良さそうだ。ELF を別々にするか統合して FatELF にするか。テスト工程が増えるな...
2016.11.24
コメント(0)
gmail アカウントを outlook 2007 に設定した後、Windows 10 PC がスリープしなくなった。Windows Vista PC でもスリープしない現象に悩んでいた。gmail サーバーとの同期に時間が掛かるのが原因らしい。同期中はスリープできない。「スリープ可」の問い合わせに対して outlook がスリープ不許可の回答を返しいつまでもスリープできない状況に陥っている。見ていると同期には 1 分以上掛かっている。mail 問い合わせ間隔が 3 分以下だと顕著に現象が現れると思われる。殆ど同期中になる。他にも都合が良くないことがあり、gmail を outlook で受け取るのは止めることにした。gmail サーバーの応答が遅いせいで世界中で電力消費が上がっている?
2016.11.21
コメント(0)
前回の対応から 14 日ほど経過し WD7500BPVT が再び不調になった。これ以上繰り返すと手間がかかる。別のハードディスクにコピーして退役させることにした。新しく買わず、何とか遣り繰りする。WD7500BPVT を組み込んだハードディスクケース OWLTECH 黒角 MINI OWL-ESL25S/U3 の癖も分かってきた。このケースに使われている ASM1053 (USB-SATA ブリッジ) を制御するファームウェアはドライブに Medium Error があるとハングアップしてしまう。USB Bus Reset が効かない状態に陥っていると思われる。ケースも何が起こるか分からない出先、使用済みでしばらく寝かせていたハードディスクに使うのは避けた方が良さそうだ。ケースも常用から一時使用に転向することにした。シールを貼って使用上の注意を記入する。まだ予備の 2.5 inch HDD がある。買いたい症を抑えなければ。
2016.11.17
コメント(0)
管理組合関係で受け取る電子メールの傾向が変わってきた。HTML メールで本文文書に色を付けているメールを受け取ることが多くなってきた。HTML を使用するのは想定していた。本文に色がついているのは予想外だった。ほぼ 1 色ですべて書かれている。タイトルを強調するとか、文書の構成に基づいた装飾はない。どういう意図があるのだろうか?黒に近い色ではない。書いているときに色がついていることは容易に気づける。目立たせるためだろうか?目立たせるためだとして、ソフト開発の仕事で普通に使われているルールとはずいぶんと違う。Subject に [] などの括弧記号で文脈・内容分類を囲むルールを使う人は皆無だ。メーラー(MUA) の分類(色付け、フォルダ分け)をしようにも出来ない。メーラー(MUA) の分類を活用していないのだろうか? Outlook ならアドレス帳から連絡先をダブルクリックして、分類を選ぶと差出人によりメールリストに色の印をつけることができる。色が少ないので分類に苦労するかもしれない。写真を入れたりすることもできるので目立たせる方法は他にもある。仕事では「仕分けルールと通知」を普通に使っていたんだけどなぁ。受け取る側の工夫次第なのがダメなのか。Outlook の新規メールウインドウを開いて色々と考えてみる。あぁ、本文にキャレットがある状態で「オプション」→「ページの色」→「塗りつぶし効果」→「図」→「図の選択」でメールの背景画像が設定できるのか。薄い地模様(磁気定期券や商品券の背景にある模様のようなもの)なら、さほどレイアウトづくりに苦労せずに、強い主張もなく差出人や内容が目立つか。多分これが普通の人のやり方なんだろうな。
2016.11.14
コメント(0)
天気予報では午後から雨が上がり、曇りになるとの事だった。15 時くらいになっても、小雨が続いていた。Web サイトからアクセスできるレーダー画像には確かに雨が映っていない。これで記録的には曇りということ? 色々と出かける都合は諦めた。php のソースを弄る 1 日になった。すっきりと読下せない。元のソースを書いた人の技量不足が読解を難しくしている。こう言うと失礼なのかな。定型的な式が良く使われている。よく見ると後に続く処理に相応しくない型を変数に入れている。あるパターンだと、必ず定型の式や構文を当てはめて、適合性は考えていないようだ。自動型変換万歳。入力長 N 文字に対して O(N^2) になるような文字列処理が多用されている。どうも、見ていると php の内部処理には無頓着だ。substr() のような文字列操作関数のオーダーを気にしていない。何度も同じ式を評価している。細かく読んで同じ式なのか、違う式なのか読下す必要がある。先の点と同様にループ内不変式をループ外に追い出していない。いずれコンパイラやインタプリタが最適化するから気にしなくても良いのでは?という意見もあるだろう。自分は書いた人が理解できているのなら、ループ内不変式は手でループ外に追い出してほしいと思っている。ループ内で何が変わり、何が変わらないのか、明確になっていれば読解で集中すべき式(それは繰り返しで結果が変わる式)が減る。そういえば、退職前の職場に配属された新人にも似たような感触があったな。単なる世代の差?
2016.11.11
コメント(0)
退職前に書いていたソースコードが機能する製品が発表された。発表後直ぐに書くと、何の製品だが推測される。しばらく寝かせた後にこの日記を公開している。たまには文書としてまとめず、思いをとりとめもなく書いてみる。ネットで色々と評されている。やっぱり電池駆動時間が思ったより伸びなかったのか。発表より 10 ~ 12 ヶ月前ほどの頃だったか、使っている SoC の消費電力が SoC メーカーの言い分に比べて大きいという感触が有った。回路設計の方にも「電池持ち悪いですよ」と言った記憶がある。他にも問題が多発していてリーダーが何回か海外出張に行っていた。SoC パッケージを触ると暖かいのだ。30cm 四方の評価用基板に乗っていた。確か 4 層だと思った。放熱板に乗っているのと同じだ。この時点で変だと思っていた。誰もが変だと思っていたのだろうか?割り振られた作業の合間に消費電力低減の可能性を探っていた。3,000 ページ(あるいはこの倍くらい)のレジスタ制御仕様と電力制御に関わるソースを読んでいた。電力制御ドライバは kref があるにも関わらず、独自実装で排他制御が破綻しているリファレンスカウンタが実装されていた。クロックと電源のツリー構造は不明瞭で、バス構造とパワードメインの対応は全く分らなかった。今になって思えば、ダークドメインをアクセスしてもハングしなかったのかも。レジスタ制御仕様書を通して見える Clock Tree、PLL 制御、Regulator tree、Power Gating、そしてそれらのドライバ、どれを見ても消費電力低減を狙えるような仕様ではなかった。稼働 CPU コア数を変えても、消費電力は 1% も変化しなかった。ほぼ同種の CPU コアを使った SoC 開発に携わったときに見てきたレジスタ仕様と比べても何か足りない感が有った。1~2 週間間隔で SoC メーカーからリリースされる基本ソフト毎に消費電力も挙動も変わっていた。ハングアップして、まともに評価すらできない状況でもあった。指摘事項は毎回 100 件程度は残っていたのにリリースノートに書かれた修正事項は 10 行にも満たない状況だった。修正箇所数に比べて報告される数が少ない。git のログにも意味ある情報は書かれていなかった。suspend, resume, boot, shutdown 処理のために小規模なシーケンサーが実装されていた。プロセッサ自ら行うことができないコア部分のクロックや電源 on/off 処理を受け持っていると思われた。シーケンサーの仕様を問い合わせてみた。非公開であり、何を処理しているかも分らなかった。16 進数で書かれたシーケンスパターンがソースにあるだけだ。回路設計チームから suspend 時のリーク電流を減らしてほしいと言われていたっけ。CPU core governor (稼働コア数調整)にも信じがたいバグがあった。SoC メーカーが手を入れた跡があった。アプリケーションの浮動小数点演算結果がとんでもない値になる問題が見つかった。報告したら、governor の修正コードに問題があると 1, 2 週間後に回答があった。消費電力を下げるなんて遠い目標なんだ。操作応答性を良くするとか、CPU 負荷に応じたクロック、コア数制御をしたら謎のクラッシュ頻発なんだろうな。手一杯の開発タスクを自分から増やす余裕はもうない。偉い人がメーカーに出向いている間も暗中模索の開発は続いていた。遠く海の向こうで交わされている言葉は解決策になるのだろうか?シリコンに焼き付いた回路を変える魔法の言葉はない。信号レベルとタイミングを確認したいと波形取得を頼んで出てきた波形が、そもそもサンプリング周波数が全く足りないオシロで測定されていた。動作不安定なバスが有り、レジスタ設定を変更してバス・クロックを下げると安定しだした。論理合成時のタイミング・バジェット計算が甘いか、未チェックではないかという疑いが有った。バスマスタシーケンサの設計ミスで転送したデータが欠損していた。エラッタ報告はなかった。Boot/Resume でシリアルコンソール出力が乱れていた。おそらくクロックか電源が回路ブロックに供給されない状態で動き出している。チップセットもおかしかった。ワイヤレス接続の電波が飛ばない。あるいは受信感度不足だった。机を並べた隣同士で干渉しないのは助かった。本当は拙いことだ。当初はデバッグの口になることも期待していた。USB-AC Charger を判定する回路のコンパレータは不完全な動作をしていた。正しく信号レベルを判定できない。制御方法や判定回路を操作しているドライバ挙動を問い合わせたら、「そんな機能は無い。」と無かったことにされた。次にリリースされたソースコードから綺麗にコンパレーターの問題動作に該当する部分の実装が削られていた。あらかじめ問題が分かっていると思える綺麗さだった。別解アルゴリズムを実装した。ああ、そうだファームウェア書き換えですら難儀していた。4, 5 回はリトライしないと最後まで書き込めなかった。誰もが生産性の問題を気にしていたと思いたい。もしかして、異仕様問題は書き込みで問題があったか。論理合成結果、Boot ROM、評価用ボード、手を加えられた Linux Kernel がまともにテストされていない。地雷原に立たされた開発なんだと思うようになった。あの時他の人はどう思っていたのだろう。そうだ、そんな中、どう思ったら良いか分からない新人が来たんだっけ。地雷原からは遠い仕事を探して割り振ったよな...他に何が出来たか、何があったか。あの時もどかしく思っていたことを思い出してみる。電力消費低減と、アンダーラン防止のため、ストリームバッファをキャッシュ有効で使う手だった。たしか dma_alloc_coherent(), dma_alloc_pages() で領域を確保していたか、ioremap_nocache() マッピングを使ってストリームバッファを仮想空間にマップしていた。DMA 転送領域なので非キャッシュ領域としてマップするのは普通のことだ。こうすると CPU からの書き込み速度は命令実行時間に比べ桁違いに遅くなる。場合によっては 1word 数 100ns ~ 数 μsec にもなる。write back キャッシュを効かせれば 1word は精々 1ns ~ 数 10ns となり劇的に高速化する。慎重に cache flush を行っていく難度と引き換えに得られるメリットは大きい。CPU の idle 時間が増え、電力消費を下げられる。ストリームバッファは担当外だった。担当だったとしても、要の機能に手を入れるには反対が有っただろう。動作確認に少なくとも 100 時間は必要だ。自動処理ではある。他にもストリームバッファを長年扱ってきた強者が居た。彼らは手として考えていたのだろうか? 応答性の悪さはどう対応しただろうか? ネットに書き込まれている内容を見るとストレージ I/O に課題がありそうだ。いや、思い出せ、「・・・そうだ。」ではなく第一感で拙いなと思うところが有ったではないか。普通は /sys/class/block/device/queue にあるノードのいくつかを調整する。eMMC の仕様を深読みして hw_sector_size, logical_block_size, optimal_io_size, physical_block_size, read_ahead_kb を変えるだろう。チラ見していた SDIO, mmc ドライバに問題を感じていたではないか。udelay(), mdelay() が多用され、polling 待ちも多かった。これでは操作性も入出力も引っかかりが多発する。そもそも、初期のリリースでは DMA S/G の作法がメチャクチャだった記憶がある。データシートに仕様が詳しく書いてあれば手を入れたかもしれない。もし SDIO, mmc ドライバ担当だったらどうしただろうか?趣味としては根本的に書き直すのは楽しい作業だったかもしれない。仕事では最も酷な仕事だろう。線形的な変化を重ねる「日本的な改善」は通用しない。大胆にアルゴリズムを変える必要が有る。成功は約束されない。良くなったとして、ユーザーランドのアプリ開発、ハードウエアの評価担当を含めた他の 200~300 人ほど居る関係者の手元で問題を起こしてはダメだ。多様かつ長時間のテストを手元でする必要が有る。そうだ、辞めたきっかけを思い出す。やはりアルゴリズムの書き直しでテストを入念にしていた時の事だったか。机で 4 ~ 5 台のテストを同時にやっていて、それを「机が汚い」と言われたのだっけ。ログ取り PC にシリアルコンソールを接続し、電源を取り回し、周辺接続の USB ケーブルを這い回し、肩をすぼめるように仕事をしていて体が痛くてしょうがなかった。「では、テスト要員を要請します」と言ったら、「無理だ」と言われたっけ。まだ記憶の中に留めている機能ブロックは多数ある。見ていた時には製品品質には遠かった。彼らはどう解決したのだろうか。製品は完成し、出荷されるのだ。自分の分までがんばった彼らに感謝しよう。完成おめでとう、お疲れ様でした。そうだ、もう一度自分の記憶と公開されたソースコードを比較してみよう。彼らの思いを確かめるために。
2016.11.07
コメント(0)
Raspberry Pi 3 Model B の root file system を USB 接続の外付け HDD にしてみた。理由は $ vmstat 1 で ブロック I/O を見ていると 4 ~ 30 秒程で 1 回 4 ~ 48KiByte 程ディスクに書き込んでいることだ。MicroSD カードが 2 ~ 3 年で壊れる(壊れた経験がある)。詳細な手順はHOWTO: Move the filesystem to a USB stick/Drive の "Extended procedure:" に沿って行う。後で扱いやすいように一応 file system にボリュームラベルを付けることにした。状況に応じて変る所は斜体にしてある。手順の概要は次の通り。Paspberry Pi 3 に USB ディスクドライブを接続する# mount コマンドで自動マウントされたボリューム(/dev/sda1 の様なデバイス) を確認する# umount /dev/sda1 で自動マウントを解除# apt-get install gdisk# fdisk /dev/sdaMBR パーティションを全て削除MBR パーティションが残っていると GPT パーティションが不完全になる問題を経験した# gdisk /dev/sdaパーティション切りおおよそ fdisk を知っていればほぼ使いこなせる# mkfs.ext4 -L piroot /dev/sda1# mkdir /mnt/sda1 で仮マウントディレクトリを作成# mount /dev/sda1 /mnt/sda1 でマウントする# rsync -avx / /mnt/sda1 でファイル(シンボリックリンク・ノードも込み)をコピーする# blkid で /dev/sda1の PARTUUID を確認する# nano /boot/cmdline.txt にてblkid で確認した PARTUUID で root filesystem を root=PARTUUID=01234567-89ab-cdef-0123-456789abcdef の様に指定する# nano /etc/fstab にて fstab を書き換える / のマウントを指定している行 /dev/mmcblk0p2 をコメントアウト PARTUUID=01234567-89ab-cdef-0123-456789abcdef / ext4 defaults,noatime 0 1 を追加する# sync; /sbin/reboot で再起動fdisk でパーティションを切ったディスクドライブを GPT パーティションに変えるのに失敗している。gdisk を始めから使った方が良いだろう。手順の中に swap パーティションを作り、/etc/fstab にマウントする指定(例: PARTUUID=6fecd6f9-60a5-4339-a0fa-79c13ac8b6c1 swap swap defaults 0 1)を加えると swap を /var/swap ファイルからパーティションに移せる。厳密には パーティションの swap と /var/swap が併存する。パーティションの swap 領域を優先して使用する。/sys/class/block/sda/queue/scheduler は deadline のままでよいのかなぁ。2016.12.05 修正 fdisk で MBR パーティションを削除する手順を追加
2016.11.05
コメント(0)
11/2 のこと 8 月に不良ブロック登録をして使用を続けていた外付け USB ハードディスク WD7500BPVT が再び止まっていた。いつもは 10~30 秒間隔くらいで点滅しているアクセスランプが点いていない。ログに切断された記録が有った。ファイルを開いているプロセスを終了して、unmount, fsck, mount, プロセス再起動で再び使い始めた。この日記を書いている時点 11/3 で再び不調になっている。fsck を掛けると、いくつかの修復確認が出てきた。すべて y とする。1 回目は 次のような kernel log が出て signal 不可で fsck.ext4 が止まる。[39921.917095] INFO: task fsck.ext4:7432 blocked for more than 120 seconds.[39921.917101] Tainted: G OX 3.13.0-85-generic #129-Ubuntu[39921.917103] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[39921.917105] fsck.ext4 D ffff88041f313180 0 7432 7431 0x00000000[39921.917110] ffff880310ebdd80 0000000000000086 ffff880405366000 ffff880310ebdfd8[39921.917114] 0000000000013180 0000000000013180 ffff880405366000 ffff880310ebdea8[39921.917118] ffff880310ebdeb0 7fffffffffffffff ffff880405366000 0000000001e21000[39921.917130] [<ffffffff8172fb69>] schedule+0x29/0x70[39921.917133] [<ffffffff8172ed89>] schedule_timeout+0x279/0x320[39921.917138] [<ffffffff8133ede3>] ? __blk_run_queue+0x33/0x40[39921.917142] [<ffffffff81342d03>] ? blk_queue_bio+0x2b3/0x3b0[39921.917145] [<ffffffff81730686>] wait_for_completion+0xa6/0x160-- 省略 --[40704.540240] sd 12:0:0:0: timing out command, waited 360s[40704.540251] end_request: I/O error, dev sdd, sector 0USB ケーブルを抜き差しして、fsck を終了させる。切断すると転送完了待ちも強制的に完了となる。fsck 2 回目も似たような状況になった。しばらく待っていたら、fsck が終了していた。ハードディスクケース内の USB-SATA ブリッジのファームで上手く扱えないエラーケースが発生しているようだ。不良ブロック登録をして延命する策も限界かな。また壊れた原因?「秋葉原に電車で行ける用が出来ないかな...」と思ったことかもしれない。
2016.11.03
コメント(0)
実家に寄り道する。目的地の中では最も遠い場所の寄り道だ。父親が Word と Excel の操作に難儀していた。前に一度教えた操作だ。難しいなと予想していた。漢字 1 文字よりも小さいリボンとクイックアクセスツールバーのアイコンを指してこれをクリックと言っても恐らく、見えない・分からないだと思っていた。色々と調べてみる。リボンのラベル表示はウインドウ横幅によって表示・非表示が自動的に変る。うーん、常に表示の様なオプションは無いのだろうか?ちょっとした状態の違いで見た目が大きく変るのは迷いの原因だ。UI デザイナーはこれをカッコイイなんて思っているのだろうか?クイックアクセスツールバーにラベル表示は無いようだ。アイコンを大きくすることもできない。視力が弱い場合に補助に使うのは無理そうだ。マウスカーソルを over すると Tip 表示が現れる。もう少し早くても良いし、離れた場所でなくても良いのでは?古い UI の方が良くできている。メニューバーからプルダウンで表示される機能を表す言葉、ステータスバーに即座に表示される機能説明、どこを見ればヒントになるか視線を泳がせて探す必要がない。Windows8, Windows10 が出てから暫く経つのに Touch UI と リボン UI の纏まりのなさもそのままだ。それとも、自分は画面を指で突いているだけですばらしい文書が書ける office が有ることを知らないのだろうか?
2016.11.01
コメント(0)
雨なので 1 日中家にいた。午後 15 時くらいに小降りになり、外出の可能性を考えてみる。雨雲レーダーでみる雲の切れ目は 1 時間分くらいだった。降られるな。色々と試している Wkiki の設定、ソース、ページを弄る。色々と思っていることが上手くいけば、公開なのだけどまだ遠い。下手なロゴだけど描くのは楽しいな。
2016.10.28
コメント(0)
(4) MAX77854 の設定をアプリから変更して解決しようとした?の続き。DA9155M には充電加速を enable/disable する信号端子 EN がある。この端子を使えば外部から充電加速制御できる。DA9155M のデータシート 10.1.1 EN を読むと次のように書いてある。The EN pin controls the BUCK_EN register. A rising edge sets the register and a falling edge clears it. The rising edge of the EN pin has to occur when DA9155M is in the disabled mode. The application processor can start the Buck by asserting the EN pin or by setting the BUCK_EN bit through the 2-wire interface.両エッジセンスなのだ。rise で BUCK_EN を set、fall で BUCK_EN を clear だ。仕様として問題を感じる。書いてあるようにドライバで BUCK_EN を書き直して、EN 端子で通知された充電停止指令を覆すことができる。(3) で見たように da9155_irq_handler()で覆している。EN 端子をレベルセンス端子にしてハードによる充電異常判定結果を覆すことができない様にするべきだと思う。EN 端子はどうなっているのだろうか?回路図が無いのでドライバを読んで推測していく。MAX77854 の fuelgauge (充電量計算ブロック) から信号を出すように設定していると見られる箇所がある。max77854_fg_init()にある次のコードだ。if (fuelgauge->auto_discharge_en) { /* Auto discharge EN & Alert Enable */ max77854_bulk_read(fuelgauge->i2c, CONFIG2_REG, 2, data); data[1] |= 0x2; max77854_bulk_write(fuelgauge->i2c, CONFIG2_REG, 2, data); /* Set Auto Discharge temperature & Voltage threshold */ volt_threshold = fuelgauge->discharge_volt_threshold < 3900 ? 0x0 : fuelgauge->discharge_volt_threshold > 4540 ? 0x20 : (fuelgauge->discharge_volt_threshold - 3900) / 20; temp_threshold = fuelgauge->discharge_temp_threshold < 470 ? 0x0 : fuelgauge->discharge_temp_threshold > 630 ? 0x20 : (fuelgauge->discharge_temp_threshold - 470) / 5; max77854_bulk_read(fuelgauge->i2c, DISCHARGE_THRESHOLD_REG, 2, data); data[1] &= ~0xF8; data[1] |= volt_threshold << 3; data[0] &= ~0xF8; data[0] |= temp_threshold << 3; max77854_bulk_write(fuelgauge->i2c, DISCHARGE_THRESHOLD_REG, 2, data); pr_info("%s: DISCHARGE_THRESHOLD Value : 0x%x\n", __func__, (data[1]<<8) | data[0]);}長いコード断片には、電池電圧 discharge_volt_threshold と電池温度 discharge_temp_threshold をレジスタ値 volt_threshold, temp_threshold に換算する処理が含まれている。おそらくこの 2 条件の論理和により、信号出力をするように CONFIG2_REG を設定しているのだろう。MAXIM が外販しているチップの中で、CONFIG2_REG と DISCHARGE_THRESHOLD_REG に近い仕様のレジスタ構成をしたチップが見つからない。SAMSUNG が出した要求仕様に基づいて新設された機能だろうか?Open Firmware の Devicetree Syntax ファイル exynos8890-universal8890_common_battery_01.dtsi から関係しそうな値を読む。電池電圧が 4.540V 以上、または 電池温度が 60.0 ℃以上で信号を出していると思われる。fg_resistor は恐らく関係していない。fuelgauge,auto_discharge_en;fuelgauge,fg_resistor = <2>;fuelgauge,discharge_temp_threshold = <600>;fuelgauge,discharge_volt_threshold = <4540>;信号が機能したとして、電池電圧が 4.540V になってからだ。電池仕様の充電終止電圧を 140mV 超える。確度のずれも考慮すればさらに 1lsb 分 +20mV で 160mV か。電池が損傷する可能性も出てくる。まさか、DA9155M が充電しつつ、別の回路でブリーダ抵抗に電流を流し始めるとか。4.540V の根拠は何だろうか? volt_threshold を計算する式に 4540 がある。 (4540 - 3900 ) / 20 = 0x20 だ。単に最大値か。保護の意図無し?
2016.10.25
コメント(0)
(3) DA9155M の VBAT_OV が 5.0V 固定の続き。MAX77854 の充電終止電圧設定関数を探してみる。初期化関数 max77854_charger_initialize() の中で次のような記述を見つける。max77854_set_float_voltage() だろう。※ 関数その他のリンク先で複数のパスが表示された場合は、drivers/battery_v2 の方を選択して下さい。/* * cv voltage 4.2V or 4.35V * MINVSYS 3.6V(default) */max77854_set_float_voltage(charger, charger->pdata->chg_float_voltage);充電電流の設定も重要だ。調査している。kernel source code の中から使用している可能性が高い設定値が見つからない。今の結論は電流 (total_current) の方はアプリから設定関数 sec_multi_chg_set_property(), POWER_SUPPLY_PROP_CURRENT_NOW を通して設定している。※ 関数その他のリンク先で複数のパスが表示された場合は、drivers/battery_v2 の方を選択して下さい。max77854_set_float_voltage() が絡むメンバ chg_float_voltage を読んでみる。max77854_set_float_voltage() には初期値、アプリ設定値が渡される。初期値は状況に応じていくつか選択肢がある。ソースを読むと Open Firmware (参考: Open Firmware, Device Tree) の API から初期値を得ている。max77854_charger.c:max77854_charger_parse_dt()ret = of_property_read_u32(np, "battery,chg_float_voltage", &pdata->chg_float_voltage);if (ret) { pr_info("%s: battery,chg_float_voltage is Empty\n", __func__); pdata->chg_float_voltage = 42000;}pr_info("%s: battery,chg_float_voltage is %d\n", __func__, pdata->chg_float_voltage);charger->float_voltage = pdata->chg_float_voltage;初期値は arch/arm64/boot/dts/exynos8890-universal8890_common_battery_01.dtsi に書かれている。arch/arm64/boot/dts/Makefile を読んでの推測だ。dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtbdtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtbdtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtbdtb-$(CONFIG_SOC_EXYNOS8890) += exynos8890-smdk8890.dtb exynos8890-universal8890.dtbexynos8890-universal8890.dtb にて、次のように書かれている。/dts-v1/;#include "exynos8890.dtsi"#include "exynos8890-rmem.dtsi"#include "exynos8890-universal8890_common_battery_01.dtsi"#include "modem-ss335ap-pdata.dtsi"#include "exynos8890-display-lcd.dtsi"もしかしたら、これは読み間違えている可能性がある。exynos8890-universal8890_common_battery_01.dtsi に書かれた値 (例えば swelling_drop_float_voltage) の桁がソースコードの fail safe 値と合っていない。そもそも、必要とされる記述がない(例えば battery,age_data)など、解釈に困る点がある。battery,swelling_drop_float_voltage = <42000>;battery,swelling_high_rechg_voltage = <4150>;battery,swelling_low_rechg_voltage = <4050>;swelling_drop_float_voltage を取得する処理は次の通りだ。sec_battery.c:sec_bat_parse_dt()ret = of_property_read_u32(np, "battery,swelling_drop_float_voltage", (unsigned int *)&pdata->swelling_drop_float_voltage);if (ret) { pr_info("%s: swelling drop float voltage is Empty, Default value 4250mV \n", __func__); pdata->swelling_drop_float_voltage = 4250;}最も高い充電終止電圧は次の記述だろう。4.3625V と読める。MAX77854 の兄弟チップ MAX77818 の電圧設定確度 (BATT Regulation Voltage Accuracy) +-1% を当てはめて出力される電圧を計算すると 4.3625V * 1.01 = 4.4061V となる。僅かに電池仕様 4.4V を超える。深刻に考える程ではないだろう。battery,chg_float_voltage = <43625>;アプリから充電終止電圧を設定できる。ノードは /sys の下の device_attribute sec_battery_attrs からと、/sys/class/power_supply/SupplyDevice がある。正確な path は解析していない。sec_battery.c:sec_bat_store_attrs() (統合ドライバ)case BATT_TUNE_FLOAT_VOLTAGE: sscanf(buf, "%d\n", &x); pr_info("%s float voltage = %d mV",__func__, x); if(x > 4000 && x <= 4400 ){ union power_supply_propval value; value.intval = x; psy_do_property(battery->pdata->charger_name, set, POWER_SUPPLY_PROP_VOLTAGE_MAX, value); } break;max77854_charger.c:max77854_chg_set_property() (MAX77854 ドライバ)#if defined(CONFIG_BATTERY_SWELLING)case POWER_SUPPLY_PROP_VOLTAGE_MAX: charger->float_voltage = val->intval; pr_info("%s: float voltage(%d)\n", __func__, val->intval); max77854_set_float_voltage(charger, val->intval); break;#endif統合ドライバ sec_battery.c から設定すると max77854_charger.c と桁が合わない。sec_battery.c の判定は if(x > 4000 && x <= 4400 ) だ。max77854_charger.c の POWER_SUPPLY_PROP_VOLTAGE_MAX で受ける方は max77854_set_float_voltage() に実装された変換式により 40500 .. 45000 の範囲が定義域だ。max77854_set_float_voltage()static void max77854_set_float_voltage(struct max77854_charger_data *charger, int float_voltage){ u8 reg_data = 0; reg_data = float_voltage <= 40500 ? 0x0 : float_voltage >= 45000 ? 0x24 : (float_voltage - 40500) / 125; max77854_update_reg(charger->i2c, MAX77854_CHG_REG_CNFG_04, (reg_data << CHG_CNFG_04_CHG_CV_PRM_SHIFT), CHG_CNFG_04_CHG_CV_PRM_MASK); max77854_read_reg(charger->i2c, MAX77854_CHG_REG_CNFG_04, ®_data); pr_info("%s: battery cv voltage 0x%x\n", __func__, reg_data);}アプリから充電終止電圧を設定できるように修正を加えたのだろうか? CONFIG_BATTERY_SWELLING (参考 _defconfig ファイル)が定義されていると MAX77854 ドライバの POWER_SUPPLY_PROP_VOLTAGE_MAX ノード voltage_max (ノード名一覧) の書き込みができる。DA9155 の da9155_chg_set_property() はどうだろうか? ノード(API) を実装していない。da9155_charger.c:da9155_chg_set_property()case POWER_SUPPLY_PROP_VOLTAGE_MAX:case POWER_SUPPLY_PROP_STATUS:case POWER_SUPPLY_PROP_CURRENT_FULL: break;case POWER_SUPPLY_PROP_CURRENT_MAX:case POWER_SUPPLY_PROP_HEALTH: return -ENODATA;論理的な構造が一致しない実装があちこちに見つかる。背景は何だろうか?レビューをしていない?担当者が交代した?複数の担当者間で連絡が取れていない?コードの癖に時間に追われていた?と思われるところがある。コメント量にムラが有る。定数マクロを使ったところと、直接マジックナンバーを使ったところがある。printk 類の 書式が一定ではない。Linux Kernel のコーディング・ルールに良く従っている。所々プログラマ本来の癖が見える。MAX77854 のドライバに原因があると考えて修正を続けていたのだろうか?誰かが DA9155のドライバに問題があることを指摘しなかったか、詳細や現状の理解を得られずに「MAX77854 のドライバを修正しろ」と言われ続けたのか?2016.10.25 追記 (5) 充電加速停止信号線がある?
2016.10.22
コメント(0)
(2) なぜ 2 つも充電回路が?の続き。簡単に読めそうな所から進める。おおよそ初期設定だったり、毎回同じ値を設定している所だ。drivers/battery_v2/da9155_charger.c:da9155_charger_initialize() (以降リンク先では drivers/battery_v2 の方を見て欲しい) に VBAT_OV (VBAT overvoltage. VBAT_OV=3.6+(N×0.025) V.) の設定がある。/* VBAT_OV: MAX(5V) */da9155_update_reg(charger->i2c, DA9155_CONTROL_C, 0x38, DA9155_VBAT_OV_MASK);※ 関数などのリンクは CGI と ポート 8082 のへの接続なので proxy や ファイアウオールが運用されているところではアクセスできないかもしれない。探すとこれ以外の場所で DA9155_CONTROL_C.VBAT_OV を設定している箇所は無い。0x38==56 だ。計算すると 3.6+56*0.025=5.0 となる。電池電圧上限が 5.0V に設定されている。先の調査で充電電圧は 4.4V だと分かっている。保護機能の一つを実質的に無効にしている。慎重さに欠けていると思う。これだけで危険と判断できない。他のアルゴリズム(回路)で保護されている可能性も有る。もしかして何かの拍子に reset されて 強い保護が掛かる? DA9155M のデータシートを読んでも Reset 値が分からない。Reset したらどのような設定になるのか分からないデバイスで電池充電するのだろうか? SAMSUNG 向けに Reset 値をカスタマイズしてある?da9155_charger_initialize() がどこから呼び出されるか、辿ってみる。da9155_set_charger_state(), da9155_irq_handler(), da9155_chg_set_property() だ。da9155_set_charger_state() は呼び出し元を辿っていくと /sys/class/power_supply/SupplyDevice/ 以下の property ノード読み書きに繋がる。root 権限を持つアプリなら電池充電制御ができてしまう。他の property 実装もついでに読むとアプリが主導して電池制御を行っている(あるいは行える)ように読める。アプリが強制終了したら電池の制御はどうなるのだろう?da9155_set_charger_state() を読んでいこう。保護がない。enable != 0 で呼び出すと、電池が満充電になった(充電終止電圧に達した)後でも構わず DA9155M の充電加速(BUCK_EN)を始めてしまう。STATUS_A に異常が示されている場合は何もせず戻るから大丈夫と思っている節がある。TJUNC_WARN=1 (ジャンクション温度 70℃ DA9155_CONTROL_E)でも強行だ。忘れてはいけない。VBAT_OV=5.0V なのだ。if (enable){ da9155_charger_initialize(charger); da9155_read_reg(charger->i2c, DA9155_STATUS_A, &status); if (status & 0x7E ){ pr_info("%s: STATUS_A(0x%X)\n", __func__, status); return; } current_setting = da9155_get_charge_current(charger); da9155_set_charge_current(charger, 500); da9155_update_reg(charger->i2c, DA9155_BUCK_CONT, DA9155_BUCK_EN_MASK, DA9155_BUCK_EN_MASK); msleep(10); if (current_setting > 500) da9155_set_charge_current(charger, current_setting);}da9155_irq_handler() を読んでみよう。外部電源供給状態で EVENT_B.E_RDY == 1 になったら(充電加速できない事象が発生したら)、充電を再開するように書かれている。え?再開できない状況かもしれないのに?if (!da9155_read_reg(charger->i2c, DA9155_EVENT_A, &event_a) && !da9155_read_reg(charger->i2c, DA9155_EVENT_B, &event_b)) { if ((event_b & 0x1) && (charger->cable_type != POWER_SUPPLY_TYPE_BATTERY)) { dev_info(charger->dev, "%s: E_RDY Event occured", __func__); da9155_mode_change(charger, da9155_check_cable_type(charger->cable_type)); da9155_charger_initialize(charger); da9155_set_vindrop_vbatov(charger); }da9155_chg_set_property()を読んでみる。ここも、da9155_set_charger_state() で気づいたこととほぼ同様の流れになっている。case POWER_SUPPLY_PROP_ONLINE: charger->cable_type = val->intval; if (val->intval != POWER_SUPPLY_TYPE_BATTERY) { da9155_mode_change(charger, da9155_check_cable_type(charger->cable_type)); charger->prev_cable_type = charger->cable_type; da9155_charger_initialize(charger); da9155_set_vindrop_vbatov(charger); } else { da9155_mode_change(charger, DISABLE); charger->prev_cable_type = POWER_SUPPLY_TYPE_BATTERY; } break;充電加速を指示されたら、どんな状況でも充電加速を始める。アプリ(Userland) のコードは .zip の中に入っているのかな... もう少し driver code を読んでみるか。2016.10.22 追記 (4) MAX77854 の設定をアプリから変更して解決しようとした?
2016.10.19
コメント(2)
(1) いつまで続くかな の続き、ソースコードとデータシートを手に入れてある程度読む場所を絞ったところまで進んだ。ソースコードと手に入れたデータシートから自分には奇妙に思える構造があった。充電ドライバが 3 つもある。drivers/battery_v2 に da9155_charger.c, max77854_charger.c, 一群の {sec_*.c} だ。ざっと読んでみて、うち一つ {sec_*.c} は統合機能を持っているらしい。ネットには回路まで解析した記事はない。DA9155M の Application note "3.3 Master/slave charger system diagram"(自動でページが開かれない場合は 3.3 節 Page 6 を開いて欲しい) に DA9155M の使い方が出ている。DA9155M の Application Note から気になる点として指摘している記事が見つかっている。充電回路が並列で構成されている。自分にとっては初めてみる構成だ。ここまでして充電時間を短くしたいのだろうか?MAX77854 はカスタムチップなはず。だとすれば MAXIM に要求仕様として高速(大電流)充電回路を盛り込めばチップを増やさずに済むはず。充電補助回路を付ける構造にしたのはなぜだろうか? MAXIM が断ったのだろうか?色々と難しいのでは?と思うところがある。充電終止電圧の判定、充電終止電流の調整だ。お互いの基準電圧源は誤差を持っている。どちらかが充電終止だと判定しても、片方は充電を続けることになる。DA9155M の Application Note を見るとソフトの介入を必要としている。上手く Kernel driver は実装されているのかな...2 つのスイッチングレギュレータが持つ LC フィルターが構成する伝達特性は各所の FET On/Off によって動的に変わる。電池特性変動も含めて安定した制御の難度は高いはず。スイッチング周波数は 1~4MHz の範囲なのでボディエフェクトによる変化も注意が必要だろう(金属シールドかな)。メーカーによってはソフト介入を必要とする充電制御は御法度あるいは、ハードウエアで安全性が担保される場合だけに限定されているだろう。確実にソフトは働くだろうか? 「高負荷アプリ使用かつ電池充電 → 電池高温 → CPU 暴走 → Kernel 停止 → ドライバ動かず → 保護回路でようやく停止」と言うようなシナリオに陥らないか慎重になる必要が有る。よりあり得るシナリオとしては、suspend 時にドライバ対応が必要になった場合、wakeup して対応できるか。あるいは Android 独自の拡張として実装された wake lock を適切に使って稼働状態を維持しているかどうかだ。電池充電 IC の電流計測精度はそれほど高くない。お互いに電流を少なめに測る傾向で誤差が振れると電池に負担を掛けることになる。瞬間的な大電流にはある程度鈍感だ。敏感すぎると(ローパスフィルタを通さないと)アプリの使用状況で激しく変動する電流を誤認して充電が進まない。電池の仕様を確認しよう。Galaxy note 7 の電池は EB-BN930ABA で出てくる画像だ。もう一つは EB-BN930ABE だ。仕様は次の通り。充電電圧: 4.4V公称電圧: 3.85V容量: 3500mAh (13.48Wh)充電電圧が高いな。探してみると他の電池メーカーにも充電電圧 4.4V の製品が見つかる。仕様を信じるか。あれ、今回はソフトを読んでいないぞ... 何だな、これだけ複雑な充電回路とソフトを構成できるほど人を注ぎ込んでいるのかな。 2016.10.19 追記 (3) DA9155M の VBAT_OV が 5.0V 固定
2016.10.17
コメント(0)
実家の Windwos10 に upgrade した母親のデスクトップ PC につないでいたプリンタが見えなくなったとのことで急遽赴くことにした。見てみるとプリンタの方は普通に使えていた。話を聞いてみると突然青い画面になったという。ブルースクリーンだろう。自分も色々と弄っているうちにブルースクリーンを見た。igdkmd64.sys だ。Intel の グラフィックスドライバだ。インテル グラフィックス・ドライバー と インテル ドライバー・アップデート・ユーティリティー を使ってドライバを更新することにした。更新した後、バックアップ作業を始めた。しばらくして、やはりブルースクリーンになった。今度はモジュール名無しで KMODE_EXCEPTION_NOT_HANDLED だ。どういうことだろう。BIOS セットアップ画面に入って仮想化機能を off, (何だろう妙に気になり) Turbo Boost を off した。Turbo boost 機能を off する動機が有った。何の作業をしていても CPU ファン回転速度が変わらないのだ。もしかしてファン制御機能が Windows10 になって働かなくなっている?父親の方のノート PC もブルースクリーンが出る。同様にドライバをアップグレードしてみる。ただし、殆ど更新されず。Intel がドライバ更新を止めてしまっている。チップに適合したドライバは「インテル Core プロセッサー・ファミリー用インテル HD グラフィックス」だ。対応 OS は Windows7 止まりだ。ドライバの更新が止まっているのに Windows7 から Windows10 に強行に upgrade を進めた Microsoft の方針は正しかったのだろうか?実家の 2 台の PC ともブルースクリーンに対して有効な対応を取った感は無い。次の対応を計画しておく必要が有る。温度監視ツールで CPU の温度上昇具合を見てみるか。
2016.10.16
コメント(0)
全884件 (884件中 101-150件目)