全884件 (884件中 151-200件目)
発売中止になった Galaxy note 7 のLinux Kernel source code はまだ公開されている。リンク先のページで Galaxy Note 7 の型名の一部 SM-N930 を検索すると見つかる。検索で見つかった中で SM-N930F のソースコードにいくつかのバージョンが見られるのでこれらをダウンロードする。バージョンは推定で古い順に N930FXXU1APGI, N930FXXU1BPH6, N930FXXU2BPI7 だろう。これからは主に N930FXXU2BPI7 を見ていく。ソースコードの大きさは 400Mbyte(390Mibyte) だ。ある程度ディスクに余裕がある環境で展開した方が良いだろう。.zip を展開すると Kernel.tar.gz が出てくるので、これを展開する。.zip も .tar.gz も 1 段階目のディレクトリが無いので「サブディレクトリを自分で作り」その下で展開すると良い。展開で出てきた README_Kernel.txt に読むためのヒントがある。default config は arch/arm64/configs/exynos8890-gracelte_defconfig だ。$ make ARCH=arm64 exynos8890-gracelte_defconfig_defconfig ファイルの内容と各ディレクトリにある。Makefile, Kconfig を突き合わせてコンパイルされるソースを特定する。今回は 充電ドライバ なので手っ取り早くキーワードを目印に探す。充電関係のキーワードは次だ。_CHARGER_, FUELGAUGE_, _BATTERY_, 色々とあちこち見回して、関係しそうな CONFIG をピックアップする。ソースを特定するのに必要最小限に絞って挙げている。CONFIG_SOC_EXYNOS8890=yCONFIG_BATTERY_SAMSUNG=yCONFIG_FUELGAUGE_MAX77854=yCONFIG_CHARGER_MAX77854=yCONFIG_CHARGER_DA9155=yCONFIG_BATTERY_SAMSUNG_V2=y展開したソースコードによく似たファイルが drivers/battery, drivers/battery_v2 に格納されている。どちらが使われるか特定するのが CONFIG_BATTERY_SAMSUNG_V2=y だ。drivers/battery_v2 が選択されている。drivers/Makefile にその記述が見られる。ifeq ($(CONFIG_BATTERY_SAMSUNG_V2), y) obj-$(CONFIG_BATTERY_SAMSUNG) += battery_v2/else obj-$(CONFIG_BATTERY_SAMSUNG) += battery/endifお、Kernel 内ではあまり見かけない単語 SWELLING(膨張) を見かける。辞書を引くまでは意味は分かっていなかった。CONFIG_BATTERY_SWELLING=yVersion 間の差分 N930FXXU1APGI と N930FXXU2BPI7 を見てみると CONFIG_BATTERY_SWELLING=y とそれに関係するコードは大きな追加と削除は見られない。N930FXXU1APGI を出した時点で電池膨張があることが分かっていたのだろうか?充電ドライバ屋をしていて、陽に電池膨張対策コードを書いたことはない。8 ~ 9 割充電をする様に書いたことはある。ドライバコードが読めなくても、差分を見るだけでプログラマなら注ぎ込んだ対策コードの多さとすぐには読み下せない複雑さが見えてくるだろう。コードを読む前にデータシートを入手する必要が有る。DA9155 (DA9155M) は市販されている IC だと思われる。MAX77854 は SAMSUNG 向けのカスタムチップの様だ。データシートが見つからない。drivers/battery_v2/max77854_charger.c のソースから推測できる機能とレジスタ構成、MAXIM サイトが提供する パラメトリックサーチを使い MAX77818 が比較的近いチップだと推測する。DA9155 datasheetMAX77818 datasheet (MAX77854 に似ていると思われる)今日はこの辺までかな。2016.10.17 追記: (2) なぜ 2 つも充電回路が?
2016.10.14
コメント(0)
実家から Windows10 PC が起動しなくなったとのことで連絡が入った。話によると BIOS 画面の直後テキスト画面のカーソルが左上に点滅する状態だった。ディスク損傷から、起動ファイル削除・破損、設定の異常書き換えまで色々と考えられた。ディスク損傷に備えて smartctl, sg utils, partimage をインストールした Ubuntu live USB drive を 10/11 の夜に用意する。testdisk も有った方が良かったかもしれない。10/12 午前中に実家に行き状況を確認する。Ubuntu で NTFS パーティションを mount すると殆どのファイルは見える。ディスク損傷や悪意があるプログラムで大半を削除された状況では無い事が分ってくる。PC 内蔵のドライブの smart 情報を採取、不良ブロック発生などの損傷が無い事も分る。何をしても「動かない状況に戻れるように」バックアップを始める。バックアップ先のドライブの不調があり作業が 1, 2 時間難航した。15 時くらいにバックアップ作業を終える。平行して Windows10 インストールメディアを作成する。インストールメディアから起動して「コンピュータを修復する」を使うためだ。DVD からの起動に難儀した。SATA bus の不調も疑った。ピックアップレンズを綿棒で拭いて復旧する。アルコールを少量用意しておいた方が良かったか。起動修復は難儀した。「修復セットアップ」の自動の起動回復処理「スタートアップ修復」は機能しなかった。たしか、「問題はありません」と... 「システムの復元」の復元ポイントは Windows7、「以前のビルドに戻す」は以前のビルド無し。全てのドライブに対して chkdsk を実施、修復は必要なし。sfc /scannow は 「保留中」にて実行できず。windows 格納ドライブを見つけて \windows\winsxs\pending.xml を xending.xml にリネームした。リネームしても sfc /scannow は 「保留中」になる。再起動と「スタートアップ修復」を試しているうちに sfc /scannow を実行できるようになる。結果は破損無し。起動せず。bootrec /fixmbr; bootrec /fixboot; bootrec /scanos; bootrec /rebuildbcd は共に効果無し。途中、Windows10 upgrade 前の windows7 を起動 OS に加えようとしていた。\windows.old\windows ディレクトリが /scanos, /rebuildbcd で選択子として示される。問題に感じつつも起動の選択子に Y で加えた。これも効果無し。起動ドライブの \Boot\BCD を 削除してみて前節同様の事をしても効果無し。bcdedit; bcdedit /createstore を実施しても効果無し。bcdedit で表示されるブートコード位置と Windows 格納位置の関係が何となく不審。bootsect /nt60 sys /mbr も効果無し。ここからは、破壊的な修復作業をする。バックアップは取ってあるのだ。bootsect /nt60 all /mbr を実行する。全てのパーティションにブートコードをインストールする。diskpart でアクティブパーティションを Windows を格納したパーティションに変更する。使用コマンドは list disk, select disk, list partition, select partition, active, detail partition, exit だ。こうすると「起動しなくなる」。前と違うのは起動しない際にテキストメッセージが出ることだ。少なくとも boot loader は実行されている。ここで「スタートアップ修復」をする。「修復しています」とメッセージが出る。ようやく異常事態であることを認識してくれた。終了後、再起動するとインストールしてあった Windows10 が起動した。復旧する。インストール後、ブルースクリーンが頻発していた。Windows7 の時にインストールしてあり、残留していたドライバ・ユーティリティをアンインストールする。USB 3.0 ユーティリティ、光学メディア書き込みツール、Battery ドライバ・ユーティリティ、ホットキーで音量・輝度・他を調整するとオンスクリーンでレベルを表示するユーティリティ(これは Windows10 の機能にもある)、メーカーがサービスを終了してしまったプリンタのポップアップメッセンジャー。CPU の仮想機能と使用していない有線 LAN も off にした。Windows10 Home なので仮想機能はほぼ使わない。Windows7 から update した windows10 は windows update の度に windows7 で使っていたドライバ・ユーティリティの残骸、メーカーが修復パーティションに組み込んだ独自の修復・診断プログラムに安定性を脅かされるのだろうか?
2016.10.12
コメント(0)
ここ 2, 3 週間は Linux Kernel の HID (Human Interface Device) のドライバ drivers/hid を読んでいる。I/O デバイスの中では身近なものだ。なかなか読み下せない。色々と書くものも滞っている。Documentation/hid の下にある hid-transport.txt が俯瞰図だ。この俯瞰図ほどには単純ではない。USB HID を見ていく。俯瞰図の "I/O Driver" が drivers/usb/core/* で URB (USB Request block) を使った通信だ。俯瞰図の "Transport driver" が drivers/hid/usbhid/hid-core.c URB 通信を抽象化して HID の送受信に変換している。俯瞰図の "HID core" が drivers/hid/hid-core.c, drivers/hid/hid-input.c と include/linux/hid.h、これらは Report descriptor の解釈、report を input event に変換する処理、"Transport driver" を "Custom Driver" から呼び出すためのラッパ、device と driver の登録・削除を担っている。俯瞰図の "Generic Driver" が drivers/hid/hid-generic.c となる。"Generic Driver" は keyboard, mouse で使われている(殆ど何もしていない)。階層的で綺麗でしょ?ではないのだ。USB HID device のうち Boot Interface Subclass デバイス専用のドライバ drivers/hid/usbhid/usbkbd.c と drivers/hid/usbhid/usbmouse.c はここでは見なかったことにしている。続けよう。よく読むとプロトコルの要所で "Custom Driver" (struct hid_driver) の hook 関数を呼ぶ機能のうち resume, suspend, reset_resume については "Transport driver" である usbhid/hid-core.c から呼ばれる。"Transport driver" を呼び出す方を見ると include/linux/hid.h で inline 関数として実装された hid_hw_* 関数を通して "Transport driver" が "Custom Driver" から呼び出されている。"HID core" の実装として敢えて include/linux/hid.h を挙げた理由だ。probe も特殊だ。hid_have_special_driver テーブルに格納されたデバイスを見ていくと "Custom Driver" drivers/hid/hid-*.c で 2 重に hid_device_id として記述している。ここは追い切れていない。hid_add_device の挙動を追うつもりだ。Driver 屋をしてきた中でなぜか HID は通らなかった道でもある。そうは言っても、仕事の合間や暇を見ては読んでいた。その時もすっと頭に入ってこなかった。あまり書くと検索エンジンのデータベースを汚してしまいそうた。時間を掛けてもう少し整理が付いてからかな。
2016.10.08
コメント(0)
運用開始 2 ヶ月半(稼働時間 837 時間)で不良ブロックが発生した WD40EZRZ の不良ブロックマップを採取してみた。WD40EZRZ 不良ブロックマップ PDF WD40EZRZ 不良ブロックマップ テキストデータ(1 行 1 LBA)不良ブロック採取直後の SMART 情報を見ると Current_Pending_Sector が 1317 だった。不良ブロック範囲かクラスタで纏めた先頭だけ?マップから見る破損状況は多彩だ。損傷状況を考えてみる LBA が MAX LBA に対して 0.5% までの小さいところではちょっとした接触か 直径が 1 トラック幅程度のスポット、LBA が MAX LBA の 17% まで進むとぐるっと円を描くような 1 ~ 2 トラック幅の傷が 1 プラッタに発生、真ん中あたりで複数プラッタ同時に円周状の傷が発生。LBA が真ん中あたりの大きめの傷は、不良ブロックスキャン中に HDD を 15cm ほど持ち上げて傾けた時にスキャンしていたブロック近辺だ。動作中にドライブを持ち上げたり、傾けるとすぐに損傷が発生するほどに繊細なのだろうか?置き直すまでは手で持っていた。それでも強い衝撃が有ったのか?0 fill をしてみて、不良ブロックを代替させてみた。不良ブロックをスキャンした時にあったブロックは全て代替した。新たな不良ブロックが増えた。Zero Fill 後に不良ブロック採取を行った後の SMART 情報WD40EZRZ 不良ブロックマップ PDF Zero Fill 後 WD40EZRZ 不良ブロックマップ テキストデータ Zero Fill 直後 (1 行 1 LBA)スポット的に 0 fill してみたところ、不良ブロックのうち 18310384 .. 18310391 の範囲は代替不能になっていた。書き込むと dmesg に次のようなログが残る。[75749.150998] ata3.00: exception Emask 0x0 SAct 0x40 SErr 0x0 action 0x0[75749.151003] ata3.00: irq_stat 0x40000008[75749.151007] ata3.00: failed command: READ FPDMA QUEUED[75749.151013] ata3.00: cmd 60/08:30:f0:64:17/00:00:01:00:00/40 tag 6 ncq 4096 in[75749.151013] res 41/40:00:f0:64:17/00:00:01:00:00/40 Emask 0x409 (media error) <F>[75749.151016] ata3.00: status: { DRDY ERR }[75749.151018] ata3.00: error: { UNC }[75749.152271] ata3.00: configured for UDMA/133[75749.152285] sd 2:0:0:0: [sda] [75749.152287] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE[75749.152289] sd 2:0:0:0: [sda] [75749.152291] Sense Key : Medium Error [current] [descriptor][75749.152295] Descriptor sense data with sense descriptors (in hex):[75749.152296] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 [75749.152305] 01 17 64 f0 [75749.152309] sd 2:0:0:0: [sda] [75749.152312] Add. Sense: Unrecovered read error - auto reallocate failed[75749.152314] sd 2:0:0:0: [sda] CDB: [75749.152316] Read(16): 88 00 00 00 00 00 01 17 64 f0 00 00 00 08 00 00[75749.152326] end_request: I/O error, dev sda, sector 18310384[75749.152340] ata3: EH complete代替できたブロックもあることから、空きを使い果たす前にマッピング制約に引っかかった感が有る。復帰が難しいドライブだ。2016/10/15 追記: 不良発生時の記録
2016.10.07
コメント(0)
ネットワークドライブをバックアップ先にして バックアップと復元(Windows7) を日曜日に実行開始した。総容量 1.2Tibyte だ。2 日経過して進捗 38% だ。バックアップ先に作られた .zip ファイルは 4067 個、1 個のファイルサイズは max 200Mibyte ほど。リソースモニターを見ていると、200Mibyte 程になるまでファイルを集めて(大きいファイルは分割して) .zip ファイルを C:\System Volime Information\Windows Backup\Staging\ 以下のフォルダに作る。出来上がったらネットワークドライブへコピーするという動作を繰り返しているようだ。それらはすべて Microsoft Security Essentials (MsMpEng) のスキャン対象になっている。ネットワークトラフィックを見ていると .zip ファイルの転送に合わせて 35 秒 90Mbits/sec で送信, 20 秒(殆ど送受信無し) の繰り返しだ。積極的に並列化しているように見えない。さて、どうやって早くしよう C:\System Volime Information\Windows Backup\ の下を Microsoft Security Essentials のスキャン対象から外すか... セキュリティを変更してアクセス権を獲得する必要がある。待て、メインマシンで実験をするなんてとんでもない。
2016.10.04
コメント(0)
ハードディスク WDC WD40EZRZ が運用開始 2 ヶ月半で不良セクタ(ブロック)が発生した。バックアップ先として運用していた。使用容量は全体の 2/3 程 (2^10 単位で 2.5Tibyte)だ。不良セクタ位置などは特定していない。2016/10/15 追記: 不良ブロック調査気づいたのは朝、Windows update でリブートした後、BIOS 設定画面で止まっていたことだ。画面のメッセージを見ると「ハードディスクを交換しろ」と表示されていた。起動直後に C5 代替保留は 10 ブロック程度だった。WD Data LifeGuard Diagnostics で FAIL してする。Extend test (飛び飛びで表面検査していると思われる) で先に進まない。定期的に「スッチャ」と音がするので、不良ブロックを読もうとして再試行している。SMART の C5 代替保留が 0x22(=34)ブロックとなった。検査をすると代替保留が増える。不良ブロックはある程度広がりが有りそうだ。検査と平行して緊急のバックアップ先を仕立てることにした。空き容量を持っていそうな Linux マシンを起動してファイルを整理する。おそらく 1shot 分ギリギリ入りそうな 1.8Tibyte を確保できそうだ(先の使用量は履歴付き)。バックアップを始める。色々と調査とディスク入れ替えを始める前にバックアップが全くない状態は避けたい。さて、久しぶりに秋葉原に電車で買い出しに行ける理由が出来たな...2016/10/15 追記: 不良ブロック調査
2016.10.02
コメント(0)
久しぶりに再稼働させた AMD Athlon64 X2 マザーボードで linux kernel のコンパイルをしていた。コア数 2 に対して並列数 4 だ。コンパイル途中で cc1 や as が segmentation fault で強制終了してしまった。.config を何も考えずに他から持ってきたのが原因? そんなことで segmentation fault になるはずはないよな。CPU のヒートシンクをさわるとかなり熱い。あれ? Q-Fan control disable だとファンが最速にならないんだっけ?(多分色々と勘違いしている) ファンの PWM 信号ピンをコネクタから抜き、強制的にファンを最速にする。CPU が正しく命令実行できていない。インストールからやり直しだ。もう一度 linux kernel コンパイルからやり直し。今度は強制終了は発生せず make 完了。as が segmentation fault になるのが意外だった。重い最適化をしていないのに? ラベル解決、アドレス確定処理、ニーモニックと機械命令の 1 対 1 変換 (いくつかは 1 対 多のうちどれかを選ぶことになるのでアドレス確定が揺らぐはず) で CPU のクリティカルパスに触れているのか。もう 3, 4 世代くらい前の CPU とマザー、熱いねぇ。
2016.09.30
コメント(0)
23 時頃だろうか、彼方此方のサイトのページが開かなくなった。普通に言えば「ネットに繋がらない」という状態だ。調べてみると LAN-WAN ルーターに内蔵された DNS サーバーから応答が得られない状態だった。IP レベルでは接続は維持されている。家内で運用している proxy server, DNS cache server が参照している上流 DNS サーバーを 8.8.8.8 (google が運用している DNS server) にすると(していると)接続できるようになった。ルーターが au one net から受けた DNS サーバーの設定を見るとプライマリ, セカンダリとも空欄になっていた。まさか DNS サーバーを止めた? au one net のインターネット接続の設定情報を見ると DNS サーバー設定のアドレスが書かれていた。DNS サーバーの設定は Windows 10 PC ならば「スタート」-「設定(歯車アイコン)」-「ネットワークとインターネット」-「アダプターのオプションを変更する」で出てきた接続アイコンをダブルクリックして「プロパティ」-「インターネットプロトコルバージョン4」-「次のDNSサーバーのアドレスを使う(を選択して入力できる)」設定だ。手動設定になった?ルーターを再起動してみる。WAN 側の DNS サーバーアドレスが設定された。設定情報のページと違うアドレスだ。ルーターの DNS サーバーも回復した。色々と調べず、ルーター再起動で良かったのか。
2016.09.19
コメント(0)
Linux のデバイスドライバ屋にとって Android の Linux と www.kernel.org の Linux の大きな差の一つが switch class だ。switch class は Audio jack や HDMI 端子の接続・切断を uevent で通知するクラス・ドライバだ。ユーザーランドからは /sys/class/switch あるいは /sys/class/extcon の下にノードが見える。退職前の仕事は Android 5.0 (Lollipop) でドライバ屋だった。久しぶりに switch 周りの kernel source を見てみると見あたらない。Android switch class の移植について と言うドキュメントが見つかった。得られた情報で探してみる。switch class は流浪のドライバだ。android 上では drivers/switch/ にある。多分今は「有った」と言った方が正しいかもしれない。本家の Linux では drivers/staging/android/switch/ から、drivers/extcon/ へ移り、名前も switch_dev_register から extcon_dev_register に変わってしまった(LKML で見つかった修正記録)。ドライバ屋にとって頭が痛い変化だ。Kernel のバージョンを上げる様な話では工数の見積もり、実際の移行段階では「リンクが出来ない」という単純な躓きから、挙動に変化が無いのかソースコードの査読とテストをしていく。「関数名や構造体の変更くらい誰かに任せればいいのに」と言われそうだ。心配なんだ。良く読んで検索・置換では対応できない仕様変更に追従する必要が有る。プログラミングの技量と良く気づいて探求する性格を持ち合わせている「誰か」なんだ。switch class をそのまま移植していたなら、開発現場の悩みも減ったであろう。あぁ、自分は辞めることで減らしてしまったな。
2016.09.05
コメント(0)
linux kernel の module_param の実装を眺めていた。ユーザーランドからは /sys/module/{module_name}/parmeters/{parameter_name} でアクセスできるノードの実装だ。文字列型ノードに書き込む setter 関数は param_set_charp だ。この中で maybe_kfree_parameter と kmalloc_parameter を呼び出している。中でリスト操作をしている。Kernel 4.7.x だと、リスト操作をする直前・直後で spin lock を使って排他制御をしている。分かりやすい排他だ。少し古い Kernel 4.1.x は排他制御の方法が違っていた。maybe_kfree_parameter と kmalloc_parameter を見てみると、排他制御のコードは無い。何処かでしているはず、と思い追ってみる。ちょっとチートな dump_stack を使って call trace を採取する。呼び出し順に並べると vfs_write, kernfs_fop_write, sysfs_kf_write, module_attr_store, param_attr_store, param_set_charp の様になった。maybe_kfree_parameter と kmalloc_parameter のリスト操作に有効な排他制御を探すと、param_attr_store でグローバルな mutex param_lock を掴んでいた。「多重に無駄なロックは設けない」という方針だから、リスト操作の直前・直後では排他制御をしていない。Linux Kernel 内は前提条件も依存性が高い。どこで実装か変わったか探す。Kernel 4.2.x のmaybe_kfree_parameter 関数の実装が変わっていた。もしかして sysfs の module parameter なんてそんなに高頻度に平行アクセスするわけでもなく... というのも変わってくるのかな。
2016.08.25
コメント(0)
秋月 GPS ロガー SPORT-GUIDE MATE の PC アプリ GPS Sport を動かし、GPS ロガーからログを取り出そうとしたら、プロダクトキーを求められた。Windows 10 に移行した時にインストールができたので使えると思った。キーが必要だったことをすっかり忘れていた。移行元の Windows Vista PC は起動可能な状態で残してある。レジストリからキーを取り出すことにした。HKEY_CURRENT_USER\Software\iTravel-Tech Applications\cyclingApp Canmore\OptionsSetting\RegProdKey_Canmore に平文文字列として格納してあった。レジストリより収集した文字列を入力して、ログ取り出し機能が動いた。Work Space 設定を古い記録が格納されているディレクトリに合わせたら、古い記録もアプリに表示されるようになる。当面は Windows10 で動かすとして、通信プロトコルが不明なままだと、PC アプリが動かなくなった時点でこのデバイスも寿命なのかなぁ。
2016.08.15
コメント(0)
実家に帰っている間、自宅の windows10 マシンの電源を遠隔操作で入れることができず難儀していた。リモートデスクトップ接続ができない。Windows10 マシンの ether I/F に Wake On LAN の設定をしてあったのに Magic Packet で起動しない。公開 HTTP サーバーに家内 LAN に対して Magic Packet を出す CGI を作ってある。実家で「高速起動を Off にする」と良いということまで調べた。帰ってきて試してみた。自分の PC には効果が無かった。古い RedHat 系の Linux をインストールしてあり、/etc/sysconfig/network-scripts/ifcfg-eth00 に ETHTOOL_OPTS="wol g" を設定して確実に Magic Packet で起動するマシンがある。このマシンに USB BUS switcherを接続して、Photo MOS リレー部分を Windows10 の電源スイッチ回路に並列することにした。ssh でログインし、原始的に stty, echo, sleep で USB BUS switcher を制御して、電源ボタンを押す操作をする。USB BUS switcher 機能の殆どを使わず、無駄な使い方かもしれない。Magic Packet 受信用 USB-Ether アダプタも動作が不確実だったし...
2016.08.13
コメント(0)
2 日間、弟夫婦の子供とポケモンGOの狩りに付き合った。延べ 3, 4 時間は外を歩いただろうか?ポケストップは 5~10 分歩いて隣接ポイントに到達する場所だ。駅や人が多い公園まで出る。弟がモバイルバッテリーを持ちプレーを続けた。出張のために買ったのか?と聞いたら、ポケモンGOのために買ったと。Android デバイスの充電ドライバ屋だった自分はモバイル・バッテリーの減り方はどうあるべきなのだろうと、観察して考えてみた。まぁ、なんだ。GPS ドライバ、ジャイロドライバ、 JNI 層を弄ってチートするというのは無しで。モバイルバッテリを長持ちさせる条件はスマホの電池充電量が増えも、減りもしない状態だ。これは意外かもしれない。充電と放電をすることで損失が 1~2 割ほど発生する。モバイルバッテリから供給した電力が全て電池充電以外の回路動作に使われている状態が理想なのだ。モバイルバッテリ側で観測できる物理量だけで、充放電量が推測できるだろうか?供給電圧、供給電流、供給時間、それらの変化履歴、ちょっと難しそうだ。スマホ内蔵電池の充放電を止める(上の図で I(Rsense)=0 となるように制御する)機能は多くの Charger コントローラに内蔵されている。これは低温・高温時に充電を止め、電池内部の化学反応を最小にする機能として回路実装されている。アプリケーションから "B. Control Boost On/Off" の経路で Charger を制御できる API が有れば良い。Android 標準の API には備わっていない。使い方が難しいからだろう。自分はテスト機能として実装した。/sys から潜ったノードに書き込むと充放電停止状態になる。標準 Android を改造することなく、実装するとなると大がかりになる。"A1. R/W Battery Status" と書かれた経路で充電状態を内臓ストレージに書き込み、USB の gadget driver 経由で MSC/PTP/MTP のいずれかのプロトコルでモバイルバッテリに充電・放電状況をフィードバックする。2~3分程度の周期で、供給電圧 VBUS を変え、単位時間当たりの充放電進行が 0% になるようにする。おおよそ VBUS 電圧を低くすれば充電速度が落ち(場合によっては充電負けし)、VBUS 電圧を高くすれば充電速度が速くなるので、拮抗する条件を探せばよい。モバイルバッテリーからのフィードバックを MSC/PTP/MTP 経由で読み出せばモバイルバッテリ状況表示アプリも作れるであろう。難点は MSC 接続の時、Storage を mount/unmount する繰り返しをすることだ。ほかのアプリに影響が出てしまう可能性が高い。はじめは Bluetooth 経由でモバイルバッテリに充電進行をフィードバック、ステータス収集することも考えてみた。理想的なフィードバックが可能な代わりに、コストが嵩む。親子でモバイルバッテリの電力を分け合えたら、あるいは 2 個持ち歩き、各々で楽しめたらなと。
2016.08.12
コメント(0)
常用サーバーのハードディスクが不調になっていた。dmesg で見ると似たような sector で Medium Error が発生していた。今は買い換えもままならないので不良ブロックを登録する事にした。「前も、不良ブロックを登録したのになぁ。」dumpe2fs -b /dev/sdc1 で不良ブロックリストを確認した。エラーになったブロックの前後を含めて登録してある。今回は fsck.ext4 -c /dev/sdc1 で自動的に不良ブロックを登録することにした。man fsck.ext4 を読んでみると -c オプションは "If any bad blocks are found, they are added to the bad block inode to prevent them from being allocated to a file or directory." と説明されている。"add" (追加)なのかと安心していた。昼間半日かけて scan が終了、fsck から色々と問題があるので修復するか?と質問攻め状態になっていた。全て yes で答えてやり過ごす。dumpe2fs -b /dev/sdc1 で不良ブロックリストを確認する。不良ブロックが綺麗サッパリ少なくなっていた。え?前に登録した不良ブロックリストは捨ててしまったの?どうも renew (再構築) してしまったらしい。まぁ、使えるからいいかと思って、運用を再開、2 時間も経たずに不調になった。別の不良ブロック・スキャンツールを使用して不良ブロックを抽出する。今度は一晩掛かった。パーティション・オフセット、LBA を ファイルシステムのブロック番号に変換する加工して fsck.ext4 -l badblock-list.txt /dev/sdc1 で登録する。既にあるファイルに被ったらどうなるのだろう?次のようなメッセージが出てきた。File /furuta/aclog/volt/2016/04/26/200000.log.gz (inode #16385172, mod time Tue Apr 26 20:59:59 2016) has 19 multiply-claimed block(s), shared with 1 file(s):<The bad blocks inode> (inode #1, mod time Fri Aug 5 08:24:05 2016)Clone multiply-claimed blocks<y>? yesどうやら、badblock 登録してファイルに被ってしまったら、引っ越しコピーをするらしい。ファイルも無事だった。688Gibyte 中 7.12Gibyte 使用、不良ブロックがポツポツと増えた。LBA の分布を見ると円周方向にちょっと壊れた感じだ。あと 5 年くらいは使うつもりなのだけど。
2016.08.04
コメント(0)
頼まれて Windows10 の移行作業に出かけたため、日記はサボり。10 時に始めて終わったのは 21 時になってしまった。おおよそ移行作業が終わって画面などの調節作業をしていた。高齢世帯でもあり、画面に表示される文字サイズの調整をしていた。Windows10, Internet Explorer 11 の設定が複雑すぎる。気付いた文字サイズに関わる設定を並べてる。IE11 - 表示/拡大/n%IE11 - 表示/文字サイズ/{最大..最小}IE11 - 下のステータスバー右下 n% (機能はメニューと同じ)IE11? - 何かのマウス/タッチパットジェスチャー ([Ctrl] キーを押しながらホイール操作 なのだけど、タッチパッドをなぞっていたら突然表示サイズが変わる。どういう条件でジェスチャー成立?タッチパット設定を見つけて、一部のジェスチャーを無効にしたほうが良かったか)Windows10 スタート/設定/システム/ディスプレイ/テキスト、アプリその他の項目サイズ[スライダー] (なんでパーソナル設定とか、簡単操作に分類しないのだ? 従来の Windows 互換性?)昔のアナログアンプ(いわゆるステレオコンポ)に例えれば音量調整ボリュームが 4 箇所も散りばめられたデザインだ。紛らわしいのも含めると次の項目もある。IE11 - ツール/インターネットオプション/デザイン・フォントWindows10 スタート/設定/簡単操作/拡大鏡Windows10 スタート/設定/簡単操作/その他オプション/カーソルの太さWindows10 スタート/設定/簡単操作/字幕/字幕のサイズそれぞれ変化内容や適応範囲に差がある。ただ単に「大きく」「小さく」「変わらないでほしい」という希望に対して、理解が必要な項目が多い。理解の不足を補う操作誘導も変わってしまった。ヘルプボタンや Tip がなくなった代わりに、リンクが現れる。別の設定に飛んだり、Microsoft の Web ページが現れたり、何が起きるか分からない。「使い慣れた操作感」だそうで。たまたま自分の誕生日に行ったので、御祝も兼ねた食事を頂いた。15 時くらいに作業完了の予定だったところ、時間が掛かって申し訳なく思う。46 才にもなって、父母意外と過ごす誕生日は初めてだったのだ。貴重な経験でもあった。
2016.07.22
コメント(0)
Windows10 移行作業で問題が発生していないか点検作業を続けている。デジカメで撮った画像ファイル 74 枚を喪失していることが分かった。回路実験に関わる画像だ。間が悪いことにバックアップを取っていない。喪失原因は RichCopy でコピーに失敗したのが原因だと推測している。バックアップがないので完全な断定はできない。RichCopy には断定できるだけでも次の問題があることが分かった。コピー先のセキュリティ設定に失敗するのが原因でコピーができない。2 ~ 100Gbyte 程のファイルが並ぶとネットワーク越しのコピーでコピー先のファイルサイズが 0 になる(3 つあるスレッド数設定を 1 にして Verify すれば問題が起きないかもしれない。この設定にすると robocopy 並みの速度になる)。ネットワーク越しコピーでコピー先のファイル内容がすべて 0x00 になる。サイズは一致するので問題に気づきにくい。RichCopy ネットで検索すると早いと評判は良い。有名ニュースサイトでは有用なツールとして紹介していることもある。コピーを正確にできるという基礎的な要件を満たしていない。ツールとして使えない。事の発端はそもそも GPT パーティション・ディスクの互換性だ。Windows Vista ←→ Windows10 のどちらの方向の 作成→認識 もできない。気づきにくい問題とは思えない。様子を見るに MBR, GPT パーティションパーサーの作りこみが甘いだけに見える。史上最高とキャッチコピーを謳う前にやることがあるだろう。Microsoft 大丈夫なのか?
2016.07.19
コメント(0)
Windows Vista マシンから Windows10 マシンへ移行する作業はじめた。想定外の問題多発で日記を数日サボっている。まだ作業は続くので日記をサボり続ける。問題を列挙していく、(1) Windows Vista と Windows10 の GPT パーティション・ハードディスクが相互に互換性がない。→ Windows Vista で慣らし運転していた 4Tbyte のハードディスクを 3Tbyte のハードディスクに再コピーする。4Tbyte の HDD を Windows10 に、3Tbyte の HDD を Windows Vista に接続してネットワークコピーする。注: Linux の testdisk で GPT パーティション情報を修復しようとしたが失敗している。Rich Copy による HDD to HDD、Windows Vista to Windows10 のコピーでも問題が発生している。(2) Windows7 で使えていた IODATA Magic TV GT (GV-MVP/XZ3) がモニタの HDCP 未サポートによる問題で再生できなくなった。ノート: Windows7 で動作確認し、Windows10 へアップグレードしたら動作しなくなった。→ Magic TV GT 専用 PC を急遽仕立てる。都合録画移行作業(録画情報のバックアップ/リストア)を 2 回行う。注: Windows Vista で使っていたビデオカードを移設しても問題が解消しなかった。(3) 電源ボタンを押しても Windows10 マシン AX88XM-A が起動しなくなる。AC スイッチ On/Off で復旧する。原因不明→ 解決は (4) の対応(4) Windows10 マシン AX88XM-A が不安定になる。突然リブートしてしまう。原因不明。→ A88XM-A の UEFI 設定にある DDR3 メモリクロックを 1 ランク下げて安定化した。組み立て時に memtest は 2 日くらい安定して動作していた。BIOS バージョンを 3001 に上げる。(5) A88XM-A の Anti surge protect が働き起動 2, 3 秒後にいったん電源が落ちてしまう。ハードディスクによくない動作だ。ハードディスク x 3、SSD x 1、BD-R ドライブ x1 のフル構成にしたら発生するようになった。→ Anti surge protect を disable にする。(6) (1) のコピー元にしようとした Windows Vista マシン M3A-H/HDMI が不安定になる。突然リセットしてしまう。電源ボタンを押しても Power LED が点灯せずファンが数秒回るだけで止まったり、BIOS 設定修正中にもリブートしてしまう。→ 電源交換をする。いろいろと取り外して移行したので、負荷が軽くなったのが問題? これにより、電源がはじめから入らない現象は消えた。Windows 起動後に突然リセットする現象は解消せず。(7) Windows Vista マシンの M3A-H/HDMI の Onboard Video 構成はかなり不安定だ。GPU が停止して GPU ドライバが再初期化することがしばしばあった。Onboard Video の GPU クロックを上げても不安定だった(2016.7.19 追記: 元々最低周波数設定)。→ (6) の作業中に Video Card を外していたのを戻す。(8) Windows Vista 上で RichCopy を使って 4Tbyte HDD to 3TByte HDD のコピーに失敗した。コピー先のセキュリティ設定がなぜか RichCopy ではアクセスできない設定になっていた。→ セキュリティ設定を手動で設定した。コピー元は単純なテキストファイルでセキュリティ設定は普通に Logon User (自分) がアクセスできるのに(9) RichCopy で Windows Vista から Windows10 にコピーする作業で 2Gbyte ~ 約 100Gbyte 巨大ファイルが並ぶとコピーできない(ファイル・エントリーは作成されるのでコピーが成功したかに見えてしまう)。→ 手動でコピー。ファイルサイズ差をコピー条件に設定して再挑戦したが失敗している。RichCopy のマルチスレッド数を上げたのが原因? Windows10 側のファイルサーバー機能が何かおかしい?(10) RichCopy で Windows Vista から Windows10 にコピーする作業で一部のファイル内容が全て 0x00 になっていた。といっても 約 55万個 あるファイルのうち確認できたのは 100 個ほどのファイル、確認作業中に奇跡的に見つかった。→ プログラムを作成し異常コピーが作られたファイルを確認中。やはり RichCopy のマルチスレッド数を上げたのが原因?(12) Windows10 のフィードバックを求められたとき、フィードバックをした(駄目出し)。フィードバックの管理で Microsoft Account を使用したら、Windows10 のログオンが Microsoft Account に切り替わってしまった。ローカルアカウントではログオンできない。→ Windows 10 - Microsoft アカウント から ローカル アカウントへ切り替える方法を使って戻す。何で回答作業と管理をするだけで MS account に切り替わるのだ?(13) Outlook2007 の仕分けとルール通知を export/import したが、仕分け先フォルダが見つからずエラーになった。ノート: .pst ファイルも import したので同一なはず。→ 仕方なく手動で再設定する。まだ何か起きるの?
2016.07.18
コメント(0)
Linux 3.10.10 x86_64, AMD A6-5200 で動作している VirtualBox で Windows7 64bit を動作させていた。これを Windows10 にした。普通に Upgrade しようとすると「CPU が対応していません」という旨の診断メッセージが出て upgrade できない。Windows10 DVD ISO ファイルを仮想光学ドライブにマウントして、Upgrade すると CompareExchange128 に未対応だと表示された。原因が分かった。CMPXCHG16B 命令だっけ?cpu instruction CMPXCHG16B is disableに有るように、次のように仮想マシン設定を変更すれば良い。% VBoxManage setextradata [vmname] VBoxInternal/CPUM/CMPXCHG16B 1こうして Windows10 に upgrade できた。結果が芳しくない。おおよそ 1 日程度放置しているだけで Blue screen で止まるようになった。2 回発生している。バックアップは無し。うーん、CMPXCHG16B 命令ちゃんと動作していないのかな。アンインストールと設定変更の泥沼を泳げば 1 ヶ月以内に解決する?
2016.07.11
コメント(0)
実家の LIFEBOOK AH45/DC を Windows10 に upgrade する作業に再挑戦する。富士通のサポートページに『Windows 8にアップグレードする前に「BIOSセットアップ」の「USB設定」を変更してください』とある。Windows8 に upgrade する際の問題が Windows10 への upgrade でも起きていた。先のサポートページには問題を起こすソフト・ドライバが書かれている。Windwos8 に upgrade する際は最新に差し替えるようにとの指示だ。今回はディスプレイドライバなど必須なものを除き、パフォーマンスアップを目的とするドライバ、アンインストールしても操作不能にならないドライバ・ソフトはアンインストールした。Upgrade 作業に USB メモリを使用できない。DVD-R にWindows10 アップグレード ISO イメージを焼いて実家へ赴く。起動時に [F2] 連打で BIOS 設定画面を出す。詳細/USB設定/レガシーUSBサポート を「使用しない」に設定する。終了/変更を保存して終了する を選択して Windows7 を起動する。DVD-R に焼いた Windows10 を自動再生し upgrade 手順を始める。以降は upgrade を進める選択をして upgrade が始まり、Windows10 をインストールできた。Windows10 インストール成功後、レガシーUSBサポートの設定は「使用しない」のままにしておく。この設定でも Windows10 は USB メモリを認識する。「使用しない」のままでできなくなることは USB メモリから起動することだ。父の使用状況ではほぼ不要な機能だ。レガシーUSBサポートを「使用する」に設定すると、起動時に USB メモリを検出、あるいはアクセスする処理で問題を起こし、処理が停止しのではと推測している。BIOS がレガシー USB サポートで USB コントローラと USB メモリにアクセスする処理と、Windows の起動ドライバが USB コントローラをアクセスする処理が衝突したか、何かの不備がどちらかに有ったかだ。ああ、Windows10 になってしまった。色々と操作方法が違うのに。
2016.07.10
コメント(0)
2016.7.11 追記: LIFEBOOK AH45/DC を Windows10 Upgrade する手順が見つかる土日は管理組合の予定が入っているかと勘違いしていた。再確認したら来週の予定だった。実家に出向き、Windows10 アップグレード作業をする。作業対象は LIFEBOOK AH45/DC Windows7 64bit だ。バックアップ作成まで進めておいた。ただ寝ているだけの簡単な仕事はずだった。Upgrade を始めて再起動するところまでは遅いながらも進む。再起動して水色の Windows10 ロゴが表示されたところで止まる。ブートメディアを使わない方法で 2 回とも同じ状態になった。通常ならドット・リング(なんて言ったらいいのだろう)が回りは始める。USB memory ブートを試みる。ブート作業の繰り返し周期は遙かに短くなる。ハードディスクか、DVD ドライブをアクセスしたと思われる直後から、何も進まない状態になった。BIOS でいくつか設定を弄ってみる。有線LAN、無線LAN、Hyper Thread、ハードウエア省電力、ブートデバイスからフロッピーを外す、自動スリープ(何だっけ?電池切れ間際動作指定)、どれも変化無し。まぁ、思っていたことはある。Windows10 にすると操作方法が変るし、できていたことができなくなる。父にとってはフォトビューワー関連の変更がかなり不満なはず。それでも upgrade するのか?
2016.07.09
コメント(0)
2016.7.11 追記opengrok をインストールしたときの日記PukiWiki をインストールしたときの日記pukiwiki と opengrok を新待機系に組み入れた。「新」と付くのは pukiwiki と opengrok を動かすために新しく構築した仮想マシンだからだ。本番系に昇格する前に待機系として稼働を続けている。直ぐに気づき、使用困難になる様な問題は起きていない。細かな設定調整は必要だ。いままで野良サーバーを 本番系 - 待機系 で運用していた。wiki ページを弄りだし 編集系(一般的には開発系)も欲しくなってきた。今までは 本番系のファイルを編集したり、増していた。数行が変ったり、ファイルが増えるだけなので相互の関連矛盾は発生しにくい。wiki ページは書きかけもある。ページそのものが無くなる可能性も有る。手軽に関連(リンク)を張ることも(切ってしまうことも)できる。公開ページにする前にある程度収拾した状態にしないと、読みにくいとおもう。「読みにくい」はもう少し具体的な問題点に分解する必要が有りそうだ。あれ?仕事の現場で使っていた wiki ページに編集系なんて言う構成は無かったような。なにか系の構成や想定している使い方に問題?いずれ気付いたときには「ううっ」と苦しんでいるか、「まぁ、これで良かったんだ」と思っているかだ。え? wiki ページに何書くか、あまり考えていないって?
2016.07.08
コメント(0)
機能が素朴な PukiWiki を家内のテストサーバーに組み込んで試用し始めた。1.5.1 UTF-8 版を選択する。ソースコード(整形済みテキスト)を内容に使う予定なのでcodehighlight.inc.php code_0_6_0_pr3i_mod ダウンロード場所(PukiWiki 内の codehighlight.inc.php ページ) という plugin を組み込んでみる。作業の大筋は codehighlight.inc.php インストール節に書いて有るとおりだ。codehighlight は対応バージョンが 1.4.6 だ。1.5.1 UTF-8 版で使うには環境の違いを乗り越える必要が有る。ダウンロードして zip ファイルを展開し、漢字コードの修正から始める。漢字コードを UTF-8 にする。nkf をインストール。多分何かの都合でインストール済みになっているだろう。$ sudo apt-get install nkf以下 pukiwiki を設置したディレクトリを ${wiki_page}、code_0_6_0_pr3i_mod を展開したディレクトリを ${down_load_path}/code_0_6_0_pr3i_mod として書く。次のようにして漢字コード変換する。$ cd ${down_load_path}/code_0_6_0_pr3i_mod$ for f in `find . -name '*.php'`; do nkf -w --overwrite $f; done$ cd wiki$ for f in `find . -name '*.txt'`; do nkf -w --overwrite $f; done$ cd ..複数行プラグインを有効にする。${wiki_page}/pukiwiki.ini.php を修正、define 第 2 引数の値を 0 にする。define('PKWKEXP_DISABLE_MULTILINE_PLUGIN_HACK', 0); // 1 = DisabledTAB 幅を修正する(任意)。${code_0_6_0_pr3i_mod}/plugin/code.inc.php を修正、define 第 2 引数文字列の空白数で指定する。define('PLUGIN_CODE_WIDTHOFTAB', ' ');ファイルから読み込むソースコードのコード体系を UTF-8 に変換して出力する指定をする(扱うソースが全て英語記述なら任意)。ソースを読んでの推測、${code_0_6_0_pr3i_mod}/plugin/code.code.inc.php に追加、上記の TAB 幅修正箇所の近傍が良い。エンコーディング指定文字列は mb_convert_encoding リファレンス参照define('SOURCE_ENCODING', 'UTF-8');block(複文|複式) 構造の Expand/Fold ツールチップ表示を修正する(任意)。${code_0_6_0_pr3i_mod}/plugin/code/codehighlight.php 次のように修正する。修正前$_code_expand = _('すべて開く');$_code_short = _('すべて閉じる');修正後$_code_expand = _('Expand all');$_code_short = _('Fold all');ファイルをコピーする。ファイルパーミッションとオーナーは必要に応じて設定すること、アクセス許可設定に応じて sudo を cp に付けて実施する。$ cd ${down_load_path}/code_0_6_0_pr3i_mod$ 必要に応じて chmod$ 必要に応じて chown$ cp -rp image ${wiki_page}/$ cp -rp plugin ${wiki_page}/$ cp -rp skin ${wiki_page}/$ cp -rp wiki ${wiki_page}/option の下はコピーしなくても動作する。css に style を追加する。${wiki_page}/skin/pukiwiki.css.php を修正、@import "./code.css"; 行を追加する。style 記述が並んでいる辺りだ。// Output CSS ----?>@charset "<?php echo $charset ?>";@import "./code.css";pre, dl, ol, p, blockquote { line-height:130%; }blockquote { margin-left:32px; }body,td {次のような Wiki 記述で動作確認する。#code(c){{#include <stdio.h>int main(int argc, char **argv, char **env){ printf("Hello World.\n"); return 0;}}}編集履歴保存方法が課題として残る。ページは wiki/*.txt に保存されている様に見える。git で履歴管理できそうだと考えている。トリガーは PKWK_UPDATE_EXEC が使えそうだ。
2016.07.07
コメント(0)
OpenGrok で linux kernel を解析して web page で表示する機能を構築する練習と試用を始めた。OpenGrok のページには Java 1.7 と Tomcat 7.x (with Java at least 1.7) で動作すると書いてある。git repository から取ってきたソースとドキュメントは Java 1.8, tomcat8 が必要だと書いてある。ubuntu 14.04 を使っているので再構築が面倒だ。OpenGrok の git repository の commit faf25670332e0ce1b1c8dfd80a020c7035e5003d 直後に branch を作り checkout する。'/' 二重打ちにより repo1.maven.org/maven2 よりダウンロードできない問題があったので build.xml を修正する。URL の末尾 '/' を削除。Java 1.7 でもコンパイルできるようになった。faf25670 直後の commit で Java 1.8 に移行している。いずれ、Java 1.8 対応以外の修正を取り込まないとなぁ...2016.7.8: git diff 出力追加diff --git a/build.xml b/build.xmlindex 3a1579d..5e139bc 100644--- a/build.xml+++ b/build.xml@@ -110,7 +110,8 @@ Copyright (c) 2005, 2015, Oracle and/or its affiliates. All rights reserved. <property name="test.svn" value="${test.repositories}/svn"/> <property name="test.razor" value="${test.repositories}/razor"/>- <property name="mvn.repository" value="http://repo1.maven.org/maven2/"/>+<!-- <property name="mvn.repository" value="http://repo1.maven.org/maven2/"/> -->+ <property name="mvn.repository" value="http://repo1.maven.org/maven2"/> <available property="compileSystrayClient" classname="java.awt.TrayIcon"/>検索結果の表示フォーマットの微調整をする。うーん、[all...] と検索結果を省略しなくても良いんだけどなぁ。src/org/opensolaris/opengrok/search/Results.java と src/org/opensolaris/opengrok/search/SearchEngine.java の getContext() メソッド呼び出しの limit パラメータ値を false に変更した。xml ファイルでパラメータ指定できないのね...。ページを再ロードしないと表示が変らないのか...。2016.7.8: git diff 出力追加diff --git a/src/org/opensolaris/opengrok/search/Results.java b/src/org/opensolaris/opengrok/search/Results.javaindex dec69bf..446849b 100644--- a/src/org/opensolaris/opengrok/search/Results.java+++ b/src/org/opensolaris/opengrok/search/Results.java@@ -200,7 +200,7 @@ public final class Results { ? new FileReader(new File(sh.sourceRoot, rpath)) : null; sh.sourceContext.getContext(r, out, xrefPrefix, morePrefix,- rpath, tags, true, sh.builder.isDefSearch(), null, scopes);+ rpath, tags, false, sh.builder.isDefSearch(), null, scopes); } }diff --git a/src/org/opensolaris/opengrok/search/SearchEngine.java b/src/org/opensolaris/opengrok/search/SearchEngine.javaindex 7aaa51f..429560b 100644--- a/src/org/opensolaris/opengrok/search/SearchEngine.java+++ b/src/org/opensolaris/opengrok/search/SearchEngine.java@@ -367,7 +367,7 @@ public class SearchEngine { if (Genre.PLAIN == genre && (source != null)) { hasContext = sourceContext.getContext(new InputStreamReader(new FileInputStream(source + filename)), null, null, null, filename,- tags, nhits > 100, false, ret, scopes);+ tags, false, false, ret, scopes); } else if (Genre.XREFABLE == genre && data != null && summarizer != null) { int l; try (Reader r = RuntimeEnvironment.getInstance().isCompressXref() ?検索結果の 1 ページ当りの行数は、/var/opengrok/etc/configuration.xml (自分は配置位置を変更している) を修正して 100 行に増やした。property ctags 設定の後ろに次を追加する。100 行でも linux kernel では複数ページになることがある。 <void property="hitsPerPage"> <int>100</int> </void>さて、もう一つサービスの構築方法を勉強しないと。
2016.07.04
コメント(0)
Windows Vista 32bit から Windows 10 64bit へ移行する作業を行っていた。データ格納ドライブを複製して、しばらく運用してみる。計画している作業段階の一つだ。予定よりも手間取る。Norton Ghost 12 も Acronis True Image (WD 版) とも MBR パーティションから GPT パーティションへ NTFS ボリュームのコピーができなかった。コピー先選択肢に現れない。True Image は「論理セクタサイズが違う」と指摘している。そうなのかなぁ。WD20EARX(hdparm 出力) がコピー元、WD40EZRX(hdparm 出力) がコピー先だ。どちらも物理 4096 bytes/sector、論理 512 bytes/sector だ。クラスタサイズは どちらも 4096 bytes だった。2016.7.19 追記: RichCopy は推奨できないツールだと判明した。正確にコピーするという最低限の要件を満たしていない。・コピー先のセキュリティ設定に失敗するのが原因でコピーができない。・2 ~ 100Gbyte 程のファイルが並ぶとネットワーク越しのコピーでコピー先のファイルサイズが 0 になる(3 つあるスレッド数設定を 1 にすれば問題が起きないかもしれない。robocopy 並みの速度だ)。・コピー先のファイル内容がすべて 0x00 になる。サイズは一致するので問題に気づきにくい。始めからクローニングをするツールとして RichCopy を使っておくべきだった。オプションを見ると暗号化ファイルのサポートが有りそうだ。処理もスレッド分割され、バッファサイズ(オプションではキャッシュサイズと表現されている)も指定できる。robocopy でコピー漏れしていた圧縮が掛かったテキストファイルを RichCopy でコピーできている。作業中に色々とできそうな時間もあった。敢えてサボることにした。
2016.06.27
コメント(0)
祖母の家から引き上げた FMV-A8290 を Windows7 から Windows10 に upgrade した。download がなかなか進まない問題は、Windows 10 のページからダウンロードして upgrade をするツールを使って解決する。upgrade 処理の途中で止まってしまうことが 2 回あった。1 回目はウイルス検出ソフトが妨害している旨が表示されていた(Microsoft security essentials なんだけどな)。2 回目は 0x80070652 と表示された。Microsoft の公式な対応方法は無いらしい。エラーコードが有るのは想定済みの事象のはず。対応策は無しなのか。Q&A の流れを見るとなんか地雷を踏みそうな手順ばかりだ。ウイルス検出を行うソフトを停止する手順が多く示されていた。Microsoft Security Essentials でフルスキャンを実施することにした。きっと未検査のファイルが有るのがお気に召さないのだろう。この後 Windows10 への upgrade 処理は全て実行された。upgrade 後、後付けした USB Wireless LAN アダプタ Logitech LAN-W150N/U2 が不調になっていることに気付いた。アクセスポイントに繋がらない。さらに接続処理を試みる無線接続・切断全般の操作ができなくなってしまう。再起動すると BIOS 起動画面に戻らず 10 分程度経過した後にブルースクリーンだ。ドライバを 2016/4/5 版から 2014/6/6 版に戻して解決した。Ralink って Mediatek に買収されたんだよなぁ。あぁ、ソフト品質が落ちたのかも。うん、まぁ、何だ。多く語ると真夜中に訪問客が来そうなので、Mediatek が出している SoC 向けの Linux の kernel source を読んで頂ければ。Windows10 の気がかりなところは、不調になっている場合でも、点 "…" が走るアニメが動いていて、今処理が進んでいるのか、回復の見込みが全くないのか、進んでいないとして何をしようとして停止しているのか全く把握できないところだ。Cortana に聞けば何か分かるのかな...「進んでいないんだけど」と質問すれば回答できるくらいの機能は有る?Windows10 になったところで scankeylx でプロダクトキーを保存、フルバックアップを実施 (Control panel に "バックアップと復元(Windows 7)" と出るのが謎だ)。バックアップ先に Linux の samba server は使えないのかなぁ。仮想ディスクイメージの作成・展開ができない旨のエラーが出た。USB 接続のハードディスクを使って解決する。次は実家の PC だ。
2016.06.17
コメント(0)
祖母が亡くなってから、使う人が居なくなったノート PC FMV-A8290 を土曜日に自宅に引き上げた。もっぱら使っていたのは介護に行っていた自分の母と父だった。使わなくなった無線 LAN アクセスポイント Aterm WR8170N も引き上げた。バックアップはしなくても良いと言われていた。とは言うもののデータを消してしまっては復活できない。バックアップデータ保管専用マシンに転送する作業を行う。バックアップ中にアクセスポイントの動作確認を平行して実施、特に問題なし。USB 端子が付いているのでストレージサーバーにできる機能は未確認。いずれはトイレ内ファイルサーバー?色々と添付物があったはず。引き上げたときには見つからず。何処にしまったか自分の記憶も定かではない。リストアに使用するメディアとクリーンインストールに使用するリカバリメディアを作成する。ハードディスクの隠しパーティションに入っているイメージだ。メディアから ISO ファイルを作る。奇妙な手順だ。恐らくメディア作成時に PC の中に ISO イメージがあるに違いない。陽に見えないのでメディアから吸い出した。続けて Windows7 から Windows10 にする作業を始めた。実家の PC も Windows10 にする作業を頼まれているので予行演習も兼ねている。16 時頃から始めて 23 時時点で終わらない。何台か Windows10 アップグレードを実施している中で最も長い。頼まれた作業について再検討だ。ISO イメージを焼いた媒体持参か、USB メモリに格納しておくか。予定では Windows10 に upgrade 後、もう一度バックアップを作成する。scankeylx でプロダクトキーの一覧を作成するところまで進めるつもりだった。ああ、最後の画面が自分の blog だったんだ。
2016.06.16
コメント(0)
何時もほぼ読み捨ての Source Next のメールマガジンを少し読む。Recover Keysという 何処か(scankeylx) で見たようなソフトがあった。 売りは 8000 種類以上のソフトに対応だということ。個人開発だと 8000+ 種類のソフトに対応出来る検証能力は無理だ。scankeylx はその点は仕方がない。scankeylx は 2 条項 BSD ライセンスでソースを公開している。scankeylx のソースを使って有償ソフトを作ることも可能だ。あんなソースコードでも商用転用したのだろうか?興味が沸く。Recover Keys のページを読むとその仕組みを直接説明する言葉は「独自のアルゴリズム」という表現くらいか。うーん、説明しているようで説明していない。まぁ、詳しく説明するのも難しいよな。ソース読んで下さいでは...Recover Keys の Q&A を読むと、あれ?と思うところが有る。Windows プロダクトキーを探すソフトを書いてみると、気付く事柄がある。それに気付いていないか、気付いたとして、対処できるアルゴリズムを作れていなく、その背景を説明できていないのでは?と思う。scankeylx のソースコード、ドキュメントを読んでいたとしても、一部のみ転用だったのか。あるいは古いリリース r0911a 以前のものを参考にした? r0911a のソースは日本語コメントなので開発できたとして、日本国内かなぁ。scankeylx を windows 上で実行できるようにしたかったなぁ...
2016.06.13
コメント(0)
仕事をしていたときに書いていたコードが open source として公開されていた。あまり詳しく書くと、色々と身元ばれしそうだ。リンク先 AV watch 記事一覧の中で取り上げられた製品のうちの一つと書いておこう。退職したので会社で管理しているリポジトリに一切アクセスできない。その後、どうなったのか噂で聞くこともない。open source で公開される事は確かだったので、ダウンロードして確かめてみた。open source で公開されるとはいうものの、開発中のソースは持ち出し出来ない。記憶に有る自分が書いたコードとどれだけ一致するかだ。読み直してみると、次の 2 点に気付いた。・回路設計の方で特性測定が行われず、仮実装した変換関数が置き換わっていた。申し送り事項として変わることを予想していた箇所だ。32 + 18 行。・ソースコード上で 2 箇所、バグ原因として 1 要因に由来する修正がされていた。SoC 内部の clock, power gating に関して On したつもりが、msleep() で idle になったと判断して Off になってしまう問題らしい。SoC メーカーが仕様を示さず、開発中も困難がつきまとった問題だった。Linux では clock tree 管理 drivers/clk 以下 clk_enable() 関数など、power tree 管理 drivers/regulator 以下 regulator_enable() 関数などが用意されていて、これらのフレームワークを使っていれば問題を起こすことは無いはずの所だった。SoC メーカーがこれらの管理機構を破壊する様な形で実装された kernel source を提供してきたのだ。多分バグ取りに苦労したと思う。おおよそ、自分が書いて退職後に見た 234kbyte のソースコード中 3 箇所に問題が有った。気付かない修正が有ったとして 5 箇所くらいか。修正されたコードを見て大体誰が修正したか予想は付く、ベテラン H さんかな。あるいは新人 H くん君? N さんに任せたのかもしれない。1 行でもコーディングスタイルの癖は出るものだ。あー、自分の癖の方が強いか。修正をした職場の同僚は「頼むヨー」と置き土産に嘆いていたのだろう。合計で 60 行程度の追加・修正になったのだろうか?自分の手で修正できなかったもどかしさは有る。それ以上に「あぁ、このソースはもう忘れて良いのだ。覚えていて何か出来るだろうか?」という意志の変化を促し、問いかけを自分にしていた。置き土産の関連ドキュメントは更新されただろうか?
2016.05.30
コメント(0)
Windows 10 PC を用意するため、ケースから M2NPV-VM(Athlon X2 5600+ 4GiByte) マザーボードを外し、P8H61-I (Core i3-2120T 8GiByte) に入れ替えることにした。Micro-ATX から Mini-ITX サイズダウンだ。処理性能はそう変わらない?M2NPV-VM の PCI スロットの並びにあるコンデンサが液漏れしているのを見つける。修理か退役か、M2NPV-VM の行き先は今のところ無い。今の計画を考えた時点で、「退役」だったはずだ。想定より悪化している状況を見ると判断がぶれる。CPU 周りのコンデンサは目視で異常なし。PCI スロット周辺で高周波で電流変動が大きい負荷が有ったか? 拡張カードは GV-R455D3-512I (ファンレスビデオカード)、USB 3.0 I/F uPD7202000F1、USB 2.0 (uPD720102GC) + KB/Mouse IF(CSC0101A-S16G) 数は多い。どれも消費電力は大きくない。過去に 5 年ほど 24 時間連続、ほぼ全スロット使用した履歴が原因なのか。マザーボードは熱で変色している。以前より判っていたことだ。ノース・サウスブリッジの裏も茶色く変色している。消費電力が大きく、今後常用はあり得ないボードだ。サウスブリッジの NF-430 の date code は 0619 だ。製造はおおよそ 10 年前。新しい、マザーボードを... ではなくて、現状でやり繰りするのだ。
2016.05.09
コメント(0)
System V init が大好きだ。と言うわけで devuan を試す。インストール後、パッケージの依存関係が壊れて追加パッケージ samba をインストールできない状態が発生した。インストールの手順を少し変えると回避できることが判ったので記録しておく。試したのは DVD 版と NETINST 版だ。どちらも同じ手順で問題解消できる。インストール手順のうち、変更部分だけ抜粋する。インストールを進めると、次の "Software selection" 画面になる。ここで [Go Back] をクリックする。"Installation step failed" となる。これは予定通りの表示だ。[Continue] をクリックする。次のステップを選ぶ画面になるので "Configure the package manager" を選択し、[Continue] をクリックする。リポジトリを選択する画面で、"security updates" と "release updates" のチェックを消し、[Continue] をクリックする。ノート: "security updates" と "release updates" は後で有効にする。再び、"Software selection" 画面に戻る。ここで命綱として "SSH server" に check を入れておくことができる(他の check を入れて fail してしまったことが有った)。[Continue] をクリックして先に進む。インストール後、ログインすると XScreenSaver のダイアログが表示される。[Settings] をクリックして先に進む。ノート: 後で "security updates" と "release updates" リポジトリを有効にして # apt-get update; apt-get upgrade すると解消する。System V init ツールをインストールする。$ suPassword:# apt-get install chkconfig# apt-get install sysv-rc-confここで必要なパッケージ群を追加インストールする。好みがあると思うので詳細は省略する。synaptic Package Manager 経由または、/etc/apt/sources.list を編集し # apt-get update を実施して "security updates" と "release updates" リポジトリを有効にする。追加パッケージ群の依存関係は確定しているので矛盾が生じにくくなっているはずだ。そうだ、肝心なことを忘れていた。確かに PID=1 は init だということを確かめよう。$ ps ax | head -10 PID TTY STAT TIME COMMAND 1 ? Ss 0:01 init [2] 2 ? S 0:00 [kthreadd] 3 ? S 0:00 [ksoftirqd/0] 5 ? S< 0:00 [kworker/0:0H] 6 ? S 0:00 [kworker/u2:0] 7 ? S 0:01 [rcu_sched] 8 ? S 0:00 [rcu_bh] 9 ? S 0:00 [migration/0] 10 ? S 0:00 [watchdog/0]160507-022053 furuta@devuan02:~$参考: ps uaxww の出力うん、init だね。
2016.05.06
コメント(0)
IO-DATA GV-MVP/XZ3 (mAgicTV GT) をインストールした PC を Windows 7 から Windows 10 にアップグレードした。GV-MVP/XZ3 の移行手順をかなり省略してしまった。今のところ問題なし。概略的には次の通り。1. Windows 7 の環境にて GV-MVP/XZ3 のソフトウエアを最新の状態にしておく2. 念のため録画情報をバックアップしておく3. Windows 10 にアップグレード4. GV-MVP/X3シリーズ Windows 10アップデーター(ページ下半分)でアップデート(ページ上半分にある DiXiM Media Server 3 もアップデートした方が良いのだろう)5. 再生確認 特に問題なし (リストアはしていない)Windows 10 に移行後、困ったことを挙げる。2016.7.19 追記 Windows7 から Windows10 にアップグレードしたらモニタの HDCP 未サポートにより GV-MVP/XZ3 が使えなくなった構成があった。Windows7 では HDCP サポートだと判定されていた。視聴・録画環境として主に使っているのであれば Windows7 のままにするのが良いかもしれない。あるいは、PC の分解・組み立てをする覚悟があるのなら、一度すべての内蔵ハードディスク、SSD の接続状態を戻せるように記録・マーキングしてから外し、内容を消してもよいハードディスクを接続して Windows10 をプロダクトキー省略で新規インストールしてみて、地デジ相性チェッカーで判定してから判断するのもよいだろう。a. スリープ状態がすぐに解除され、resume してしまう。ネットワークアダプタの Magic Packet でのみ、コンピュータのスリープ状態を解除できるようにするにチェックを付ける(アップグレードで消えちゃった?)b. 「スタートアップ」を容易に設定できなくなった (Windows10 スタートアップ を検索すれば方法が見つかる。コマンドラインを使って解決、スタートアップを隠す理由有るのかなぁ...)c. 通知領域が変化する度に音が鳴る。設定 → システム → 通知とアプリケーション → 「次のアプリからの通知を表示する」に並んだアプリアイコンをクリック → 通知が届いたら音を鳴らす → オフ (ここまで設定が細かいのに通知領域のアイコンにマウスカーソルを合わせても Tip 表示が出なくなった。デフォルトの通知音が何というか、萎えてしまう。スマホで使うことを前提に目立たない様にしたのかな)Windows 7 から続いていた「mAgicTV Manager が resume 時に終了してしまう(あるいは終了した状態になっている)」 問題は Windows 10 でも解決されなかった。タスクスケジューラーに トリガー {イベント時, ログ: システム, ソース: Power-Troubleshooter, イベントID: 1} にて resume 時の処理に 次の .BAT ファイルを起動する様に登録して解決する方法は継続した(cygwin が必要)。c:pushd "C:\Program Files\I-O DATA\mAgicTVGT"c:\cygwin\bin\sleep.exe 4start mtvManager.exepopd周囲の PC も可能であれば Windows 10 に移行している。AMD E350 の 32bit 環境で Windows 10 にアップグレードできるのに、仮想マシンの AMD E450 64bit 環境では Windows 10 に "CPU 未サポート" でアップグレードできない。何か問題有ったっけ?
2016.05.01
コメント(0)
blog, web サービスに障害が出ていたので報告します。ご迷惑をおかけしまして申し訳ございません。4/24(日) 10:35 ~ 10:45 の間、一時的に blog 画像を中心に www.ftechworks.mydns.jp に格納しているコンテンツにアクセスできない状態が発生しました。また、ログより 4/24(日) 2:20 頃よりアクセスが遅くなっていたと推測されます。原因: ブロードバンドルーターの DNS 機能不全対応: ブロードバンドルーター再起動 これにより一時的にアクセス遮断長期対応家内サーバーの DNS 上流設定を google public DNS server にして改善するか、しばらく様子を見ることにします。
2016.04.24
コメント(0)
USB device に付けられた serial number から /dev/ttyUSBn ポートを探す処理をサーバーの復旧作業中にデバッグしていた。root で lsusb -v で iSerial に表示される文字列から device node を見つける処理だ。良い機会なのでメモに残す。ネットを検索すると大抵は /etc/udev/rules.d/* を書き換える方法だ。ちょっとした実験や彼方此方の linux PC でちょっと試すのであれば udev 設定を書き換えるのは大げさだ。次のスクリプトで iSerial から /dev/ttyUSBn を見つけることができる。download findttyusb.sh script (USB serial から ttyUSB を割り出すスクリプトをダウンロードする)#!/bin/bash# find ttyUSBN by serial code.function FindTtyUSB() { for node in /dev/ttyUSB* do node_name=`basename ${node}` serial_no=`udevadm info --query=property --name=${node_name} | grep ID_SERIAL_SHORT | cut -f 2 -d=` if [ "${serial_no}" == "$1" ] then echo ${node} break fi done}for sn in $*do echo "${sn} `FindTtyUSB ${sn}`"done実行例$ ./findttyusb.sh A400gCMOA400gCMO /dev/ttyUSB1簡単な bash script なので出力フォーマットやエラーステータスが気にくわなければ目的に合うように書き換えられると思う。少々効率が悪いのは不問としている。秋月で売っている FTDI の FT232RL は USB serial number がユニークに振られている。少々値は張っても、しっかりとした作りだと思える点の一つだ。
2016.04.15
コメント(0)
家内サーバーの復旧作業を続ける。このサーバーは副サーバーも兼任している。退職前に放置していたことを思い出す。正論を言えば副サーバーが正サーバーに依存していてはいけないのだ。ディスクスペース削減と正←→副間でお互いバックアップをしている。複雑な構成になってしまったのだ。お金が使えれば整理もありだろう。今は無理だ。NFS mount option に bg,soft を付ける。縮退起動可能なようにした。samba server (smb, nmb) は 2 回、background で stop/start を遅延して行うようにした。起動直後は名前解決、ネットワークドライブの接続が不安定になる。頻度は低いので大きな問題としない。デバッグ中に script の再帰ループを作ってしまう。やってしまった。副サーバーで行っていた商用電源監視サービスの調子がまだおかしい。調べてみると電圧・周波数を互いに取り違えて採取している。サービスを記述している bash script を修正する。表示、ログ出力を状況把握がしやすいように強化する。こうして、複雑な構成は復活するのであった。以下は本日の出来事色々サーバー保守のため液晶モニターが欲しいなと思い、ハードオフに行く。うーん、程度が分かるものは大体 3,240円 からか。324円, 540円 の物は程度表示もなし。ブラウンモニタが有るのだし我慢するか。20:59 頃に地震あり。地鳴りが聞こえだした後、揺れ出す。突き上げるような揺れだった。スーパーのお米が尽きていたのは、何か有ると噂があったから?
2016.04.14
コメント(0)
新しい公開 web サーバーを構築している途中で、家内サーバーの不調に気づく。情報更新が止まっていた。再起動すれば直るだろうと、のんきに考えていた。再起動に失敗する。/etc/init.d/* の実行過程を見ると NFS mount をしようとして失敗していた。先に進まない。何回か試しても同じところで止まっている。NFS mount をする記述を comment out して、再起動する。先には進んだようだ。何かおかしい。NFS mount に依存しないサービスが動いていない。よく見るとファイル、ディレクトリが作れていない。touch や mkdir を試してもエラー。read only mount になってる。dmesg を見で local disk の I/O エラーを疑う。「USB 接続のハードディスクは信頼性低いよなぁ...」。色々試した結果、USB ケーブルの接続切断をする。何とも中途な異常だ。volume label で mount できているのに I/O エラーになったと言うことだ。fsck -f で local 接続の disk のうち、内蔵、USB 接続とも unmount 可能な disk を全て check する。これで NFS mount 無しで再起動できるようになった。NFS mount をするように記述を戻す。NFS mount のところで止まるようになった。もう一回 NFS mount の記述を comment out して、再起動する。手動で NFS mount するとできてしまう。途中 iptables で自家中毒してしまったかと思い。iptables を設定せずに動作させても NFS mount で止まってしまうことも分かった。手動で NFS mount 出来たときに、mount point まで移動して、ls してみると I/O error と表示された。「え? NFS mount した directory で I/O error を食らった。もしかして、NFS server が言っていることなのか?こっちも USB 接続だよなぁ。」NFS server に入って export している directory を ls してみる。同様に I/O error を食らった。ああ、NFS server の方でも disk 不調だったか。NFS server を停止 lsof で open している process を見つけて止める。NFS server でも unmount して fsck -f を実施した。journal を回復する以外は問題なし。NFS mount する記述を元に戻して、再起動する。まだおかしい。今度は smb (samba) が起動せず、何かを待つ状態で止まったままになる。nmb もおかしい可能性がある。 wins (NetBIOS かもしれない) 名前解決ができない。これも、nmb, smb を service command で stop/start すると使えるようになる。詳細に書けば {smb stop, nmb stop, nmb start, smb start} を 2 回繰り返せば nmb, smb とも稼働する。理由は分からない。手で nmb, smb とも stop/start すれば、samba は機能するのだ。根本を解決する方法?拘らない。dirty hack で解決しよう。もう眠い、もうすぐ日にちが変わって 2:30 だ。明日は script で smb, nmb を stop/start する処理を書いて立て直し作業から始めるか。
2016.04.13
コメント(0)
サーバー乗り換えのため apache2.2 から ubuntu 上の apache 2.4 へ移行作業を進めた。設定ファイルを copy & paste しただけでは動作しなかった。まずは daemon を起動するときのエラー。Either all Options must start with + or -, or no Option may.Options 指定で有効にする機能に対して '+' が必須になった。うーん、記述文法としてそんなに拘るところなのかな...エラーを取り除いた後、ログファイルに次の行が残る様になった。cgi-bin に付いても同様だった。AH01630: client denied by server configuration: /www/virtual_server_root/html/AllowOverride, Order, Allow が Require に纏められてしまった。何だろなぁ。互換性が取れるような仕様にできなかったの?と言いたい。ExecCgi Option が ExecCGI に変わった。一部が大文字に変わった。えー、その何だ、いいよもう、百歩譲って変えるのはいいよ。でもさ、認識できない Option が有りますよと、ログに残らないのはどういうことよ。上記 2 つの問題で必要だった記述変更例は次の通り。変更前の例<Directory "/www/virtual_server_root/cgi-bin"> Options ExecCgi FollowSymLinks AllowOverride None Order allow,deny Allow from all</Directory>変更後の例<Directory "/www/virtual_server_root/cgi-bin"> Options +ExecCGI +FollowSymLinks # Add plus '+' sign, GI in capitals Require all granted # Rewrite AllowOverride, Order, Allow</Directory>ネットを検索すると Require all granted が良く見つかった。管理のために 自ホストと local network だけからアクセスできる様にするためのページは次のように制限する。 Require local Require ip 192.168.0.0/24デフォルトでは CGI が使えない。次のコマンドを投入して CGI module を組み込む。# a2enmod cgidおおよそこれで、httpd の基本的な動作は動くようになってきた。ようやくスタートラインに着けた。まだ長い。ずっと open source 界隈の問題と感じるところだ。互換性、継承性を考えずに仕様をコロコロと変えてしまう。どう見ても致命的な問題に対する仕様変更ではないのに。
2016.04.12
コメント(0)
退職してから時間を掛けてやってみたいことにようやく着手し始めた。自営の web サーバーを構築し直して、wiki (目的は章立て等の文書構造を保ちつつ、書き進められるページを構築する)、global もしくは opengrok 等のソースコードをブラウズできるサービスを提供する。作成過程をバージョン管理し文書の追記・改訂課程を共有できるようにする。あるいは、ブランチして複数の構成を提供できる。現在のほぼ画像を提供するだけの貧弱なサービスは止めずに、サーバーを切り替えるのも課題の一つだ。しばらく本格的な web server 構築をしていなかった。最新の環境を再勉強するだけで大分時間が掛かっている。慣れた人なら、半日で済む作業なのだろう。最も重い課題は自分のサボり癖を乗り越えることかもしれない。え?何を始めるのかって?
2016.04.04
コメント(0)
ソフトのリリースなので文体を変更して書きます。linux kernel driver の nandsim を改良した nandsim_prof をひっそりとリリースします。linux version 3.18.25 の kernel source tree に対してパッチを当てる diff 形式です。readme linkdownload link次の機能追加と改良をしてあります。・ページ追記操作回数を数え検査します・ページ読み出し操作回数を数えて検査します(read disturb 対策)・各ページ、各消去ブロックの操作回数カウンタ読み出せます・ページ書き込み、ブロック消去時に msleep() または schedule() を挿入します・ページ書き込み操作を高速化しました次の機能を変更してあります。・ステータスを /sys/class/mtd/mtdN node から読み出すようにしました・cache_file(backing store file) を使用したとき kernel panic を起こす問題を解消しました。raw NAND memory を直接使う開発なんて殆ど無いと思いますが現行の nandsim が使いづらい、kernel panic を起こして使い物にならない場合は試してもらえればと思います。kernel version は 3.18.25 を指定しています。その他のバージョンにも素直にパッチが当たると思います。ほぼ nandsim_prof.c というドライバを丸々追加するようなパッチです。diff ファイルを見ながら手作業で追加するのも簡単にできるでしょう。2ヶ月半 ubifs のテストを実施していました。同時に nandsim_prof の動作確認もしていました。kernel panic 等の致命的な問題は取り除いたつもりですが、何かあるかもしれません。そのときはご容赦願えればと思います。I release the linux kernel driver nandsim_prof which is enhanced from the driver nandsim. nandsim_prof is released as diff format file which patches linux kernel version 3.18.25 source code tree.readme linkdownload linkI added following features.+ Counts and checks partial page programming operation cycles.+ Counts and checks page reads cycles.+ Read counters in detail, all erase blocks, and program pages.+ msleep() or schedule() at writing page and erasing block.+ Slightly more faster at programming page.I also changed following features.+ Read status from nodes under /sys/class/mtd/mtdN node, instead of debugfs nodes.+ Fix kernel panic when using cache_file (backing store file).
2016.04.03
コメント(0)
2016/3/30 カードリッジ → カートリッジ 訂正(指摘ありがとうございました)Canon MG7530 を使い始めて 1 年と 2 ヶ月くらい経つ。インクが切れるのが早いかな?我慢しよう。インク交換の時の動作に疑問が有る。プリンタの操作パネルを開けても、カートリッジが動き続ける。インクが無くなると、パソコンの画面にインクが切れた旨と交換を促す指示が表示される。印刷が停止する。強制的に再開はできない。この状態でプリンタの操作パネルを開ける。操作パネルの下にインク・カートリッジがある。既に印刷は停止しているのに、パネルを開けてもカートリッジは左右に何度も往復する。外装の陰に入ったり、出たり。1 分くらいは動作し続ける。いつカートリッジを交換して良いのか、息が合わない。観察しているとカートリッジのランプが点灯(インク切れカートリッジは点滅)して完全停止する様だ。電子マニュアルには完全停止したと判断する方法は書かれていない。一度異常動作をさせたことがある。外装の陰からカートリッジ出たところで少し止まった。カートリッジを外したら、隠れるように移動し始めた。そのまま外れかけのカートリッジを内部の構造物にぶつけて非常停止させてしまった。外れた時点で、停止するような制御機構は無い。ぶつかって、トルク異常、あるいはモーター駆動と変位に狂いが出るまで動く。機構部を覆うカバーが開いているのに機構が動き続けるなんて、絶対に禁止だった会社に勤めていたことがある。Canon の基準ではカバーが開いていても、機構が動いていて良いのだろうか?インク切れで既に印刷は止まっているのだ。しかも、再開しない。オフセットがずれることも無い。この時点でカートリッジは交換作業位置に移動しておけばよい。パネルを開けたら直ぐ交換できる。一歩譲って、操作パネルが少しでも開き始めたら、全ての動作をキャンセルして、カートリッジを制止させ、交換位置にゆっくり移動しないのだろうか?そう言えば、Canon は東芝メディカルシステムを買収したんだっけ? 安全性に対する意識は大丈夫なんだろうか?
2016.03.29
コメント(2)
drivers/mtd/nand/nandsim.c を改造した nandsim_prof.c (リンク先は linux-stable repository の v3.18.25 tag に当てる diff patch) をひっそりとリリースしようと動作確認をしていた。NAND memory に backing store file を指定する cache_file parameter を殆どテストしていないことに気づく。cache_file を指定すると kernel panic する。負荷試験をしてしばらくして workingset_refault() 内部で NULL pointer access している。次のような kernel log だ。kernel 時刻が 3 桁台だ。手際よく実験すれば短時間で再現する。[ 491.193149] BUG: unable to handle kernel NULL pointer dereference at 0000000000000630[ 491.194058] IP: [<ffffffff811adb47>] workingset_refault+0x67/0xd0[ 491.194058] PGD 29fd3067 PUD 29fd9067 PMD 0 [ 491.194058] Oops: 0000 [#1] SMP [ 491.194058] Modules linked in: configfs deflate ubifs ubi cmdlinepart nandsim_prof nand nand_ecc nand_bch bch nand_ids mtd rpcsec_gss_krb5 nfsv4 nfsd auth_rpcgss nfs_acl nfs lockd grace sunrpc fscache binfmt_misc joydev serio_raw i2c_piix4 hid_generic psmouse usbhid hid e1000 [last unloaded: netconsole][ 491.194058] CPU: 0 PID: 64 Comm: kworker/u4:4 Not tainted 3.18.25-ubifs.ex0+ #10[ 491.194058] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006[ 491.194058] Workqueue: writeback bdi_writeback_workfn (flush-ubifs_0_0)[ 491.194058] task: ffff880034e22360 ti: ffff880034e40000 task.ti: ffff880034e40000[ 491.194058] RIP: 0010:[<ffffffff811adb47>] [<ffffffff811adb47>] workingset_refault+0x67/0xd0[ 491.194058] RSP: 0018:ffff880034e42fd8 EFLAGS: 00010246[ 491.194058] RAX: 0000000000000600 RBX: 0000000000000000 RCX: 0000000000000000[ 491.194058] RDX: 0000000000000006 RSI: 0000000000000022 RDI: 0000000000000000[ 491.194058] RBP: ffff880034e43008 R08: 0000000000000000 R09: 0000000000000000[ 491.194058] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000072[ 491.194058] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000019758[ 491.194058] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000[ 491.194058] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b[ 491.194058] CR2: 0000000000000630 CR3: 0000000029fd8000 CR4: 00000000000006f0[ 491.194058] Stack:[ 491.194058] ffff880034e43038 ffffea0000c65900 0000000000000000 0000000000000007[ 491.194058] ffff8800326af710 0000000000019758 ffff880034e43038 ffffffff81183cdd[ 491.194058] 0000000000000050 0000000000001cb2 ffffea0000c65900 0000000000000050[ 491.194058] Call Trace:[ 491.194058] [<ffffffff81183cdd>] add_to_page_cache_lru+0x3d/0x80[ 491.194058] [<ffffffff8118537f>] pagecache_get_page+0x9f/0x1e0[ 491.194058] [<ffffffffa0265be0>] get_pages+0xb0/0x180 [nandsim_prof][ 491.194058] [<ffffffffa0265cec>] read_file+0x3c/0xf0 [nandsim_prof][ 491.194058] [<ffffffffa026697c>] nandsim_do_state_action+0x8fc/0x1300 [nandsim_prof][ 491.194058] [<ffffffffa02678b8>] switch_state+0x1e8/0x4e0 [nandsim_prof][ 491.194058] [<ffffffffa0268224>] nandsim_hwcontrol+0x2c4/0x600 [nandsim_prof][ 491.194058] [<ffffffffa0251ebb>] nand_command_lp+0x4b/0x2e0 [nand][ 491.194058] [<ffffffffa024e652>] nand_write_page+0xf2/0x150 [nand][ 491.194058] [<ffffffffa02503af>] nand_do_write_ops+0x1ff/0x420 [nand][ 491.194058] [<ffffffff817521fb>] ? _raw_spin_unlock+0x2b/0x40[ 491.194058] [<ffffffffa0250720>] nand_write+0x60/0x90 [nand][ 491.194058] [<ffffffffa027fa6b>] ? ltree_add_entry+0x7b/0x1d0 [ubi][ 491.194058] [<ffffffffa023b230>] part_write+0x20/0x30 [mtd][ 491.194058] [<ffffffffa02381e4>] mtd_write+0x54/0x60 [mtd][ 491.194058] [<ffffffffa0283bba>] ubi_io_write+0x14a/0x710 [ubi][ 491.194058] [<ffffffffa0284668>] ubi_io_write_vid_hdr+0xc8/0x140 [ubi][ 491.194058] [<ffffffffa028137f>] ubi_eba_write_leb+0x19f/0x720 [ubi][ 491.194058] [<ffffffff810c2513>] ? mark_held_locks+0x73/0xa0[ 491.194058] [<ffffffff8174d6b7>] ? mutex_lock_nested+0x2e7/0x4d0[ 491.194058] [<ffffffffa02c3ba2>] ? ubifs_add_bud_to_log+0x82/0x490 [ubifs][ 491.194058] [<ffffffffa027eb24>] ubi_leb_map+0xb4/0xf0 [ubi][ 491.194058] [<ffffffffa02b8009>] ubifs_leb_map+0x89/0x110 [ubifs][ 491.194058] [<ffffffffa02c3e5c>] ubifs_add_bud_to_log+0x33c/0x490 [ubifs][ 491.194058] [<ffffffffa02a9bda>] make_reservation+0x40a/0x630 [ubifs][ 491.194058] [<ffffffff810c28ed>] ? trace_hardirqs_on+0xd/0x10[ 491.194058] [<ffffffffa02aa1d2>] ubifs_jnl_write_data+0x112/0x3e0 [ubifs][ 491.194058] [<ffffffff81191904>] ? __test_set_page_writeback+0x154/0x1c0[ 491.194058] [<ffffffffa02aec0c>] do_writepage+0x17c/0x240 [ubifs][ 491.194058] [<ffffffffa02aedc7>] ubifs_writepage+0xf7/0x1f0 [ubifs][ 491.194058] [<ffffffff8118ed6a>] __writepage+0x1a/0x50[ 491.310137] [<ffffffff81190ff3>] write_cache_pages+0x253/0x500[ 491.310137] [<ffffffff8118ed50>] ? set_page_dirty+0x60/0x60[ 491.310137] [<ffffffff811912f4>] generic_writepages+0x54/0x80[ 491.310137] [<ffffffff81191355>] do_writepages+0x35/0x40[ 491.310137] [<ffffffff81229917>] __writeback_single_inode+0x57/0x2e0[ 491.310137] [<ffffffff8122af7b>] writeback_sb_inodes+0x30b/0x550[ 491.310137] [<ffffffff817521fb>] ? _raw_spin_unlock+0x2b/0x40[ 491.310137] [<ffffffff8122b25e>] __writeback_inodes_wb+0x9e/0xd0[ 491.310137] [<ffffffff8122b5ab>] wb_writeback+0x31b/0x340[ 491.310137] [<ffffffff810c281d>] ? trace_hardirqs_on_caller+0x10d/0x1d0[ 491.310137] [<ffffffff8122b6e6>] wb_do_writeback+0x116/0x220[ 491.310137] [<ffffffff8122bbd0>] bdi_writeback_workfn+0x70/0x260[ 491.310137] [<ffffffff8108e3a2>] ? process_one_work+0x152/0x560[ 491.310137] [<ffffffff8108e424>] process_one_work+0x1d4/0x560[ 491.310137] [<ffffffff8108e3a2>] ? process_one_work+0x152/0x560[ 491.310137] [<ffffffff8108e8d2>] worker_thread+0x122/0x4f0[ 491.310137] [<ffffffff8174b450>] ? __schedule+0x410/0x940[ 491.310137] [<ffffffff8108e7b0>] ? process_one_work+0x560/0x560[ 491.310137] [<ffffffff810947de>] kthread+0xee/0x110[ 491.310137] [<ffffffff81752130>] ? _raw_spin_unlock_irq+0x30/0x50[ 491.310137] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 491.310137] [<ffffffff817528d8>] ret_from_fork+0x58/0x90[ 491.310137] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 491.310137] Code: e0 03 83 e3 03 4c 8b 2c c5 c0 09 d2 81 48 89 d8 48 c1 e3 0b 48 c1 e0 06 48 29 c3 4d 8d 74 1d 00 49 8d 84 1d 00 06 00 00 4c 89 f7 <4c> 8b 78 30 e8 f0 4c ff ff 49 8d 84 1d a8 06 00 00 48 ba ff ff [ 491.310137] RIP [<ffffffff811adb47>] workingset_refault+0x67/0xd0[ 491.310137] RSP <ffff880034e42fd8>[ 491.310137] CR2: 0000000000000630[ 491.310137] ---[ end trace ca77cb5f177245a8 ]---nandsim.c から nandsim_prof.c を派生される際に問題が混入してしまったのか?ソースの diff を眺めて見ても問題点は見つからない。眠くなって昼寝してしまった。調査再開、まてよ、元々の nandsim.c に問題が有ったのでは? back trace を眺める。get_pages() 関数が back trace に挟まっていた。ああ、なんだが怪しいと思っていた nandsim.c 内部に実装された get_pages() と put_pages() か。ファイルアクセスを高速化する目的で実装された get_pages() と put_pages() だと思われる。派生させる際に処遇に悩んでいた実装だ。他の kernel_read(), kernel_write() の使用例を見ると必須の実装ではない。元の nandsim.c から出来た module を組み込んでも同様の問題が再現する。余計な実装をして自爆したのか。linux kernel driver の僻地のようなところでは信頼性が高い実装を期待できない。実際 nandsim.c の様な実装が上手く動いていたとして、ファイルアクセスが早くなるのだろうか?そうは思えない。危険な複雑さを導入してまで見合う?取り敢えず get_pages() と put_pages() の実装は全て削除して負荷試験を再投入する。寝る間際、30 分ほどは持つようになった。朝起きたときにどうなっているだろうか?
2016.03.13
コメント(0)
ubuntu 14.04 をベースに kernel 3.18.25 に差し替えて UBI/UBIFS 負荷試験をさらに続けていた。root 権限でファイル操作をする負荷を掛けていた。root 権限だと「真の」file system full まで UBIFS volume に書き込める。file system full まで書き込む操作を繰り返しているうちに kernel は停止する。console (printk) 出力を見ていると次の 2 つの stack dump が典型的な kernel 停止直前の出力だ。(1) UBI assert failed in wl_tree_add at 203 (pid NNNN)(2) BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffffa0273800>] wl_tree_add+0x40/0xf0 [ubi](1) の wl_tree_add() で assert した stack dump(前後の出力をすべて含む)[ 348.007307] UBI error: __wl_get_peb: no free eraseblocks-- snip --[ 1177.689377] UBI error: __wl_get_peb: no free eraseblocks[ 1179.653004] [nandsim] nandsim_prof_page_progs_update: ERROR: Too many program cycles after erase. row=8192, c=4, page_prog_max=4[ 1179.665065] UBI assert failed in wl_tree_add at 203 (pid 2610)[ 1179.667078] CPU: 0 PID: 2610 Comm: ubifs_bgt0_0 Not tainted 3.18.25-ubifs.ex0+ #1[ 1179.669473] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006[ 1179.672855] ffff880007521688 ffff8800073478e8 ffffffff8174af24 dead000000100100[ 1179.675500] ffff880007520870 ffff880007347928 ffffffffa0274898 ffff880007347928[ 1179.680248] ffff880007520870 ffff880022179480 ffff880022178000 0000000000000000[ 1179.684895] Call Trace:[ 1179.686543] [<ffffffff8174af24>] dump_stack+0x51/0x6d[ 1179.689633] [<ffffffffa0274898>] wl_tree_add+0xd8/0xf0 [ubi][ 1179.693185] [<ffffffffa0274d03>] erase_worker+0x453/0x8a0 [ubi][ 1179.696695] [<ffffffffa02744a5>] do_work+0xc5/0x150 [ubi][ 1179.699884] [<ffffffffa0276afb>] ubi_refill_pools+0x20b/0x3c0 [ubi][ 1179.703683] [<ffffffffa027d219>] ubi_update_fastmap+0x39/0x10e8 [ubi][ 1179.707493] [<ffffffffa026eb7b>] ? ubi_next_sqnum+0x2b/0x60 [ubi][ 1179.711174] [<ffffffffa02761ce>] ubi_wl_get_peb+0x3e/0xc0 [ubi][ 1179.714612] [<ffffffffa0270518>] ubi_eba_write_leb+0x178/0x720 [ubi][ 1179.718360] [<ffffffffa02c976c>] ? ubifs_change_lp+0x16c/0x740 [ubifs][ 1179.722367] [<ffffffffa026de7b>] ubi_leb_write+0x15b/0x160 [ubi][ 1179.725887] [<ffffffffa02ad38e>] ubifs_leb_write+0xbe/0x150 [ubifs][ 1179.729564] [<ffffffffa02c115b>] ubifs_tnc_end_commit+0x35b/0x6c0 [ubifs][ 1179.733619] [<ffffffffa02b9f54>] do_commit+0x234/0x640 [ubifs][ 1179.737094] [<ffffffffa02ba652>] ubifs_bg_thread+0x1d2/0x220 [ubifs][ 1179.740872] [<ffffffffa02ba480>] ? ubifs_run_commit+0x120/0x120 [ubifs][ 1179.745527] [<ffffffff810947de>] kthread+0xee/0x110[ 1179.748425] [<ffffffff81752130>] ? _raw_spin_unlock_irq+0x30/0x50[ 1179.752177] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 1179.756077] [<ffffffff817528d8>] ret_from_fork+0x58/0x90[ 1179.759330] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 1179.762768] general protection fault: 0000 [#1] SMP [ 1179.763687] Modules linked in: deflate ubifs ubi cmdlinepart nandsim_prof nand nand_ecc nand_bch bch nand_ids mtd rpcsec_gss_krb5 nfsv4 nfsd auth_rpcgss nfs_acl nfs lockd grace sunrpc joydev binfmt_misc fscache serio_raw i2c_piix4 hid_generic usbhid psmouse hid pcnet32 mii[ 1179.763687] CPU: 0 PID: 2610 Comm: ubifs_bgt0_0 Not tainted 3.18.25-ubifs.ex0+ #1[ 1179.763687] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006[ 1179.763687] task: ffff880006a50000 ti: ffff880007344000 task.ti: ffff880007344000[ 1179.763687] RIP: 0010:[<ffffffffa0274800>] [<ffffffffa0274800>] wl_tree_add+0x40/0xf0 [ubi][ 1179.763687] RSP: 0000:ffff8800073478f8 EFLAGS: 00010286[ 1179.763687] RAX: ffff880007520870 RBX: dead000000200200 RCX: ffff880007520878[ 1179.763687] RDX: 0000000000000100 RSI: 0000000000000001 RDI: ffff880007347f58[ 1179.763687] RBP: ffff880007347928 R08: 0000000000000001 R09: 0000000000000001[ 1179.763687] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880007520878[ 1179.763687] R13: ffff880007520870 R14: ffff8800221793e8 R15: ffff880006a50000[ 1179.763687] FS: 0000000000000000(0000) GS:ffff88002fc00000(0000) knlGS:0000000000000000[ 1179.763687] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b[ 1179.763687] CR2: 00007f9911818cd8 CR3: 0000000028734000 CR4: 00000000000006f0[ 1179.763687] Stack:[ 1179.763687] ffff880007347928 ffff880007520870 ffff880022179480 ffff880022178000[ 1179.763687] 0000000000000000 ffff8800221793e8 ffff8800073479b8 ffffffffa0274d03[ 1179.763687] ffff8800073479b8 0000000000000246 0000000000000000 ffff8800221794d0[ 1179.763687] Call Trace:[ 1179.763687] [<ffffffffa0274d03>] erase_worker+0x453/0x8a0 [ubi][ 1179.763687] [<ffffffffa02744a5>] do_work+0xc5/0x150 [ubi][ 1179.763687] [<ffffffffa0276afb>] ubi_refill_pools+0x20b/0x3c0 [ubi][ 1179.763687] [<ffffffffa027d219>] ubi_update_fastmap+0x39/0x10e8 [ubi][ 1179.763687] [<ffffffffa026eb7b>] ? ubi_next_sqnum+0x2b/0x60 [ubi][ 1179.763687] [<ffffffffa02761ce>] ubi_wl_get_peb+0x3e/0xc0 [ubi][ 1179.763687] [<ffffffffa0270518>] ubi_eba_write_leb+0x178/0x720 [ubi][ 1179.763687] [<ffffffffa02c976c>] ? ubifs_change_lp+0x16c/0x740 [ubifs][ 1179.763687] [<ffffffffa026de7b>] ubi_leb_write+0x15b/0x160 [ubi][ 1179.763687] [<ffffffffa02ad38e>] ubifs_leb_write+0xbe/0x150 [ubifs][ 1179.763687] [<ffffffffa02c115b>] ubifs_tnc_end_commit+0x35b/0x6c0 [ubifs][ 1179.763687] [<ffffffffa02b9f54>] do_commit+0x234/0x640 [ubifs][ 1179.763687] [<ffffffffa02ba652>] ubifs_bg_thread+0x1d2/0x220 [ubifs][ 1179.763687] [<ffffffffa02ba480>] ? ubifs_run_commit+0x120/0x120 [ubifs][ 1179.763687] [<ffffffff810947de>] kthread+0xee/0x110[ 1179.763687] [<ffffffff81752130>] ? _raw_spin_unlock_irq+0x30/0x50[ 1179.763687] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 1179.763687] [<ffffffff817528d8>] ret_from_fork+0x58/0x90[ 1179.763687] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 1179.763687] Code: 90 31 c0 49 89 fd 49 89 f6 49 89 f4 65 4c 8b 3c 25 c0 b8 00 00 eb 0b 0f 1f 40 00 4c 8d 63 10 48 89 d8 49 8b 1c 24 48 85 db 74 40 <8b> 43 18 41 39 45 18 7c e7 7e 0d 4c 8d 63 08 eb e3 0f 1f 80 00 [ 1179.763687] RIP [<ffffffffa0274800>] wl_tree_add+0x40/0xf0 [ubi][ 1179.763687] RSP <ffff8800073478f8>[ 1179.946401] ---[ end trace 215d3a8314753d92 ]---(2) の wl_tree_add() で NULL pointer access をした stack dump 前後の出力をすべて含む[ 454.131725] UBI error: __wl_get_peb: no free eraseblocks-- snip --[ 608.154458] UBI error: __wl_get_peb: no free eraseblocks[ 620.956412] hrtimer: interrupt took 1965201 ns-- snip --[ 706.202702] UBI error: __wl_get_peb: no free eraseblocks[ 707.062650] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020[ 707.063510] IP: [<ffffffffa0273800>] wl_tree_add+0x40/0xf0 [ubi][ 707.063510] PGD 1dc52067 PUD 16212067 PMD 0 [ 707.063510] Oops: 0000 [#1] SMP [ 707.063510] Modules linked in: deflate ubifs ubi cmdlinepart nandsim_prof nand nand_ecc nand_bch bch nand_ids mtd rpcsec_gss_krb5 nfsv4 nfsd auth_rpcgss nfs_acl nfs lockd grace sunrpc joydev binfmt_misc fscache serio_raw i2c_piix4 hid_generic psmouse usbhid hid pcnet32 mii[ 707.063510] CPU: 0 PID: 2422 Comm: ubi_bgt0d Not tainted 3.18.25-ubifs.ex0+ #1[ 707.063510] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006[ 707.063510] task: ffff880025092360 ti: ffff880023374000 task.ti: ffff880023374000[ 707.063510] RIP: 0010:[<ffffffffa0273800>] [<ffffffffa0273800>] wl_tree_add+0x40/0xf0 [ubi][ 707.063510] RSP: 0018:ffff880023377cf8 EFLAGS: 00010202[ 707.063510] RAX: ffff8800259a5730 RBX: 0000000000000008 RCX: ffff880022672878[ 707.063510] RDX: 0000000000001b0d RSI: ffff8800259a5678 RDI: ffff8800226733b0[ 707.063510] RBP: ffff880023377d28 R08: dead000000100100 R09: 0000000000000000[ 707.063510] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800259a5740[ 707.063510] R13: ffff8800226733b0 R14: ffff8800259a5678 R15: ffff880025092360[ 707.063510] FS: 0000000000000000(0000) GS:ffff88002fc00000(0000) knlGS:0000000000000000[ 707.063510] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b[ 707.063510] CR2: 0000000000000020 CR3: 000000002e2bf000 CR4: 00000000000006f0[ 707.063510] Stack:[ 707.063510] ffff880023377d28 ffff8800226733b0 ffff8800259a5720 ffff8800259a4290[ 707.063510] 0000000000000000 ffff8800259a5678 ffff880023377db8 ffffffffa0273d03[ 707.063510] ffff880023377db8 0000000000000246 0000000000000000 ffff8800259a5760[ 707.063510] Call Trace:[ 707.063510] [<ffffffffa0273d03>] erase_worker+0x453/0x8a0 [ubi][ 707.063510] [<ffffffffa02734a5>] do_work+0xc5/0x150 [ubi][ 707.063510] [<ffffffffa02753b0>] ubi_thread+0x160/0x240 [ubi][ 707.063510] [<ffffffffa0275250>] ? ubi_wl_get_peb+0xc0/0xc0 [ubi][ 707.063510] [<ffffffff810947de>] kthread+0xee/0x110[ 707.063510] [<ffffffff81752130>] ? _raw_spin_unlock_irq+0x30/0x50[ 707.063510] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 707.063510] [<ffffffff817528d8>] ret_from_fork+0x58/0x90[ 707.063510] [<ffffffff810946f0>] ? __init_kthread_worker+0x70/0x70[ 707.063510] Code: 90 31 c0 49 89 fd 49 89 f6 49 89 f4 65 4c 8b 3c 25 c0 b8 00 00 eb 0b 0f 1f 40 00 4c 8d 63 10 48 89 d8 49 8b 1c 24 48 85 db 74 40 <8b> 43 18 41 39 45 18 7c e7 7e 0d 4c 8d 63 08 eb e3 0f 1f 80 00 [ 707.063510] RIP [<ffffffffa0273800>] wl_tree_add+0x40/0xf0 [ubi][ 707.063510] RSP <ffff880023377cf8>[ 707.063510] CR2: 0000000000000020[ 707.063510] ---[ end trace f74004a66509482e ]---未編集のログ出力負荷試験に nandsim.c を改造した nandsim_prof.c を使用している。これも後で整理しようと思う。nandsim_prof.c が "[nandsim] nandsim_prof_page_progs_update: ERROR: Too many program cycles after erase. row=8192, c=4, page_prog_max=4" と出力しているので page #8192 に対して 4 回書き込みをしていることが分かる。NAND memory によっては「追い書き」(partial write) 回数制限に抵触する。(1), (2) の stackdump は wear leveling 処理 drivers/mtd/wl.c で起きている。wl.c を十分に読解していない。wl.c の comment に有るように free, used, erroneous, scrub RedBlack-tree 構造、pq queue 構造がある。どこかで矛盾した状態になっているのだろう。wl.c の comment に書かれたことと source code を比べてみると CONFIG_MTD_UBI_FASTMAP がまとわりついている部分に関して comment の解説が乏しいことが分かる。後付けされたような fastmap が怪しい。drivers/mtd/Kconfig を読むと CONFIG_MTD_UBI_FASTMAP "Experimental feature" だと説明がある。default では "N" だ。ubuntu distribution ではわざわざ Y (defined) にしてある(/boot/configs-* を参照)。CONFIG_MTD_UBI_FASTMAP を .config から外し undefined (# CONFIG_XXX ... is not set) にして同様の負荷試験をしてみる。30~60 分しか負荷試験が持たなかったのが、半日以上連続試験に耐えている。退職前に気になっていた問題、出来ていなかった負荷試験はおおよそ終わる。仕事でさわっていた kernel の CONFIG_MTD_UBI_FASTMAP がどうなっていたかは既に記憶にない。そもそも kernel の version は近いものを選んでいて、違っている。UBI/UBIFS 以外にも自分が担当していたコードはある。これらは機器固有のコードだ。持ち出しは出来ない。持ち出したところで試す環境と手段がない。出来る範囲の心残りは無くなった。さあ、新しい課題を見つけよう。
2016.03.04
コメント(0)
linux の UBI, UBIFS のテストを継続して実施している。今のところ wl_tree_add() および rb_insert_color() を起点とした NULL pointer access の stack dump は再現していない。wear leveling のバランスは良くないことか分かってきた。512bytes/page, 16384bytes/erase_block, 8192 erase_blocks (NAND sim の標準デバイス、容量 128Mi+ bytes) のデバイス全体を 1 パーティションとして UBI のボリュームを作成して UBIFS を mount する。使用量 70~73% 限度にランダムパターン書き込み・読み出し・消去を繰り返する。NAND memory simulator driver の統計情報を見ると、平均の数値は良さそうに見える。一方、ほとんど使われない erase block が残る。Total wear: 3551638Total numbers of erases: 3551638Number of erase blocks: 8192Average number of erases: 434Maximum number of erases: 491Minimum number of erases: 1Number of ebs with erase counts from 0 to 49 : 261Number of ebs with erase counts from 50 to 98 : 1Number of ebs with erase counts from 99 to 147 : 6Number of ebs with erase counts from 148 to 196 : 27Number of ebs with erase counts from 197 to 246 : 269Number of ebs with erase counts from 247 to 295 : 218Number of ebs with erase counts from 296 to 344 : 545Number of ebs with erase counts from 345 to 393 : 563Number of ebs with erase counts from 394 to 442 : 367Number of ebs with erase counts from 443 to 491 : 5935どうやったら、stack dump 出やすくなるのかな。
2016.02.25
コメント(0)
ファイルシステムテストツールを作っていたのは、退職直前で ubi, ubifs の動作に疑問と問題が有ったためだ。退職直前で ODM 元で行った頼んでもいない修正が原因だとわかった。それでメデタシメデタシとは思っていなかった。linux kernel の device driver 屋だったので、filesystem の実装(しきたり的なもの)には疎い。問題を追っていたときに ubi, ubifs のソースも見ていた。driver 屋的に「なんか、うさんくさい」と感じるところが有った。すぐに指摘できるのは全体的にエラーリカバリーの弱さだ。ubi, ubifs のソースを読んだ限りにおいて、MTD device (NAND memory) の どこか 1 page でも訂正不能 page が有ると mount 不能に陥り、file を 1 つ(あるいは directory を 1 つ)失う程度の軽傷がファイルシステム全体を失う重傷になる。ext3, ext4 といったよく使われる file system では考えられない仕様だ。叩かれ弱い。ubi, ubifs 設計・実装者が問題を避けている。排他制御や multi thread の実装も追いにくかった。wear leveling は上手く行くのか?解説資料も検索すると見つかる。見つかった中に徹底したテスト結果を論ずるものは無い。前置きが長くなってしまった。いま再現性を確認中という段階で、次のような kernel の stack dump が出た。ファイルを削除中に発生している。ubifs wl_tree_add で検索すると、bug 指摘が多く見つかるのでよくある問題だと思われる。[ 5507.669488] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008[ 5507.669553] IP: [<ffffffff813bb3a8>] rb_insert_color+0x18/0x170[ 5507.669595] PGD c9afa067 PUD c9ac8067 PMD 0 [ 5507.669629] Oops: 0000 [#1] SMP [ 5507.669655] Modules linked in: deflate ubifs ubi cmdlinepart nandsim_prof nand nand_ecc nand_bch bch nand_ids mtd pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) cuse nfsd rfcomm bnep bluetooth auth_rpcgss nfs_acl nfs lockd grace sunrpc i915 fscache snd_hda_codec_hdmi snd_hda_codec_realtek intel_rapl snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp eeepc_wmi snd_hda_intel asus_wmi coretemp sparse_keymap snd_hda_controller kvm_intel snd_hda_codec kvm snd_hwdep snd_pcm drm_kms_helper snd_seq_midi snd_seq_midi_event snd_rawmidi drm snd_seq crct10dif_pclmul crc32_pclmul snd_seq_device mei_me snd_timer serio_raw snd cryptd mei shpchp soundcore wmi 8250_fintek i2c_algo_bit lpc_ich video tpm_infineon mac_hid parport_pc ppdev lp parport pata_acpi uas usb_storage ahci libahci r8169 mii pata_via[ 5507.670280] CPU: 1 PID: 3214 Comm: ubi_bgt0d Tainted: G OE 3.18.25-ubifs.ex0+ #3[ 5507.670328] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 08/20/2012[ 5507.670383] task: ffff8803f90b2360 ti: ffff8800c7820000 task.ti: ffff8800c7820000[ 5507.670427] RIP: 0010:[<ffffffff813bb3a8>] [<ffffffff813bb3a8>] rb_insert_color+0x18/0x170[ 5507.670484] RSP: 0018:ffff8800c7823d08 EFLAGS: 00010246[ 5507.670517] RAX: ffff8803f53588ff RBX: 0000000000000000 RCX: ffff8803f5359520[ 5507.670560] RDX: 0000000000000000 RSI: ffff8800c841b530 RDI: ffff8803f5358870[ 5507.670603] RBP: ffff8800c7823d08 R08: ffff8803f5359518 R09: 0000000000000000[ 5507.670646] R10: 0000000000000001 R11: 0000000000000026 R12: ffff8803f5358907[ 5507.670690] R13: ffff8803f5358870 R14: ffff8800c841b530 R15: ffff8803f90b2360[ 5507.670736] FS: 0000000000000000(0000) GS:ffff88041f280000(0000) knlGS:0000000000000000[ 5507.670786] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 5507.670822] CR2: 0000000000000008 CR3: 00000000c8456000 CR4: 00000000000407e0[ 5507.670867] Stack:[ 5507.670882] ffff8800c7823d48 ffffffffa0692a83 ffff8800c7823d48 ffff8800c841a148[ 5507.670937] ffff8803f5358870 ffff8803f5359519 ffff8800c841b530 000000000000001a[ 5507.670989] ffff8800c7823dc8 ffffffffa06939eb 00000000c7823dc8 ffff8800c841b618[ 5507.671043] Call Trace:[ 5507.671069] [<ffffffffa0692a83>] wl_tree_add+0xa3/0xf0 [ubi][ 5507.671103] [<ffffffffa06939eb>] erase_worker+0x3fb/0x8a0 [ubi][ 5507.671128] [<ffffffffa0692cd7>] do_work+0xa7/0x120 [ubi][ 5507.671151] [<ffffffffa0695b30>] ubi_thread+0x140/0x220 [ubi][ 5507.671174] [<ffffffffa06959f0>] ? ubi_wl_flush+0x1f0/0x1f0 [ubi][ 5507.671198] [<ffffffff810933d3>] kthread+0xf3/0x110[ 5507.671218] [<ffffffff817c36f0>] ? _raw_spin_unlock_irq+0x30/0x50[ 5507.671242] [<ffffffff810932e0>] ? kthread_create_on_node+0x240/0x240[ 5507.671266] [<ffffffff817c43d8>] ret_from_fork+0x58/0x90[ 5507.671286] [<ffffffff810932e0>] ? kthread_create_on_node+0x240/0x240[ 5507.671309] Code: 89 d0 48 83 e0 fc 75 eb 5d c3 31 c0 5d c3 0f 1f 44 00 00 55 48 8b 07 48 89 e5 48 85 c0 0f 84 21 01 00 00 48 8b 10 f6 c2 01 75 62 <48> 8b 4a 08 49 89 d0 48 39 c8 0f 84 93 00 00 00 48 85 c9 74 05 [ 5507.671484] RIP [<ffffffff813bb3a8>] rb_insert_color+0x18/0x170[ 5507.671510] RSP <ffff8800c7823d08>[ 5507.671524] CR2: 0000000000000008[ 5507.677032] ---[ end trace ac0635da470d30eb ]---詳細情報のリンク: kernel log (Linux version 3.18.25-ubifs.ex0+ (furuta@catbox) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) ) #3 SMP Mon Feb 22 10:04:14 JST 2016, 改造した nandsim のエラーも有る。意図したエラーだ。要解消だろう), ps 出力(rm /mnt/ubifsex/home/furuta/c/c/ccdcd0dd92eac432f5a3d22348ae6cf0 で停止),cpuinfo 出力(i3-2120T), wear leveling のバランスにも疑問が有るほとんど書き換わらない erase block が約 28.6% を占める。ファイルシステム(ボリューム)全容量の 50%~60% 程に使用量を抑えて読み書きした結果だ。ファイルシステムテストツールのスナップショット(branch on-mtd-ubifs) 簡単な使い方は次の通り。ただし、ほかの環境で動かすことは全く考えていないので、エラーになる。% cd ubifsex% sudo ./scripts/install-package.sh # ubuntu 14.04 に追加するパッケージ% make # バイナリ作成% sudo snippet/modprobe/modprobe-mtd.sh # ほかの環境ではスクリプト内の nandsim_prof を nandsim に要修正% cd fstest-ddrm-00 # テストスクリプトディレクトリ移動% ./test-ubifs-u40t8r71g.sh # テストパラメータを指定してテスト開始テストツールにも問題が見つかっている(firo: First In, Random Out でエラーが発生する)。テストツール、ubifs とも信頼が出来ない状態だ。仕事で見つけても「見なかったことに」だったかもしれない。時間はいっぱいあるのだ。問題を解決していこう。2016.10.30 以下追記UBI/UBIFS 負荷試験 - undef CONFIG_MTD_UBI_FASTMAP にて動作安定drivers/mtd/nand/nandsim.c の cache_file がまともに動作しない - get_pages(), put_pages() が怪しい?
2016.02.22
コメント(0)
会社に居たときにファイルシステムテストツールを書いた。退職時に持ち出しができない。こっそりと持ち出しはせず、書き直していた。ようやく、テスト実行できるところまで実装が進んだ。テストコード、動作確認用の落書きも含めて次のような分量になった。おおよそ 5900 行、そんなに多かったかな?% wc `find . -name '*.c' -o -name '*.h' -o -name 'Makefile' -o -name '*.sh'` 19 62 454 ./snippet/doubleformat/doubleformat.c 5 4 33 ./snippet/readline-test/readline-test.sh 123 335 2450 ./snippet/openfifo/openfifo.c 27 53 428 ./snippet/fstest-ddrm-00/testBuildPath.sh 41 103 764 ./snippet/modprobe/modprove-mtd.sh 35 68 444 ./Makefile 459 1354 10046 ./firo/randomout.c 22 52 442 ./firo/Makefile 770 2348 19185 ./firo/firo.c 47 106 1092 ./firo/randomout.h 8 19 135 ./mtrandom/Makefile 215 940 7278 ./mtrandom/mt19937ar.c 94 439 3434 ./mtrandom/mt19937ar.h 157 435 3316 ./test00/test00.sh 68 170 1666 ./snapshot.sh 7 16 106 ./readline/Makefile 62 150 1518 ./readline/readline.h 530 1654 12224 ./readline/readline.c 18 35 294 ./ddmtrand/Makefile 1119 3488 28422 ./ddmtrand/ddmtrand.c 997 3413 28117 ./fstest-ddrm-00/fstest-ddrm-00.sh 134 429 3047 ./test02/test02.sh 21 41 391 ./pseudorand/Makefile 705 2147 16528 ./pseudorand/pseudorand.c 232 574 4372 ./test01/test01.sh 5915 18435 146186 totalアルゴリズムを書き直しをしたので分量は増えている。2~3 倍くらい?これだけ書いても、ランダムにディレクトリツリー構造とファイルを作る。適当につまみ取りして読み出し検査。ボリュームが溢れそうになったら先の検査で合格したファイルを消すだけだ。書き直しをせず、そっくり思い出して同じ物を作れただろうか?
2016.02.19
コメント(0)
Linux に NAND memory をシミュレートする nandsim ドライバが有る。これを改造してもう少し詳しい情報を取ろうと改造中だ。block erase count(これは既存、ブロック毎にカウント取得を追加), page program count, page read count を取得できるように改造、加えて追記ルールチェックも加えようとしている(既存で実装されている。しかし、デバイスメーカーが指定するルールチェックはしていない)うーん、動かないデバドラはのめり込むねぇ。
2016.01.20
コメント(0)
ひょんなことから退職前の開発現場で使っていたターゲット書き込みツールをネットの検索で見つけた。詳しく書くと色々と触ってはいけない情報もあるので差し控えておく。情報を知っているならば "ツールをまとめた圧縮ファイル名から、バージョン名を取り除いた文字列" と "デバイス名" の組み合わせでググってみると見つかる。見つかった先でダウンロード出来ないものもある。2, 3 巡ればダウンロード可のサイトも見つかる。展開してバイナリを見とみると、確かに "デバイス名" が入っていた。驚くのは "デバイス名" が見つかったことだ。開発時に「門外不出、使用者限定」だと言われたツールだった。非公開だと思っていた。公開されているチップと共通ツールだったとしても、ビルド時は外れているものだと思っていた。人伝えに聞いた契約内容に思い当たる節はある。暗号化キー、ストラップピンなどで壁が有るはずだけれど...そんなのあったかなぁ。検索結果を詳細に調べてみると、2, 3 年前からデバイスのファミリーが増えるたびに、どこからかリリースされている。うーん、漏れまくりだったのか。安いデバイスなりに緩いなぁ。ターゲットは手元にない。実動するかは分からない。
2016.01.14
コメント(0)
I-O DATA mAagic TV GT (GV-MVP/XZ3) の動作がかなり遅くなってしまった。録画失敗も頻発するようになっていた。録画を 50 本くらい消してみた。全く動作が速くならない。それどころか、mAgic TV Guide が固まったまま 10 分以上が経過した。何か変わってしまったのか?リソースモニタで動作の様子を探った。ディスクの項目を開くと MsMpEng.exe が mAgic TV の録画ファイル XIT を大量に読み込み続けていた。MsMpEng.exe は Microsoft Security Essentials (MSE) だ。MSE の設定画面を開いて(スタート→プログラム→Microsoft Security Essentials または 直接 C:\Program Files\Microsoft Security Client\msseces.exe を起動) 、除外設定をすることにした。セキュリティは弱くなる。■ 設定タブ - 除外されたファイルと場所「参照」 ボタンを押して "録画ファイル保存場所" と "番組データ保存場所" を探して 「追加」 ボタンを押す。標準的なインストールならば次の場所になる。終わったら 「変更の保存」 を押す。C:\Users\ユーザー名\AppData\Roaming\I-O DATA\mAgicTVC:\mAgicTVD\Record■ 設定タブ - 除外されたファイルの種類「ファイル拡張子」の欄に拡張子を入れて 「追加」 ボタンを押す作業を何回か繰り返す。終わったら 「変更の保存」 を押す。追加する拡張子は次の通りだ。たとえば DGNO だったら、「ファイル拡張子」欄に DGNO と入力し、「追加」ボタンを押す。DGNOXITXURXCNXSK※ XUR は古い mAgic TV の録画ファイル拡張子です。おそらくここまですればかなり軽くなるはずだ。プロセスの監視を除外すればより軽くなる。■ 設定タブ - 除外されたプロセス「参照」 ボタンを押していくつかの "mAgic TV の実行ファイル" を探して 「追加」 ボタンを押す操作を繰り返す。標準的なインストールならば実行ファイルの一覧は次の様になる。効果が有りそうな順にしてある。終わったら 「変更の保存」 を押す。C:\Program Files\I-O DATA\mAgicTVGT\mtvManager.exeC:\Program Files\I-O DATA\mAgicTVGT\mtvGuide.exeC:\Program Files\I-O DATA\mAgicTVGT\mtvPlayer.exeC:\Program Files\I-O DATA\mAgicTVGT\mtvUpdate.exeC:\Program Files\I-O DATA\mAgicTVGT\mtvMaintainer.exeC:\Program Files\I-O DATA\mAgicTVGT\mtvdsv.exeC:\Program Files\I-O DATA\mAgicTVGT\mmcFileServer.exeC:\Program Files\I-O DATA\mAgicTVGT\mtvBDDubbing.exeC:\Program Files\I-O DATA\mAgicTVGT\mtvDubbing.exeえ?なんでこんな設定をするのかって? んー、まぁテレビを見るようになったかな。
2016.01.07
コメント(0)
退職前に自分の荷物を少しづつ引き揚げた。既に自分の机からテスターも消えた。ただキーボードを叩くだけのプログラマの姿に戻っている。テスターで電圧を測り、USB オシロで波形をみて、疑似的な接続機器群で動作確認して、ひたすら治具で接続切断を繰り返す。そんなことを机の上のガラクタを使って 1 ヵ月前までしていたのだ。開発機材を動かしても、動いたと言う手応えが殆ど無くなった。リセットボタンを押して動き出し、しばらくするとシリアルコンソールにプロンプトが出るだけ。ああ、こんな感じ方をするんだ。ほぼ身の回りにいるソフト開発者が感じる組み込み開発というものは。他人の感じ方にプローブを当てることはできない。単に今、自分の体験を他人の体験と射影で結びつけようとしているだけなのか。手応えとは何だったのだろうか?ガラクタたちがメーターの針で、7 セグメントの LED や液晶パネルで、動きを示す。カチカチと繰り返すリレーの音に合わせてログが出力される。そんなことだったのか。いくらレジスタの値を変えた所で、外観的な変化は一切なし。動いていなくても、動いていても、どうでも良くなってしまうのか。
2015.12.25
コメント(0)
scankeylx の新版 r1512a をリリースした。前回のリリースより 3 年 4 ヵ月が過ぎてしまった。Windows はこの間 8, 8.1, 10 とバージョンが 3 つ進んだ。思えば、問題プロジェクトを始めてしまったのだ。プロジェクト開始時点で有った課題は次の通りだった。実行環境が KNOPPIX だった。産総研 のメンテナンスが滞りがちになり次のプラットホームを探す必要があった。Windows 8 のプレビュー版に対してキー検索を掛けてもキーをデコードできない問題が有った。新しいデコードアルゴリズムを導入する必要がある。kylix は発売終了から多くの年月が過ぎていた。新しい環境にインストールするのに無理があった。開発環境は仮想マシン内にだけとなってしまった。新しい pascal 処理系を探す必要があった。ソースコードのコメントが S-JIS の日本語だった。多くの linux が UTF-8 に移行して、漢字コードの表示に問題が出始めていた。2 次, 3 次利用を考慮してライセンスを分かり易いものにする必要が出てきた。出力結果整理アルゴリズムが弱く、冗長な結果を削減できていなかった。これらの問題を一気に解決すべく... と思った時点で困難プロジェクトだった。加えて仕事が重く個人的な活動ができる時間が殆ど無い状態が続いた。問題が多い、時間が無い、重い仕事のため保守の記憶を維持できない。まずぶつかった問題は、kylix ソースコードと lazarus/free pascal コードの多重メンテナンスだった。3 年 4 ヵ月前のリリース時点で既に lazarus/free pascal へ移行を始めていた。問題対応をするも、お互いのコードを簡単に merge できない。kylix と lazarus は似て非なる処理系だ。時間が無かったことも重い課題だった。半年以上コードを弄れない期間が続いた事も有った。記憶は殆ど消えてしまい、何を修正していたのか忘れてしまうことが度々あった。その度にソースの半分程度を 1 行 1 行 自己レビューした。さらに進まない。コメントを英語で書きなおし続けた。問題点が見つかる度に、黙々とコメントを修正すべきなのか、書き直したコメントが後に捨てられるのなら、新アルゴリズム実装と新スレッド構造実装をしてしまった方が良いのではないか。作業が揺れた。コメントを修正して新アルゴリズムとスレッド構造を実装する事になった。コードは仮死状態となり、2 年くらいは動かないコードを相手に書きなおしとコード注ぎ込みを続けることになってしまった。やる気を維持するのは非常に困難な状況に陥ってしまった。コードの仮死状態が続いたせいで、実装を終ったと思う段階が何処なのか、自分でも分からなくなっていた。単体テストコードを 2000 行くらい注ぎ込んだだろうか。部分で完成させることにした。Windows 8 以降に対応したデコードアルゴリズムをネットで見つけた。レビューしてみるとアルゴリズムが冗長でどうもおかしい。何か「コピペコードに対する引っ掛け」の様な意図が有る様に思えた。デコードアルゴリズムはネットで出ていたコードは参考に冗長性を排除し書き直し、検算も行った。今年の 5 月頃ようやく動き出した。ubuntu 環境の問題にぶつかる。ubuntu は 10.04, 12.04, 14.04 其々で操作が違う。違いに合わせて手順書を分岐させる必要があった。ubuntu が確実に動作しない問題もあった。"try ubuntu" でデスクトップ画面にならず login 画面になってしまう(metacity window manager をインストールする必要があった)。画面が出なくなってしまう(boot parameter を修正する)。LTS のマイナーリリースごとに問題が無くなるのではなく、増えることも有った。何も考えずに最新 15.04 版からバック・ポートして問題が感染してしまっている。動作検証を殆どしていないと思えた。VIA C3, C7 を動作対象としない決断を下すのも 1 ヵ月以上掛った。ubuntu 10.04 で動くはずなのに謎の完全フリーズ、kernel の生きている部分に触れることすらできない。踏ん切りがついたのは VIA C3 環境が壊れたことだ。テストランできなくなった。では、問題を段階的に片づければ良かったのだろうか? 最後にそうする事にした。最新の lazarus/free pascal ではコンパイルできない。後回しにした課題だ。
2015.12.20
コメント(0)
リリースのお知らせなのでいつもの日記と違う文面で書きます。前回のリリースから 3 年 4 ヵ月が過ぎました。Windows プロダクトキー検索ツール scankeylx の新バージョン r1512aをリリースしました。新バージョンは前回リリースに比べて次の様に変わりました。実行環境が ubuntu の live mode になりました。検索対象を windows 10 迄としました。ソースコードを lazarus/free pascal に対応する様に書き直しました。ソースコードのコメント・メッセージを全て英語に直しました。ソースコードライセンスを二条項 BSD ライセンスとしました。大きく変わった所が多く、問題や操作性の違いなど、ご不便を強いてしまうことも有るかと思いますがよろしくお願いします。
2015.12.20
コメント(0)
全884件 (884件中 151-200件目)