ふるた技工所(てっこうしょ)

全4821件 (4821件中 101-150件目)

< 1 2 3 4 5 6 7 8 ... 97 >

• 

  近所で梨狩り始まる - カラスさんは既に来ている

  近所で梨狩りが始まった。画像は 8/2 日曜日に撮った。最近カラスが騒がしいのは梨が実り始めたからか。持ち帰りの梨も出始めた。梨狩りは 3 密だろうか？ 常に屋外だ。息はすぐに風で遠くへ流れる。太陽光下なので紫外線で殺菌される。あまり接触はしない。あー、子供を肩車するとかはあるかな。適当に離れて行動できる。もぎ取った梨や出荷規格外の梨を食べるテーブルサービスも有ったっけ。テーブルを拭くとか、皮むきの包丁を洗うとかかな。普通に今までもしている。大抵の梨園のテーブルは屋外か、屋内でも吹きっさらしだ。換気は十分。梨園は天候に左右されやすく、どちらかと言えば地味な観光だった。今年はお客さん来るのかな。

  2020.08.03

  コメント(0)

• 

  風呂釜が壊れた ノーリツ GTS-163A - エラー 252 「ふろ循環系統の故障または異常」

  いつもの様に風呂を沸かし始める。そろそろ沸くかなと思った頃に、いつもと違うアラーム音が鳴りだした。普通に動いているときは 3 回くらいピー、ピー、ピー、となってお風呂が沸く。長く鳴り続けていた。ん？何かあった？操作パネルをみたら、時計表示部分と運転 LED が点滅を繰り返していた。時計部分の時刻がずれている？と不思議に思った。エラーコード？ 風呂釜の形式ノーリツ GTS-163A で取得したマニュアルを読んでみると、エラーコード 252 「ふろ循環系統の故障または異常」だった。自動湯張りが停止した。湯船の温度は少しぬるめ、運転ボタンを押し直す。エラー解除された。追い炊きを押す。5 分くらいして同様にエラーとなった。湯張り量はいつもと変わらず。放置すれば湯温は下がる。すぐに少しぬるめの湯船につかる。湯面が上がれば解消？　再度追い炊きを試す。再度エラーになった。循環ポンプが動き、追い炊き吐き出し口から出る水流がある。温度は上がっていない。ガスバーナーが点火していない。外からガスの臭いはしないので、追い炊きバーナーに繋がるガス弁が開いていないのだろう。失火や着火失敗ではないと思われる。そうであれば、シャワーを使ったときに風呂釜が「ボン」と音を立てて、小さな爆発を起こすだろう。GTS-163A 動作状況機能状況風呂給湯動くシャワー動く追い炊きエラー 252自動 湯張り湯張りまで動作保温はエラー 252 で停止少し温度高めで湯張りすれば、湯船に浸かれそうかな... 昔は当たり前だった湯張り一回勝負だ。なんだな、部屋を買ったとき、風呂釜は「動かない機器」(あるいは動作保証がない設備)として取引すると不動産屋から説明があった。2003 年製なので 17 年稼働、既に性能維持のための保守部品は無いはずだ。部屋を買って 2 年半くらいで壊れたか... あと 3 年くらいは動くつもりだった。浴室リフォーム展示会に行ったのは 1 年半前、見積は取らずだったので、壊れるフラグを立てた積もりはなかったのに。

  2020.08.03

  コメント(0)

• 

  M2A-VM HDMI 膨張コンデンサ交換 - 条件が違う 6 個

  PCI スロットに SCSI ボードを差し込む積もりで、M2A-VM HDMI マザーボードの PC を開ける。コンデンサが膨れているのが見えた。1 箇所だけかな... 混んだ場所で作業していたので、全体が見えず。懐中電灯を当てて見て 2, 3 箇所を確認した。SCSI ボード差し込むのは無理か、マザーボードをケースから外すことにした。同じ 6.3V 820uF のコンデンサが 6 個膨らんでいる。上の画像の様に、電圧系統を調べたのは後のことだ。調べる前は「え？同じ電圧系統が全滅？」と思い電源ユニット Enhance ATX-0250GA (500W PFC) を開けて確認する。ヒートシンク下に 2 次側コンデンサが並び、角度を変えながら見回す。膨らみがあるコンデンサは見当たらない。日本ケミコン KZG 6.3V 820uF ばかりなぜ膨らむのだろう。膨らんでいないのもある。電圧系統を調べてみる。5V, 5VSB, 5VSB を上流とするアナログレギュレータ下流, Vterm (DRAM bus 終端電圧), 5V はなぜか USB ポート周りが膨らむ。5VSB も殆ど使った実績がない USB ポート周りだ。6 個のコンデンサの使用条件が違うことが分かった。修理後発熱状況を触診で診てみると、隣接しているレギュレータで炙られているコンデンサと、リプルが大きいと思われるコンデンサが有りそうだ。シルク印刷と極性の関係に要注意だ。白く塗られている方が正極、塗られていない方が負極だ。メーカー毎にシルク印刷とコンデンサ極の対応は違う。周りのコンデンサも含めて、対応を確認する。コンデンサを 6.3V 1000uF OS-CON に変えることした。系統が違うのと、5V, 5VSB は負荷される容量が変わることがあり得ること、Vterm を含むアナログ電源系は、隣接するレギュレータが熱く、負荷電流が多そうだ。容量が増えても、まぁ、大丈夫かな... と見込む。コンデンサは小型なので PCI スロットよりも頭が低い。拡張カードも当たらない。マザーボードを外す時点で、「新しいマザーボードに入れ替えるか...」と何となく思っていた。出費が痛いのは分かりつつも、2, 3 ヶ月前からネットで新しいマザーボードと CPU を物色し始めていた。うん、新しい物を探すと壊れる法則が発動した。修理を終えて、M2A-VM HDMI が元いた PC ケースには別のマザーボードが入っていた。段ボール箱の上に座らせ、8Gibyte の主記憶にネットワーク・ブートした Linux を乗せて動作確認、20 分ほど動かして、交換したコンデンサに異常なし。段ボール箱に入れて仕舞う。Phenom II X4 945, 8Gibyte、命令セットが足らず Android Emulator は動かなくなり、ビルドも少し難儀する。

  2020.08.02

  コメント(0)

• 

  Ainex RS-007 USB2.0 リアスロット Type-C 2 ポート 道理で廃番になるわけだ - Rp 56kΩ が付いていない

  Ainex RS-007 USB2.0 リアスロット Type-C 2 ポートを買う。USB Type-C ポートを増設するのが目的だ。調べてみると USB Type-C ポートとして機能しない回路になっていた。CC1, CC2 に Rp 56kΩが付いていない。「出荷終了品」になった理由だろう。千石電商から通販で届いたときに、パッケージがくたびれていて汚れていた。妙な感じがした。誰も手を付けないのはなぜ？ぱっと見の仕様からして変だ。PC マザーボードの USB 2.0 端子は 2 ポート出ている。これを 1 ポートにしてしまう。製品全体で 4 ポートを Type-C 2 ポートにしてしまう。もったいないな... と思っていた。詳細を調べる前にポートが減る理由を考えてみる。Type-C コネクタは DP, DM 信号が A, B 両列にある。スタブにならない様に Port 1 - A 列, Port 2 - B 列になる様にしたのかな... 最もらしい理由が本当なのか基板を良く見てみよう... 注: この考えは間違いPlug 内で DP, DM の A, B 列がまた接続されている。 3.3.1 Cable Construction (informative) USB Type-C Cable and Connector Specification Release 2.0。基板を良く見てみる。あれ？ Rp 抵抗器が無い様な。Rp 抵抗器は VBUS に電力を供給する側だと示す VBUS - {CC1, CC2} 信号端子間に入る Pull UP 抵抗器だ。単純に抵抗器で構成した場合、ポートは Host Role 固定になる(4.11.1 Termination Parameters など)。秋葉原の千石電商で店ざらしになっていたのは、「良く訓練された人」が手に取って Rp 抵抗が無いことを見て、買わなかったのだろう。半分剥がれかけのシールが汚れているのは、開けて念入りに確認したのか。通販は難度高いな。どうなっているのだ？ CC1, CC2 信号を VBUS へショートするのは乱暴すぎる。接続相手が壊れるかも。オープンでは VBUS 供給能力無し (Device Role に認識されるか、そもそも接続不成立) になってしまうし。VBUS - CCx 間 Rp 抵抗値 と VBUS 電流供給能力 (VBUS=5V)Rp 抵抗値 [Ω]VBUS 供給電流 [mA]56k50022k150010k3000回路を調べてみる。CC1, CC2 とも open だった。なるほど、販売終了になるわけだ。RS-007 PDF 回路図 1 channel 分次の様に CC1, CC2 を 56kΩ で pull up すれば良いはず。図に描くのは簡単だ。RS-007 (修正案) PDF 回路図 1 channel 分Type-C Receptacle の端子に半田付けか... 細かすぎる。鉛筆で塗る？この blog で出ていた RS-007 回路図一式 bsch v3 形式と PDF

  2020.07.31

  コメント(0)

• 

  地震来るのかなぁ - 緊急地震速報で一斉停止したみたい

  さて、色々と取りかかるかな。と言った頃合い 9:39 に緊急地震速報が防災無線放送から流れてきた。曇った空の元、不気味に響き渡る。放送長いな。隣接市の放送も聞こえ始めた。え！これから部屋の中がかき乱されたように物が倒れて散乱するの？身構えて 3 分くらいしても揺れは感じず。どうしたんだろう... 何処か別の場所で？ 玄関の扉を開けて、テレビを点ける程度の時間的余裕が有った。商用電源監視記録を見てみると、機械類が一斉に停止したと思われる周波数上昇が 9:39 に見られた。やはり 3 分くらいして、皆テレビを点けたのだろうか？ 9:42 に周波数低下のピークが出た。緩く周波数が上がっていくのは、「本当に来ないの？」と身構え続けたか、福島県郡山市の爆発事故が気になったのか、長くテレビを点けていた？19 時少し過ぎ、北の空を部屋から見る。冷たい北風が部屋に入ってきて、体が冷やされる。ん？北の空が橙色の目を細めてこちらを見ている。お天道様、まだ何かするの？

  2020.07.30

  コメント(0)

• 中国企業のアプリなど「利用制限の法整備を」- たまには政治ネタ、ソフトウエアの現実を分かって検討しているのかな

  ニュースサイトを見ていたら、何処かの党が『中国企業のアプリなど「利用制限の法整備を」』と何やら法整備を検討していた。なんだろうなぁ。議員さん達、日本のソフトウエア開発の現状を理解していないな。今時、アプリどころか OS の kernel 部分まで殆ど中国が絡んでいるのに。安い中国製スマホなら、普通の人でも直ぐに思いつくだろう。現実はかなり多くの日本製(正確に言えば日本メーカーブランド)の家電製品に中国製のソフトウエアが絡んでいる。テレビ、録画・再生機器、WiFi/BT 使用機器、PC 周辺機器 HDD/SSD、少し見回して思いつく製品だ。これらの製品に使われているデバイスはチップセットの形で中国が設計して、それらを動かすソフトウエアも組みで提供されている。メーカーはリファレンスデザインを意匠デザイナーが設計した外形に合わせて、プリント基板に起こす。部品はそのまま載せ替えだ。ビジネス用語で言えば「ターンキービジネス」だ。信号線 1 本、つまり GPIO のポート番号、IRQ 割り込み番号、そんな細かいところまで同一だ。もし、1 本でも使用信号を変えたならば、中国で作られたソフトウエアに手を入れる必要がある。「簡単でしょ？」と思っている人が居るかも。現実は GPIO のポート番号、IRQ 割り込み番号を変えられる日本のエンジニアはそんなに居ない。仕事をしていた先で、人が足りないのだけど... 出来る人知っている？と聞かれたり、いわゆる人材派遣・客先常駐の開発事業者に声を掛けたのだけど、人が居なくて 2, 3 ヶ月間作業未着手と言ったことを何回も見てきた。チップセット外のデバイスを使ったならば、ほぼ絶望的に対応できる日本のエンジニアは居ない。中国のエンジニアに聞くしか無い。あー、洪水で開発拠点大丈夫かなぁ。退職・(会社役員を)退任した高齢者を何人か見てきて思うのは、彼らはネジ・グギと言った目で見て数えられる物は非常に鋭い洞察をするのに、ソフトウエアの様に目に見えないものは全く理解できていないことだった。目的を達成するまでの処理の組み立て、処理の難度・規模、お互いの関連性と言った事柄を見た・聞いた通りに、言い直すことも、書き直すことも難度が高かった。彼らは同じ物を繰り返し作る、誰かの真似で仕事が出来る。といった昭和の教育と日本の社会設計で生きてきた人たちなのだ。まだ政治は昭和のまま、技術まで昭和に彼らは戻したいの？

  2020.07.29

  コメント(0)

• 

  今時の秋月電子通販の注文から着荷までの時間 - 自分の注文の場合 2 日だった

  最近殆ど秋月電子の店に行っていない。雨続きなのと新型コロナウイルスが流行していて、行っても色々と制限があって楽しむのは難しそうだと思っている。通販を使う。お知らせには「新型コロナウイルスの影響で通販の注文が集中し、通常より2 ～ 3日程度発送作業に遅延が発生しています。」とある。待つのかなぁ。2020/7/26(日) 午前 1:45 頃に注文を実行する。日曜稼働だったとして 7/26(日) 午前に作業開始、通販センターのページをみると月曜稼働かもしれない。出荷通知 7/27(月) 19:35 → ヤマト運輸(北東京法人) 7/27(月) 19:53 → ヤマト運輸(流山ベース) 7/28(火) 3:23 → ヤマト運輸(地域拠点) 7/28(火) 6:40 頃配達開始 → 自宅 7/28(火) 10:30 頃着荷 となった。大型家電量販店の注文から着荷までの時間と比べてほぼ同じか早い。新型コロナウイルスの影響が無い商品で、途中の配送ルートにも影響が無く、大雨の影響が無かったのが幸いだったのかも。店にお客が戻った？注文殺到が一段落？経済活動低下？

  2020.07.28

  コメント(0)

• 

  手持ちの MO ドライブ 2 台とも不調・故障 - もうちょっと慎重に電源を入れれば良かったか

  ジャンクで買った MO ドライブで読めないメディアが有った。そもそも、手持ちの MO ドライブで読める積もりだった。MELCO MOS-640S を動かしてみる。ジャンクで買った MO ドライブより状態が良くない。エラー多発、最初からメディアを認識しない。何が悪いのだろう。ダメ元でレンズクリーニングをしても変わらず。悪化したかな。128Mbyte の MO メディアなら、一番最初に買った MO ドライブが使えるはず。TEAC OD-121S を動かす。SCSI, AC ケーブルを接続して電源ボタンを押す。ON! 「あっ」部屋の電灯が一瞬暗くなったのが分かった。POWER LED は点灯しない。もう一回押しても、POWER LED は点灯しない。2 回目の Power On は SCSI ケーブルを外すべきだった。「部屋の電灯が一瞬暗くなった」と言うことは AC ライン電圧低下が起きたのだ。大電流が流れたな。ドライブ内部のヒューズが切れただけで済んでいれば... 部品が焼けるような異臭は無い。カバーを開けて、何が起きたのか見てみる。見た目で激しく焼損した部品は見当たらない。ん？電源基板の抵抗器の足下が黒いな。読み取り出来る IC の DATE code のうち新しそうなのは 1992 年 14 週か。28 年前に動いていたドライブなのか。こんなに古いといきなり電源 ON は危険なのかも。具体的に用心して「電源 ON」はどうしたら良いのだろうか？ なにも繋がず独立した状態、なるべく燃える物が無いところ、ブレーカー付きタップなどで保護された内側から電源を取り、少ない電流でトリップして幹線・分岐線をトリップさせないようにする。電源基板を外すため、ネジを外す。錆びていた。電解コンデンサの液漏れだろう。基板の銅箔とランドがカビたように緑黒く錆びている。電解液と残ったフラックスが融合したの？部品に電解液が染みついている。広範囲だ。こうなると 2 次側は殆どショートなのだろうか？あるいは、コンデンサに充電できないので、目一杯 1 次側の電流を増やして、過電流なのだろうか？弄っていると手がベタつく。ふいても手に付いてくる。基板に染みこんでいるなぁ。ヒューズ管が黒く曇っている。内側に丸く粒状になった金属が線状に並んで付着している。ああ、大電流で消し飛んだのか。ヒューズの電流定格は 3A、恐らく Fast Blow タイプ。3A 定格のヒューズが 1 秒未満で切れたのだから、一瞬 10A 以上は流れたのかも。3A を僅かに上回る程度で切れたならば、ヒューズの細線は形が残り、真ん中だけ切れるか、うで始めたスパゲティの様にしなった状態で切れる。外から 5V, 12V を供給すれば動くのかな。それとも、手持ちのメディアを読み終え(読むのを諦め)、使う目的が無くなるのか。

  2020.07.28

  コメント(0)

• 

  ハードオフでジャンク 640MByte MO drive を買う - 家の中では一番良く動くドライブかな

  ハードオフでジャンク 640MByte MO drive OLYMPUS MO643U5 を買う、110 円でジャンク box に入っていた。そう言えば、手持ちの MO メディアは読めるのだろうか？一応、SCSI 接続のドライブは持っている。「予備になるかもしれない」機材が 110 円なら良いかな。足が取れているなぁ。後で代わりの足を貼り付けるか。ん？もしかして一度開けた？足が貼ってあった部分がシールになっている。綺麗に貼り戻したのかな？あっ、そうだ。MO メディアを見たことが無い人がいるかもなぁ。手持ちの 640Mbyte メディアを出しておこう。虹色に輝いている円盤を格納した四角いケースが MO メディアだ。この大きさで 640Mbyte を格納する。比較のため右上に 32Gbyte の Micro SD card を置いておいた。簡単に諸元を比較してみる。いずれも実測値、Micro SD の容量はメーカー品種によって違う。大きさは見ての通り、重さは比較していない。項目640M MO32G Micro SDSD / MO容量(bytes)635,600,89631,914,983,424約 50.21sequential read転送速度(Mbytes/sec)2.0192.1約 45.8テクノロジーの進化は驚異的だな。640Mbyte MO メディア 1 枚で 2,000 ～ 3,000 円くらいだったか。ドライブが 20,000 ～ 40,000 円くらいした。MO が普及していた頃に USB は無く、さらに SCSI Interface, cable, terminator も必要だった。SCSI 部分で 10,000 ～ 20,000 円くらいかな。今時 Micro SD card reader はメーカー製パソコンなら普通に付いているし、スマホに標準装備されている。無くても 100 円ショップで探せば 100 円で売っている。外観的な不具合は EJECT ボタンが引っ込んでいること、カラカラ音がすること(ネジが取れていた)、汚れがついていること。あー、AC アダプタで給電が必要か。調べてみると EIAJ 極性統一プラグ(RC5320A) 区分 2 で 5V 1.6A だ。適当な変換ケーブルを付けて供給しよう。ネジは 2 個の後ろ足の下にあるシールを剥がすと出てくる(自分が手にしたドライブは 1 個足が無い)。シール下からカラカラと音がしていた。ネジが外れた状態になったのは何でだろう。ポストが割れていた。これでネジが締まらなかったのか。反対側はポストの形が残っていた。良く見るとヒビが入っていて、手で軽く強度を確かめたら、崩れてしまった。丁寧にポスト再建？いずれパテとか使うのも慣れないとなぁ。ダサく養生テープで「仮止め」という恒久処置をして使うか。そのうちベタつくかカラカラに乾いて剥がれるかもしれない。ドライブに皮脂が付いているなぁ。やっぱり開けたのか。ハードオフ・ジャンクなのだ。普通にあること。ドライブは OLYMPUS MOS3393E で 2002 年 8 月製だと読める。製造から 17 年 11 ヶ月経過している。皮脂をパーツクリーナーで拭き取る。レーザー・ダイオードが劣化していることも考えられる。今後、書き込みで使う事は無いからレーザー強度は弱くなっていても平気かな。透明スモークパーツのポストの一部が割れて動く様になっていた。ボタンの支えも折れていた。スモーク・パーツとボタンの支えは接着剤で補強することにした。瞬間接着剤を使って見たけれど、ダメなんだよなぁ。盛れる接着剤の方が上手くいく。内部を補修して、養生テープでケースを留める。緑のアクセントがダサダサ・デザインだな。ダイソーで買った汎用の足も取り付けた。結局付けた足も余り役に立たない状況だったのが後で判る。手持ちにあった EIAJ 極性統一 DC プラグ区分 2 で電源供給ケーブルを作る。EIAJ 極性統一 DC プラグって RC5320A と言う規格名が付いているのか...電源 ON、Windows10 PC に接続する。アクセスランプが点いてディレクトリを読み込んだ。おお、Windows10 はまだ MO に対応しているのか。あれ？なんか変だな。MO メディアによって読める・読めないがある。読んだ内容も部分的に壊れている。なんか変な壊れ方だなぁ。MO メディアによってはドライブの挿入側を下にして読めるようになった。ハードオフ・ジャンク、この程度は中難度だ。データの壊れ方が... ECC による訂正限界を超えたのか。手持ちのドライブも動かしてみる。さらに問題が悪化した。機会が有れば別の日記に書くか。ディスク表面はホコリで汚れているし、拭き取ると砂埃でキズが付いてしまった。俗な環境と使い方だと 25 年持たないのか。

  2020.07.26

  コメント(0)

• 

  つかの間、スズメが池で水浴びするほどに雨が止む - 昼過ぎからまた雨

  つかの間、スズメが池で水浴びするほどに雨が止む。空も明るくなり始めていた。洗濯物は外で干せるかな。既に部屋干しを始めていた。ほぼ外気温と同じ程度の 28 ℃で冷房して湿度を下げつつ、扇風機で風を当てて乾かす。スズメさん、散々雨が当たっていて水浴び状態だと思っていたのに。少し濁った水溜まりで水浴びするのが好みなのか。外で干せるかな... と思いつつ洗濯物は移し替えず、サボっていた。昼過ぎくらいに雨が強く降り出す。外で干せないなぁ。

  2020.07.25

  コメント(0)

• 

  キリギリス(ササキリの仲間)を見つける - 8 月くらい見られる虫？

  近くでキリギリス(ササキリの仲間)を見つける。尻尾のさやが長いのでよく目立っていた。体長は触角を除き鞘を入れて 5 ～ 6cm ほど、触角も 5cm は伸びている。この大きさでキリギリスなんだ。大きいので調べる前はバッタかと思っていた。頭の部分が尖っていなく、どちらかというと丸まっているというか、絶壁スタイルなのでキリギリスの仲間だそうだ。ん？群生相には変化していないよな。緑色だし普通かなぁ。

  2020.07.21

  コメント(0)

• 

  OMRON D2FC-3M に CR を付けてみてチャタリングを押さえ込む実験 - 簡単ではなさそう

  ELECOM Mouse M-XGL10DB の OMRON D2FC-3M に抵抗とコンデンサを付けてチャタリングを押さえ込めないか試してみることにした。D2FC-3M を検索すると通販が見つかる。なぜだろう、手を出しづらい。手持ちの部品でなんとかしてみよう。スイッチに並列してスパークキラー回路を付加する。抵抗とコンデンサを直列して構成した単純な回路だ。下の回路図で Mods と付けた囲みの中に入っている Rsk, Csk 部分に当たる。抵抗は 100Ω, コンデンサは 0.1uF なので、GPIO の Rup (Pull Up) 抵抗と合わせて約 15kΩ と考えると、時定数は 15kΩ x 0.1uF = 1.5ms だ。スイッチを押した瞬間の電流は Vdd ≈ 3.0V なので 3.0V / 100Ω = 30mA になり、スイッチの定格内に収まる。なんだな、色々と計算したところで、手持ち部品がいっぱいある 100Ω, 0.1uF を選ぶのは既定路線だった。付加回路無しで先に測っていた次の波形の様なチャタリングを十分に押さえ込めると考えていた。スイッチを押して離してみる。ん？付加回路無しだったときはパルス的な Off だったはず。1.38ms 程スイッチがチャタリングで Off になることが何回も発生している。かなり様子が違う。付加回路無しだとチャタリングで Off する時間は短い。接点に掛かる電圧が 3.0V 程でも接点間が放電して電流が流れるのか。付加回路のコンデンサでほぼ 0V に端子間電圧を維持すると、直ぐに消弧して接点間電流が途絶えるのだろうか？離し操作の部分も同じような変化だ。約 (3.0V * 0.6) = 1.8V に上昇するまでの時間は約 1.45ms なので、時定数はだいたい合っている。何回か 押し - 離し を試してみると、チャタリングで Off になる時間は 3.6ms になる場合も見られた。うーん、かえってクリックの反応を悪くするかも。2020.07.22 追記ELECOM M-XGL10DB 分解クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている D2FC-3M のチャタリングの様子を見てみる

  2020.07.20

  コメント(0)

• 

  クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている D2FC-3M のチャタリングの様子を見てみる - チャタリング除去アルゴリズムの限界を超えている？

  クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている OMRON D2FC-3M がチャタリングを起こしているのか、波形を見ることにした。接点は機械なので、チャタリングは新品でもある。クリックをしたという状況判定に影響が出る程度のチャタリングかどうかだ。マウスの操作にダブルクリックがある。恐らく、2 回のクリックとして分離するかどうか、判断できない On/Off の繰り返し継続があると、反応が悪くなると考えられる。左ボタン周辺の回路を追ってみる。次の様な回路になっていると思われる。nRF24LE1E データシートと読み合わせて、不自然なところは無い。右ボタンも同様だと思われる。PDF の回路図、bschv3 ソースnRF24LE1E GPIO 端子に D2FC-3M の Normally Off 側を接続した回路だ。nRF24LE1E の pull-up 抵抗を On にして、マウスボタンを押していないときは High Level、マウスボタンを押したときは Low Level になる回路だ。pull-up 抵抗の線形性は良い。MOS FET のチャネル On 抵抗に良く見られる定電流特性は見られなかった。14.97kΩ の抵抗で pull-up されていると見なせる。スイッチの NO - Common 間 (GPIO 端子 - GND 間) の波形をスイッチのレバーを押して、離す操作をして観測する。操作毎に波形が違ってくる。何回か波形を撮ってみて、典型的な変化を取り上げる。左ボタン側の波形と右ボタン側の波形の全体を見てみる。左ボタン側右ボタン側左ボタン側の方にチャタリングが多く見られる。特徴的なのはスイッチを押した直後のチャタリングに加えて、約 5.4m ～ 15.3ms の範囲に後続するチャタリング、離したときに 12.3ms ほどチャタリングが継続した後、一端小さなチャタリングを含みつつ、押した状態(On 状態)で落ち着き、32.8ms 後に完全に離した状態(Off 状態)に遷移する。Off 状態に遷移する直前にもチャタリングが見られる。全体的に「押し」はダブルクリックと判別しにくく、「離し」は逆ダブルクリックあるいは、反応遅れになっている。クリック感覚が良くないと感じた状況をある程度説明できている。「押し」の状況はマウスの Firm ware に実装されたアルゴリズムが解れば理解できるのかも。チャタリングを起こしている状態は複雑だ。接点なので On と Off しか無いはずと思っていた。拡大してみると電気的には何かのインピーダンス素子で繋いだ様な状態になってる。ほぼ抵抗的だとは思う。パルス的に Off になる。波形の変化から、放電が一瞬止まる現象なのか？スイッチ周辺の回路で波形の様子は大きく変わる。別の日記でこのチャタリングを付加回路で押さえようとしたときの波形も触れようと思う。スイッチの変化を Both Edge (Interrupt On Change) で受ける場合、注意深いアルゴズム実装が必要そうだ。教科書的なアルゴリズムは N を定めて N 回同じ入力なら、安定したと見なすという素朴なアルゴリズムだ。それで上手くいく？ マウスの場合、ダブルクリック入力も考慮する必要がある。良好な状態の右ボタンの「離し」部分も、チャタリングが含まれていた。機械的な「離し」からどれだけ遅れての変化なのかは見えていない。スイッチ(接点)は奥深い部品だと思う。2020.07.22 追記ELECOM M-XGL10DB 分解OMRON D2FC-3M に CR を付けてみてチャタリングを押さえ込む実験

  2020.07.19

  コメント(0)

• 

  ELECOM M-XGL10DB 分解 - マウスクリック反応が悪くなる

  使っていた ELECOM M-XGL10DB マウスの左ボタンのクリック反応が悪くなってしまった。次の様な症状かある。クリックしても反応しない離したタイミングが遅れるチャタリングかなぁ。購入記録は 2019/3/30 だった。いわゆるエルゴノミクスマウスだ。うーん、もう少しだけ大きめが良かったかな(買ったのは L サイズ)。親指に力が入ってしまう。手のひらがマウスの丘からずり落ちそうになり、小指が机上についてしまう、ついつい親指の付け根に力が入ってしまう。買って 1.25 年で不調になった。早いのか？遅いのか？ 分解してみて使われているスイッチが OMRON D2FC-3M だと分かる。D2FC-3M のデータシートは見つからず。近そうな D2FC-F-7Nのデータシートを読んでみると電気的・機械的に不具合が出ること無く 5,000,000 回の開閉ができると書いてある。使用状況を計算してみる。5 秒に 1 回クリック、1 日 16 時間使用、年中無休、使用期間 1.25 年(3600 * 16 / 5) * 365 * 1.25 = 5,256,000なるほど、不具合が出てもおかしくない使用状況なのか。ネジは足のシールに全て隠されている。Y ネジあるいは、ベンツネジ、個人的にはヤッターネジ(ヤッターマンってもうオジサンしか分からないよね)が使われている。カバーを開ける。ゴミが入っていた。使用状況そのままを記録しておく。基板と電池ホルダー、上部ボタン基板の間はコネクタを介して接続されている。組み立て、分解はしやすい。メイン基板は小さく作られている。モーションセンサーに遮光をするためと思われる不織布テープが貼られていた。ケースが青く光るのを避けたか、あるいは何か干渉する不具合があったのか？ マウス前方に点灯したことが無い LED がついているのと関係あるのかな？左右ボタンのスイッチに OMRON D2FC-3M が使われていた。D2FC シリーズの派生品だと思われる。マウスメーカー向け専用品らしく、データーシートは納品仕様書のコピーらしいものが見つかる。ワイヤレストランシーバーは 24AT01、丁度一致する型番は見つからなかった。機能、パッケージ、モーションセンサ PAW3212DB の応用回路例からNORDIC nRF24LE1Eかその互換品だと推測する。トランシーバーの基準クロックは 16MHz 水晶を使っていた。モーションセンサーを隠しているテープを剥がして、センサーの型番を見てみる。PAW3212DB だった。光った所を見たことが無い LED が 2 つ前方についている。何かのゲーミングマウスと共通基板になっているのだろうか？ここからの光漏れを防ぐためにセンサーに遮光テープが貼られている？基板の型名は EL017MR VG かな。M-XG や EX-G といった型名やシリーズ名と一致しない。基板裏面、かなり分かりやすく信号名がシルク印刷されている。スイッチの配線にテストランドが設けられている。接触痕は見当たらない。製造時テストはしていないか、開発時のテスト用だと思われる。うーん、洗浄は省略なのかなぁ。側面親指スイッチの基板を見ると、スイッチが 3 個乗る設計だ。天井に 1 個？一時期ホイールの手前側にスイッチを付けるマウスが流行っていたような... 中ボタンだったっけ？スイッチは HUANO 製、押したことが殆ど無いので耐久性、感覚は分からず。側面親指スイッチ基板裏をみると、天井用スイッチの配線もされている。修理？値段を調べてみると 1,351 円だった。買い直しかな。2020.07.22 追記クリック反応が悪くなった ELECOM Mouse M-XGL10DB に使われている D2FC-3M のチャタリングの様子を見てみるOMRON D2FC-3M に CR を付けてみてチャタリングを押さえ込む実験

  2020.07.19

  コメント(0)

• 

  SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う

  SMR HDD WD60EZAZ を買った直後に近い状態にするには、trim (Linux の command line で blkdiscard) を使う。あるいは mount option に discard を付ける。具体的には blkdiscard command を次の様にして使うと、HDD の全領域が trim される。# blkdiscard -v -p 16MiB /dev/sdXblkdiscard は ubuntu 16.04 以降で使える。util-linux package に入っているので、標準的なインストール構成なら使える状態になっているはず。-v は進捗表示をする指定、-p オプションで指定している値は trim (SCSI なら unmap) command 1 回につき、何 byte 分を実施するかと言う値だ。16MiB は 16Mibyte 刻みで trim を発行する指定になる。理想は SMR HDD の allocation unit の整数倍にするのが良いと考えられる。外部からは分からないので、1Mibyte ～ 32Mibyte 程度の間で良いと思う。小さくしても、許容できる実行時間で済むと思われる。blkdiscard 実行例: 対象 /dev/sdc WD60EZAZ, -p 16MiB, 実行時間約 214 秒(経過出力 1 行で 1 秒)/dev/sdX は trim しようとする HDD のノードだ。よく調べて指定して欲しい。WD60EZAZ の場合、trim すると block から読み出したデータは 0x00 の連続となる。実質的に消去になる。firm ware に直接 command を送って(送る手段があったとして) trim を取り消すなどの操作をしないと、データは復活しない。普段使いならば、mount option に次の様に discard を指定するのが良いだろう。/etc/fstab にも同様に記述できる。# mount -o discard /dev/sdXI /mount/pointlinux kernel 5.4.47 で file system が discard に対応しているか簡単に検索してみると btrfs, ext4, f2fs, fat(exfat), gfs2, jfs, nilfs2, xfs が対応している。主要な file system は入っている。種類が少ないので惜しいと思う人もいるかも。SMR HDD WD60EZAZ の trim command (discard あるいは unmap) の挙動は興味深い。色々と試した結果を書いていく。HDD の状態は前の日記でテストをした後の状態だ。ramdom read/write - sequential read x 1 - sequential {write and read} x 2 をした後だ。各操作の途中ディスク容量に対して 2 ～ 3% 程度のお試し read/write をしている。この状態で trim (blkdiscard) を全領域に対して、分割無しに実行してみた。blkdiscard command に device の node を指定するだけだ。# blkdiscard -v /dev/sdc/dev/sdc: Discarded 6001175126016 bytes from the offset 05 秒も経たないうちに blkdicard は終了する。ちゃんと trim しているの？多分 HDD の firm ware が back ground で処理しているのだろう。ほぼ 3 時間待って、sequential read の転送速度を測ってみた。グラフの縦軸は転送速度、横軸は進捗 0%: LBA=0, 100%: LBA=Last LBA だ。あれ？外周部分、分割構造境界だけ trim されている。trim された場所は平均で 400Mbytes/sec 出ている。3 時間放置ている。frim ware が動作時間の 100% を使って trim 処理を実行していたら、平均転送速度 150Mbytes/sec として、 150Mbytes/sec x (3600 x 3sec) = 1,620,000 Mbytes の範囲、割合に換算して 27% は trim された状態になっていると期待していた。綺麗に 0x00 で wipe するまでもなく、allocation unit に trim された範囲を追記するなら、もっと早いはず。当面の書き込み需要に応じるなら、trim する範囲は 10% 未満で十分というのも分かる。何だかなぁ。転送速度プロットの様にモヤモヤする。(2回目) 同じ blkdiscard command を実行して、6 時間ほど放置する。sequential read の転送速度を測る。16 ～ 17% くらいが trim された様だ。重ねて blkdiscard を実行すると、前の trim が取り消しになるのか、それとも 3 時間で 8% が back ground で trim されるのか。(3 回目) 同じ blkdiscard command を実行して、12.5 時間ほど放置する。sequential read の転送速度を測る。24 ～ 25% くらいが trim された様だ。一括の trim (blkdiscard) では直ぐに trim されないことは確かだ。転送速度が 400Mbytes/sec 出ていないところを狙って dd で読んでみると書き込んだデータが読める。そこを狙って trim するとデータは 0x00 になり dd の転送速度は上がった。blkdiscard 範囲を分割する指定 -p を付けて実行してみる。次に示す command line の太字部分のような指定だ。指定する値をいくつか試してみた。実行終了までに時間が掛かる。手応えがある。次の例のように 512Kibytes 分割だと見込みで約 4500 秒かかる。途中 ctrl-c で停止した。# blkdiscard -v -o $(( 0 )) \ -l $(( 6001175126016 )) -p $(( 512 * 1024 )) /dev/sdc-p に 512Mibyte を指定すると、23 秒で終了する。HDD の中で何か変化していると期待できる。全領域で sequential read の転送速度は 400Mbytes/sec 前後出る様になった。転送速度のブレが大きく、買ったばかりと違っている。trim command の動作は allocation unit に trim 範囲を追記するだけのようだ。read/write command に対して allocation unit を通しで読んでみて trim された記録が見つかったら、範囲を記憶し、trim 済みか判断する。次の read/write command に対して、trim された領域なのか、いくつか記憶した trim 範囲と照合してみて最適な動作を決める様だ。trim された後の sequential write の転送速度を測ってみる。CMR HDD に近い転送速度の傾向を示した。最外周で 200Mbytes/sec、最内周で 80Mbytes/sec 出ている。分割構造の特徴は見えにくくなっている。相変わらず中央の分割の後半で転送速度 130Mbytes/sec で底打ちする。謎なままだ。WD60EZAZ は都度細かく trim する使い方で性能が出る見込みがある。OS の file system に trim 指定を(Linux ならば discard 指定を)するか、自動で trim を積極的に使う環境ならば、CMR HDD に少し劣る程度の性能で使えるかもしれない。(注: ここで行った random read/write のテストは trim を使っていない)より具体的には大規模ソースの build 作業で生成される object file の様に create - write - read - remove の繰り返しならば、障害を引き起こしそうなアクセス速度の低下や応答時間の長期化は経験せずに済むと思われる。それでも CMR HDD とほぼ同等は無理そう。trim をせずに defrag したり、record file / data base の様にファイルの一部を read/write する使い方を続けたり、trim に対応しない RAID 構成で使うと、障害になるほどのアクセス速度の低下や応答時間の長期化が発生する可能性も分かった。SMR HDD WD60EZAZ の性質が分かってきた。この HDD を買った目的は何だっけ？ えーっと、バックアップ作業用に買ったはず。うん、バックアップを数分で消す blkdiscard の魔法を覚えた！SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果SMR HDD random read/write アクセス後の sequential read/write 速度

  2020.07.18

  コメント(0)

• 

  SMR HDD random read/write アクセス後の sequential read/write 速度 - 遅くなるなぁ

  まず買ったばかりの SMR HDD WD60EZAZ の sequential read 速度を見てみる。縦軸は転送速度 bytes/sec, 横軸は 進捗で 0% が LBA=0, 100% が LBA=Last LBA だ。380Mbytes/sec 出ている。データシート上の最大転送速度は 180Mbytes/sec だ。実用上この速度は出ない。Trim された領域を read して出ている速度だ。File System を構成するならば、書き込んだことが無い領域を読むことは無い。読んだとしてクラスタ単位で操作する都合上で行われるはずだ。380Mbytes/sec は記憶媒体に律速されない AHCI SATA I/F - WD60EZAZ 間の最大転送速度を示していると考えられる。Trim されているので何回 sequential read を繰り返してもほぼ同じ結果になると考えていた。繰り返してみると、転送速度に僅かな変動が見られたり、瞬間的に(全容量に対して 2 ～ 3% 程度の範囲で)突如として転送速度が低下する現象がみられた。なぜ起きるのか良く分かっていない。買ったばかりなのに媒体上に不安定な領域でもあるのだろうか？あるいは、HDD の firm ware に使われているアルゴリズムが動作履歴に左右されやすい時間オーダーになっているのだろうか？先に行った random read/writeに続けて、sequential read/write をする。1 回目の sequential read は転送速度が進捗に対して 3 段階で変化した。各段階で最大転送速度と最小転送速度の差が大きい。比較的早い外周領域(0% ～ 33.3%)の範囲でも 90Mbytes/sec 差が有り、ほぼ 2 倍の振れ幅がある。振れ幅も密度に差が有り、allocation unit に沿うように転送速度が低下している様に見える。段階の位置を見るとほぼ進捗の 33.3%, 66.6% の所で段ができている。いかにも意図的な位置だ。大規模な分割構造がある様に見える。LBA で綺麗に 3 分割されているということは、媒体上では外周では細い環、内周では太い環に分割されているのだろうか？ さらに細かく分割して最適化を追求するよりは動作検証をしやすくした様に見える。1 回目のsequential write の転送速度(リンク先は続く sequential read を含む)を見てみる。「これは HDD なのか？」転送速度が波打つ様に変化した。分割構造の境界付近では最高転送速度は 200Mbytes/sec を越える。それ以外では IDE I/F 時代の HDD 程度の速度になった。外周部分で 30M ～ 70M bytes/sec だ。ULTRA ATA 33 ～ 100 が全盛で容量 20Gbyte ～ 100Gbyte の HDD がよく使われた時代に戻った感じだ。転送速度の変化も分割構造の前後で非対称だ。ヘッドを静定する時間がシーク方向に依存しているか、HDD 媒体上の allocation unit に未使用追記領域が無かった場合の空き検索アルゴリズムに方向性があるのか？特定条件を満たしたときにデーターシートスペック 180Mbyte/sec を出しているようにも見える。何が何でもスペックを出すような構造を設計した？分割構造の境界付近を「SMR 追記を早く行うための余剰領域」かつ「不良ブロックが発生した場合に代替利用する領域」にしているのだろうか？転送速度が速くなる進捗の幅が 3%, 5%, 5%, 3% となるので、何か意図的な割り振りを感じる。おおよそ HDD に書き込んだデータのうち、15 ～ 20% 位が書き換えられると想定して、追記未使用領域を用意しているのだろうか？あるいは運用中に不良ブロックが発生したとして、最大 20% 程の代替領域があれば、運用継続可能と想定している？そうだとすると SMR 方式は物理的な記録密度向上に対して、性能と耐不良ブロックのために払う代償も大きい。コスト競争が激しい製品で、差し引き 3 割り増しにもなれば大きいのも確かだ。全領域を Sequential write すればスッキリするのだろうか？ sequential read 転送速度が向上し、CMR 方式 HDD と同等と見なせる程度に転送速度のブレは減るのだろうか？2 回目の sequential read をしてみる。転送速度は全般的に向上した。分割構造の外周部で、205Mbytes/sec が出る様になった。転送速度のブレは依然として大きい。最外周の分割部分で転送速度の振れ幅は 70Mbytes/sec 程度、速度低下の機会はある程度減ったように見える。中央、内周分割部分でも転送速度は 10M ～ 20Mbytes/sec 向上している。気持ち速度低下頻度が下がったように見える。HDD 内の allocation unit をほぼカバーするような sequential write を行った積もりだった。write() システムコールに対して転送長 256Mibyte、Linux Kernel の BIO から AHCI driver 間の最大転送長は 30720kiByte (30Mibyte) にしている。HDD 上の allocation unit を綺麗に上書きで書き直せると期待していた。sequential read 転送速度の結果を見ると、依然として allocation unit に対して追記、溢れた場合は隣接 allocation unit に対する追記に振り替えている様に見える。2 回目の sequential write をしてみる。転送速度が波打つ様なことは無くなった。最外周の分割構造で、upper 205M ～ 200Mbytes/sec, lower 160M ～ 155Mbytes/sec の転送速度が出ている。ある程度 block 配置状態が整理された様に見える。依然として、転送速度に振れ幅がある。 奇妙なことに真ん中の分割構造で、転送速度の下限が 130Mbytes/sec 程に安定して底打ちする現象が見られた。原因は分からず。勘ぐった見方をすると転送速度調整をしている様に見える。外周側の分割構造でも、転送速度の変化が進捗に対して 5Mbytes/sec になっている。HDD に乗ったチップ内の DMA controller 速度を媒体記録密度とは別の調整パターンで設定している？マーケティング / ブランディングと言った大人の事情？3 回目の sequential read をしてみる。2 回目と比べて大きな変化は無い。分割構造の境界付近で転送速度が妙に遅くなったり、早くなるようなパターンは依然として残る。媒体上の場所毎に使い方が違うことを示唆している。WD60EZAZ は Trim command を受け付ける。何か変化があるから command として受け付けるのだろう。試してみるか。2020.7.15 22:50 追記: 手順の流れを明確化した。2020.7.18 追記: SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う

  2020.07.15

  コメント(0)

• ヒグラシが鳴く - 19 時には静かになっていた

  18 時過ぎヒグラシが鳴いているのが聞こえてきた。雨が降り、久しぶりに冷たく感じる風がふく夕方だった。雲が厚く、景色は早めに暗くなる。夕食の準備をしていたので、ゆっくりと耳を傾けなかった。食べ終わって 19 時、まだ鳴いているかな？と思い窓辺へ、もう鳴いていなかった。暑い夏は間もなくなのだろうか？

  2020.07.13

  コメント(0)

• go to キャンペーンではなく do too (一緒に対策しよう)キャンペーン？ - できることも考えないと

  ネットの書き込みを見たら、go to キャンペーンを誤記しているのを見つける。そうか、do too (一緒に対策しよう)か。それにしては機運が盛り上がらない。もっとスマートな衛生対策、生活様式、社会活動のあり方があるはず。大抵のことは世の中の片隅で細々と行われていたりする。探すと見つかるものだ。おかしいな、たしか 10 兆円くらいのよく分からない予備費を補正予算で成立させた様な... もう使っちゃったとか。

  2020.07.12

  コメント(0)

• 再び籠城体勢に - まだ店が静かなうちに行動しておく

  新型コロナウイルスの感染が拡大している。数で見れば今まで以上に状況は悪化している。買い込み物資を点検して不足分を買い足すことにした。店の棚の状況を見るに、多くの人に慌てた様子は無さそうだ。先行して行動できる間はあと 3 日 ～ 1 週間くらいか。

  2020.07.10

  コメント(0)

• 

  少しの晴れ間に買い物へ - 夕焼け空を見て帰る

  夕方くらいに雨模様の空が少し晴れそうだった。午後 17 時に家を出る。買い物で店を回っていたら、19 時を過ぎてしまった。久しぶりに見る夕焼けか。サーモンピンクに染まっている。隣に見える矢切線からはジリジリとコロナ放電の音が聞こえてくる。水分が多い雲と空なのだろう。秋雨の晴れ間とも感じる空だ。夏至を過ぎている。夕方に行動できる時間も段々と短くなるのか。

  2020.07.08

  コメント(0)

• アブラゼミが鳴き始める - 今年は早いのかな

  16 時頃、雨は一時的に止み、南風の強風が吹き続ける。どこからかアブラゼミの鳴き声が聞こえてきた。風に吹き飛ばされて、揺れるように聞こえる。梅雨の真っ最中、まだ出てくるには早かったか。17 時、また小雨が降り出した。蝉の声聞こえなくなっちゃったな。

  2020.07.07

  コメント(0)

• 

  マイナポイント混乱するかもなぁ - 残念、みどすけ君は 9 月から

  親に「マイナポイントを登録したいのだけと」と相談された。親のところには IC カードリーダーが無い。マイナポイントのサイトを見てみると、コンビニとかスーパーにあるキヨスク端末でできそうだけどなぁ...カードリーダーを持って行って、作業を手伝おう... 練習がてら自分の所で試してみる。あれ？ SMBC デビットカードを登録できない。マイナポイントサイトには出ているしなぁ。決済サービス選択で見つけることができない。キーワード無指定で決済サービス区分を全選択しても、サービス一覧に出てこない。もう一つページを潜ってみて、SMBC デビットカードの説明をよく読んでみる。あっ、「申込開始日 2020年9月1日から」と書いてあった。3/4 ほどスクロールするとやっと出てくる表に書いてある。まだ登録できないのね。隠すことでも無しと思う。んー、でもなんだな。URL を良く見ると... "MP0000166" これって、登録に使うコードでは？「登録サービス番号」にも MP0000166 と書いてあるしなぁ。登録キャッシュレス決済サービスページにある表には 三井住友カード株式会社 三井住友カード / ＳＭＢＣデビット の行に "決済事業者番号 M0038" と書いてあって、紛らわしい。残念、ページを印刷してマイキーIDを控えておくか... あれ？紙に印刷されない。PDF に出力しても印刷されない。スクリーンショットか、手で書き写すしかないのかなぁ。再ログインで マイキー ID を入力する場面はなかった。マイキーID は何に使う？IC カードリーダーを持って、親のところに行ってみる。majica を登録したいらしい。やっぱり登録できない。マジか...コンビニかスーパーに行かせてたら... たぶん端末の前で 1 時間くらいは立ち往生だった...

  2020.07.04

  コメント(0)

• 

  大きなクワガタムシを見つける - 一回り小さいカブトムシくらいの大きさ

  久しぶりに買い物に出る。怪我をしてから、外出はゴミ捨てなどごく近隣に限っていた。大きなクワガタムシを見つける。多分クワガタムシ、かなり大きい。一回り小さい雌のカブトムシ？と思うくらいな大きさだ。口の形からクワガタかな？温暖化の影響で昆虫も大型化して、夏の早いうちから飛び回るようになるのだろうか？

  2020.07.03

  コメント(0)

• x86/x86-64 arch で cache flush 関数を試しに実装してみる - kernel の実装を持ってくる

  Linux の Userland で cache flush をしたくなったので、x86/x86-64 アーキテクチャ上で cache flush 関数を実装してみる。Linux kernel 内に有った実装をほぼそのまま持ってくる。#include <stdint.h>static void clflush(volatile void *p){  asm volatile("clflush %0" : "+m"(*(volatile uint8_t *)p));}clflush ソースkernel から持ってきた理由は、検索をしていたらcacheflush() system call が見つかったからだ。kernel source を調べてみると x86/x86-64 アーキテクチャではこの system call は無い様に見える。特権を持っていなくても、CLFLUSH 命令は使えるからだろう。試しに使ってみるコードを実装する。#include <stdint.h>#include <stdio.h>#include <string.h>static void clflush(volatile void *p){  asm volatile("clflush %0" : "+m"(*(volatile uint8_t *)p));}const char hello[] = "Hello world.\n";void MainB(char *buf){  memcpy(buf, hello, sizeof(hello));  clflush(buf);  fputs(buf, stdout);}int main(int argc, char **argv, char **env){ char buf[128];  MainB(buf);  return 0;}clflush テストコード全体逆アセンブルしてみる。まぁ、まぁ、綺麗に inline でオブジェクトコードが生成されていた。0000000000400620 <MainB>:  400620: 48 b8 48 65 6c 6c 6f movabs $0x6f77206f6c6c6548,%rax  400627: 20 77 6f   40062a: c7 47 08 72 6c 64 2e movl   $0x2e646c72,0x8(%rdi)  400631: 48 89 07             mov    %rax,(%rdi)  400634: b8 0a 00 00 00       mov    $0xa,%eax  400639: 66 89 47 0c          mov    %ax,0xc(%rdi)  40063d: 0f ae 3f             clflush (%rdi)  400640: 48 8b 35 09 0a 20 00 mov    0x200a09(%rip),%rsi        # 601050 <stdout@@GLIBC_2.2.5>  400647: e9 74 fe ff ff       jmpq   4004c0 <fputs@plt>  40064c: 0f 1f 40 00          nopl   0x0(%rax)より良い使い方は、前後にmemory barrierを使う。cache line size も /proc/cpuinfo から拾わないと。clflush size    : 64cache_alignment : 64

  2020.07.02

  コメント(0)

• 

  SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果 - Android, Linux Kernel, yocto ソースコードを格納して build するのは向かないかも

  SMR 記録の HDD WD60EZAZ を Linux で使うには BIO (Block IO request) のタイムアウト設定 /sys/block/block_device_name/queue/io_timeout に 240000 (240秒) を設定すれば sync() でハングせずに使えそうなことが分かってきた。設定値は kernel が管理する cache 量、稼働中に想定される単位時間当たりの書き込み量、頻度に依存すると思われる。主記憶サイズ 24Gibyte での値だ。ランダムアクセステストの結果に気になる傾向があったので、記録に残しておく。ランダムアクセスの分布は LBA: [0..MaxLBA] = a*random(), Length: [4096..512Mibytes] = exp(l * random()) bytes となる様に a, l を定めている。read, write はほぼ半々になる様に混在させている。ランダムアクセステストをする前に行った HDD アクセス履歴の概要を書く。最後の全 block 連続書き込みから、次の表の様にランダムアクセスをした状態だ。6Tbyte に対して、221266 回 write のランダムアクセスをしている。テスト前のランダムアクセス数Read / Write回数Read220113Write221266テスト後のランダムアクセス数Read / Write回数Read269244Write270439均等に分散しているアクセスだと仮定すると 6Tbyte / 221266 ≒ ‭27,121,994 (27Mbyte) 程度の範囲に 1 箇所はランダムアクセスをして乱れがあるはずだ。厳密にはアクセス長分布は 512Mibyte まで有るので、27Mbyte 丸々上書きされている場合もある。意外と疎な感もある。OS の Cache を使わずに Read/Write Random Access をした結果から、Read のアクセス時間と転送長の関係をプロットしたグラフを見てみる。最小 Read Turn Around Time は約 8ms だった。Seek time + Rotation 待ち時間として考えられる。気になるのは、アクセス時間の分布がいくつかの帯に分かれることだ。構造を示すような資料は見つからなかったので推測で書く。HDD の記録面は4Mbyte 程の CMR Allocation Unit10M ～ 30M byte 程度の単位で管理された Small SMR Allocation Unit200M ～ 300Mbyte 程度の単位で管理された Large SMR Allocation Unit (Small SMR Allocation Unit をまとめたか、あるいはさらに高密度記録を行っている)といった階層的な構造になっている様に見える。シーケンシャルアクセステストの結果から、ドライブ全体を 3 分割する構造も見えている。SMR HDD らしい所は転送長が 1Mbyte 未満の所で、Access Time が 8ms ～ 300ms 程度の幅があることだ。最小アクセス時間と最大アクセス時間の比は 37.5 倍になる。細かいアクセスが多発する場合、総アクセス時間の予測をしにくい。Small SMR Allocation Unit も Large SMR Allocation Unit も追記を行っていく構造になっていると思われる。2020.06.29 加筆 書き込みをした場合、LBA, (新しい書き込みだと印を付ける)SerialNumber, block data を組みで追記し、プラッタ上の LBA の並びは追記順になっている様に見える。SMR 記録された track を読んでいって、読みたい LBA の最新が見つかるまで、シーケンシャルにアクセスしていると推測する。Write のアクセス時間と転送長の関係をプロットしたグラフを見てみる。条件は先ほどの Read 同様 OS の Cache は使わない。最小 Write Turn Around Time は 140us 程になっている。10Mbyte 程の書き込みまで多くの場合 転送速度は 400Mbyte/sec だ。SATA-III I/F の転送速度 6Gbps の上限に近い。プラッタに書き込まず、HDD 基板上の半導体メモリに格納したら、転送完了している様に見える。もし、電源断になったらどうするのだろう？プラッタとスピンドルモーターでフライホイールを構成して、Flash Memory か特別な磁気媒体領域に書き込み終わるまで、電源供給無しに動作し続けるのだろうか？実効的な HDD の cache size は 10Mbyte 程に見える。WD Blue Data Sheetには 256Mbyte と表記されているので 10Mbyte x n tansaction の様に使っているか、Small/Large SMR Allocation Unit の再構築に使っている可能性がある。転送長に対して顕著にアクセス時間が長い場合が見られる。アクセス時間からして Small/Large SMR Allocation Unit を再構築しているのでは？と考えられる。追記ができなくなった場合、近隣の Allocation Unit に追記するか、それも出来なくなった場合は、再構築をするのだろう。このグラフからは読み取りにくい。HDD を休ませることなく連続してランダムアクセステストを実施していると、次の様なグラフに変化する。分布がより鮮明に現れ、転送長が 512Mibyte の場合のアクセス時間は 7 ～ 10 秒だったのが、45 秒程に変化する。連続してランダムアクセステストを実施していると、read もアクセス時間が変化する。転送長が 1Mbyte 以下で 8ms でアクセス完了する場合が減る。Small SMR allocation Unit から読んでいると思われる 300ms 程のアクセス時間になる。転送長が 1Mbyte 以上の場合も、Large SMR Allocation Unit を 2 つ跨ぐ様なアクセス時間に変化している。対数グラフで一マス上なので体感的に速度は 1/5 ～ 1/10 程度に下がってしまった様に感じるかも。OS の cache を使った場合のアクセス時間と転送長の関係を見ていく、Read の方は、Queue に溜まった transaction が完了するまで待つ場合が出てくる。待つ場合は 100Mbyte/sec 出ている転送速度が 3Mbyte/sec 程度まで低下した様に見える。最大で 30 ～ 40 秒待つ場合が出てきている。アプリケーションによってはフリーズしたような体感になる。連続アクセスを続けていると、待ち時間はさらに長くなる。200 秒ほどの待ちになる。先行する write transaction が完了するまでの待ちだと考えられる。これが、冒頭で触れた「タイムアウト設定 /sys/block/block_device_name/queue/io_timeout を 240000」にしようと考えた背景だ。OS の cache を使った場合の write は、順調に OS の cache に格納して完了している。転送速度が 2Gbytes/sec と 3Gbytes/sec に別れる原因は探っていない。OS の cache 管理構造が原因なのか、主記憶が 24Gibyte なので Memory Bus の channel 構成が非対称なのが原因なのか。ランダムアクセスですっかり遅くなってしまった SMR HDD WD60EZAZ のアクセス速度を回復する方法は有るのだろうか？2020.7.16 追記: SMR HDD random read/write アクセス後の sequential read/write 速度2020.7.18 追記: SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う2020.7.18 追記: Android, Linux Kernel の様な大規模ソースを格納して build 作業に使う場合、mount option discard (trim) を付ければ hang up に近いような応答時間にならずに済むかもしれないことが分かった。それでも、ランダムアクセスは性能的に不利だ。積極的には build 作業に使わない方が良さそう。

  2020.06.28

  コメント(2)

• SMR の HDD を Linux で使うと sync() で hang するかも - Waiting in uninterruptible disk sleep

  SMR 記録方式の HDD WD WD60EZAZ を linux (Lubuntu 20.04)でベンチマークテストしている。ベンチマークプログラムが kill -9 (SIGKILL) も効かない状態でハングする。ランダムアクセステストで kernel の cache は有効な状態、ベンチマークプログラムは root 権限で動作している。raw block device をアクセスするためだ。ps uaxwwでハングアップしている状態を見てみる。STAT が DL+ となった。"Waiting in uninterruptible disk sleep" (割り込み不可の状態でディスク I/O 完了待ち)だ。$ ps uaxww | grep ssdstress &34176 0.0 6.4 1576728 1574484 pts/1 DL+ 613 1:30 ./ssdstress -f 6001175126016 -pn -xb -rn -my -b 4096 -i 1 -a 131072 -i exp -n 24576 -u 65536 -dn -dY -s 20200614 /dev/sdcroot 権限でプログラムを動かしたとしても、uninterruptible 状態が長時間続く様な動作を kernel がすることはまずあり得ない。Linux Kernel で uninterruptible あるいはその逆の interruptible というのは誤解を招きやすい表現の一つだ。この場面において、純粋に「割り込み (interrupt) を受け付けない」という意味ではなく、Userland process が呼び出した「system call 処理中に signal を受け付けない」状態ということだ。どんな signal も受け付けない。signal 9 (SIGKILL) も含まれる。/proc/pid directory 内にあるいくつかの process status を見てみる。stat と status も D stateで止まっていることを示していた。/proc/34176 # cat stat34176 (ssdstress) D 34175 31200 31057 34817 31200 4194560 393297 0 1 0 6180 2875 0 0 20 0 1 0 23546681 1614569472 393621 18446744073709551615 94412556185600 94412556207685 140733693111200 0 0 0 0 0 0 1 0 0 17 3 0 0 3976146 0 0 94412556225760 94412556226828 94412566093824 140733693114159 140733693114281 140733693114281 140733693116396 0/proc/34176 # cat statusName:ssdstressUmask:0022State:D (disk sleep)Tgid:34176Ngid:0Pid:34176PPid:34175TracerPid:0Uid:0000Gid:0000FDSize:64Groups:0 -- snip --ps コマンドで得た情報は確かだ。ベンチマークプログラムはどこまで進んでいたのだろうか。ログ出力が途切れていたので、活動状況を類推できる fd/* file descriptor 使用状態(open している状態)を見てみる。/proc/34176/fd # ls -latotal 0dr-x------ 2 root root 0 6 13 15:46 .dr-xr-xr-x 9 root root 0 6 13 15:46 ..lrwx------ 1 root root 64 6 13 15:46 0 -> /dev/pts/1l-wx------ 1 root root 64 6 13 15:46 1 -> 'pipe:[233565]'l-wx------ 1 root root 64 6 13 15:46 2 -> 'pipe:[233565]'stdin, stdout, stderr だけだった。ほぼプログラムは終了している状態と考えられる。ん？ stack ってなんだ。system call を発行してから kenel 内でどこまで進んでいるか見ることができる call stackだった。/proc/34176 # cat stactk[<0>] submit_bio_wait+0x60/0x90[<0>] blkdev_issue_flush+0x94/0xd0[<0>] ext4_sync_fs+0x15d/0x200[<0>] sync_fs_one_sb+0x23/0x30[<0>] iterate_supers+0xa3/0x100[<0>] ksys_sync+0x62/0xb0[<0>] __ia32_sys_sync+0xe/0x20[<0>] do_syscall_64+0x57/0x190[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9各 kernel 関数のリンク先は Lubuntu 20.04 で使っている 5.4.0-37 に近い5.4.47 のソースにリンクしている。sync() を起点として submit_bio_wait で止まっている。「まぁ、そうだろう」と思う状況だ。真に止まっている場所は submit_bio_wait 内から呼び出した wait_for_completion_io か少し進んだ先のはず。ここで、TASK_UNINTERRUPTIBLE 状態で止まるように wait_for_common_io を呼び出している。signal を受け付けない訳だ。厄介だ。call stack の流れは、ext4_sync_fs を経由している。ハングアップの真の原因を作ったと推測している raw block device access と違う。raw block device access と ext4 file system を格納しているドライブに対する access が何処かで queue なり fifo を共用している？ 同じ SATA controller に繋がっているのだ。システム全体が停止してしまう可能性を示唆している。この現象が出た後、reboot できない。途中で途切れてしまったベンチマークテストの結果を見てみると、kenel cache を経由したアクセスで、完了まで 100 秒以上経過している場合がある。63 回だ。出始めの SSD に良く見られたプチフリーズとよく似ている。より悪い挙動かもしれない。Linux kernel 5.x から/sys/block/block_device_name/queue/io_timeout と言う ms (ミリ秒) 単位でタイムアウトを設定できるノード(リンク先は kernel 内の store 実装)が増えたようだ。各 Controller 毎にバラバラに実装されていた timeout を統一的に扱うノードなのだろうか？ SSD や SMR HDD といった癖があるデバイスが増え、実装する機運が高まったのかも。一方で各 Controller 毎にあった複雑な事情を吸収しきれず、complete しないゾンビののような BIO request (Block IO request) が生じやすい？io_timeout ノードの設定を変えて SMR HDD を使えるようにできるだろうか？ なんだな、筋が悪い予感がする。以前プチフリ SSD を Linux で使うのを断念している。よく似た状況だ。

  2020.06.23

  コメント(0)

• 喉が渇く、体がじんわりと痛い、作業が続かない - 怪我の症状かな

  怪我の症状だろうか？喉が渇く、外傷・内出血がないところもじんわりと痛むところがある。作業が続かない。大人しくしているか、体を横にしていた。一番大きな傷は横 3 cm, 縦 2cm 程の楕円形の形だ。リンパ液が浸出して、固まらない状態になった。長くなりそうだ。

  2020.06.21

  コメント(0)

• 

  感染したのかな - 自電車で転び怪我

  自転車走行中に転ぶ。怪我をしてしまった。画像が苦手な方がいたら申し訳ない。傷口から感染したのかな。

  2020.06.20

  コメント(0)

• しばらく日記をサボっていたわけ - プログラミングスキルチェックサイトに没頭していた

  ここしばらく、日記がサボりがちになっている。プログラミングスキルチェックサイト(Paiza)に没頭していた。100 点は目指さない。「好きにプログラムを作ってみよう」。という姿勢だ。もう少し「好き」を具体的に書くと、問題文ある入力範囲の制限はできるだけ取り除くあまり面倒でなければ Secure coding をしてみる入力エラー、内部ロジックエラー、メモリ不足など不意な状況もなるべく検出する時には over kill のアルゴリズムを投入してみる。そして、逆もあり素朴でのんびりと動くアルゴリズムで臨むこともするちゃんと動くことを目標にする。時間が掛かってもよいから、テスト入力は 100% 期待値と一致させる「たまには bash で...」と思ったら、まだちゃんと動いていないみたいいくつかの問題で統計された正解率が極端に低い問題が有った。なんでだろう。試しに解いてみることにした。おおよそ次の傾向があることが分かってきた。そもそも問題文に誤りがある入力に可変要素がある(特にテキスト入力の列方向)ステートマシンの様に内部記憶をもち、それを順次変化させる必要があるマシンイプシロンなど環境に依存性があり、作ったコードが題意を満たすかどうか証明するのに時間がかかる(マシンイプシロンは DBL_EPSILON などで取得可能だ。厳密にいえば環境依存なので、調査する必要があるし、値をなるべく真値に近く扱える実装が必要だ)全部言及すると長くなる。何かネタが無い時の機会に回そう。「そもそも問題文に誤り」は出題側は気付かないのだろうか？正解率は低く回答時間が長い。他の問題の傾向と比べて突出してる。しばらくして、「何かおかしい」と気付くはずだ。表に出す前(本番環境稼働させる前)に、レビュー、テストを十分にするのが教科書に書かれていることだ。誤りもそれほど難しい論理証明をせずとも発見できるものだった。どうやって問題作ったのかな。何も考えずにどこかのサイトのコピペ？ コピペ技術者で十分というのはちょっと悲しいな。

  2020.06.20

  コメント(0)

• dmesg (kernel long) に予兆が出ていたのか - スイッチングハブが壊れた

  スイッチングハブが壊れた時に「あれ？ネットワーク」とふと思っていた。他に仮定できるいくつかの原因が有ったはず。故障した HUB に接続しているlinux PC の dmesgを見直してみたら、故障の兆候が記録されていた。[511464.633473] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx[511465.026759] r8169 0000:05:00.0 enp5s0: Link is Down[511467.505506] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx[511467.891947] r8169 0000:05:00.0 enp5s0: Link is Down[511484.046647] r8169 0000:05:00.0 enp5s0: Link is Up - 100Mbps/Full - flow control rx/tx[511484.614987] r8169 0000:05:00.0 enp5s0: Link is Down[511744.850145] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx故障する前に見ていた。「高頻度で接続・切断の繰り返し、Ethernet link の調子が悪いけどなんだろう？」程度にしか思っていなかった。「繋がっているしな...」とログに記録された兆候を見逃していた。Ethernet HUB を「動いている」時に積極的に外すことはしない。経験として、ネットワークから HUB を(あるいは HUB から PC を) 10 秒程度切り離しても、つなぎ直せば平然と TCP/IP のコネクションは維持されつづけるし、UDP だって何事もなかったように続行する。上流 HUB から常用/予備のケーブルが伸びていれば、HUB の予防交換をしたかもしれない。予備 HUB を予備ケーブルでネットワーク基幹に繋ぎ、故障 HUB に繋がった機器類を 予備 HUB へ移していけば、何事も発生しない 10 秒の空白時間で保守ができる。ケーブルを抜いて挿す時間だ。引っ越す前は常用/予備のケーブルを張ってあったんだよなぁ。兆候の表れ方も解ったし、こんど似たような現象に遭遇したら、保守計画を考えることにしよう。あっ、考えると壊れる謎ジンクスがあったな。考えないことが一番の予防？

  2020.06.19

  コメント(0)

• 

  スイッチングハブが壊れた - 予備に置き換えた後に修理してみる

  あれ？ 第 2 サーバーにアクセスできない。第 2 サーバーは主に http proxy と各種のバックアップを担っている。ping, ssh を含めて、ネットワークアクセスができない。サーバー本体を見てみると、いつも通りな発光パターンで HDD アクセスランプが点滅している。なんというか、不定期なんだけど、ログを吐いたり、Page In するようなリズムがある。リセットボタンに伸ばした手を引っ込める。少し視界を広くし、HUB を見てみる。あれ？電源ランプ以外は消えている。イーサーネットケーブルを抜き差ししても、ポートランプは点かない。電源を入れ直してみる。投入直後の LED 全点灯動作が起きない。HUB 壊れたのか。予備の HUB に置き換えてネットワークアクセスは復旧した。壊れたと思われる HUB を試験しやすい場所に持って行く。下の画像で左側の HUB だ。Port 1 にケーブルを接続しても、port ランプは点かない。なんだな。仕事先に持ち込んで、引き上げた HUB が休眠している。運用に支障はない。動作比較用に並べた右側の HUB は接続したポートのランプが期待したネゴシエーション状態で光る。ポート 1 ～ 8 を動作試験、全て接続しない。交換前に確かめた状態は再現する。購入記録を確認してみる。2008/5 に購入していた。購入後直ぐに使い始め、停電・引っ越しなどの特別な状況以外は通電し続けている。12 年間使えば壊れても仕方無しだな。7,280 円か、今時買うと、3,000 円でおつりがくる。買った当初は機能的に 3 世代くらい進んでいた。第 2 世代で Jumbo Frame 対応、第 3 世代で省電力化がテーマだった様に記憶している。ほぼ全ポート何かの機器に繋がることになるのに、省電力化に惹かれたんだっけ。分解しよう。底にネジが無い。前面パネルシートの裏にネジが隠れていた。No.1 + ドライバーに嵌まるネジを使っていた。ケースは最大で 11 port あるいは、10 port + インジケーター 2 個までの製品と共通だった。塗装剥げが汚く見えるなぁ。どうしようも無かったら、ラベルテープでダサく作り直すか。電源ユニットのコンデンサ劣化だ。左下に見える黒スリーブのコンデンサ 2 個が膨張していた。起動時 LED 全点灯せず、全ポート接続できない状況と整合する。出力が 1 系統しか無いのにコンデンサ 2 個が膨らむ？膨らみ方も違う。基板パターンを追うと、この 2 つのコンデンサは並列接続されていた。隣接する整流ダイオードの発熱影響の差かな？封止ゴムが弾けそうになるまで膨らむのか。仕様は 10V 1000uF 低直列抵抗型。部品箱に転がっていた東信工業 UTWRZ 10V 1000uF に交換する。そう言えばこれを買った千石電商はご無沙汰している。コロナウイルス流行でどうなっているのだろう。基板にはコンデンサの - 側に白いマーキングが付いていた。少し熱で焼けている様に見える。電解液による汚損は気にならない程度か。2 次側の回路定数を読んでみる。高精度抵抗は 16.0kΩ(1602) と 5.76kΩ(5761) か。TL431 型のシャントレギュレータを使っているとして、出力電圧 Vout = ( 2.495V / 16.0kΩ ) * (16.0kΩ + 5.76kΩ) = 3.39V 位なはず。再び組み立てる。うーん、プラスチックネジ締めにくいなぁ。動作確認してみる。電源投入時に LED 全点灯動作し、ポートに接続してポートランプも期待するネゴシエーション状態で点灯する。交換した電解コンデンサも破裂せず。ん？そう言えば電源の出力電圧確かめたっけ？またバラして確認してみる。3.395V は回路から読み取った値に近い。画像をクリックすると、動画をダウンロードして再生します。あれ？ 3.412V に上昇する？AM ラジオを近づけて、動作音を聞きながら電源電圧を測定する。ああ、なにもケーブルを接続しなくても、何かの動作/休止を繰り返しているのか。画像をクリックすると、動画をダウンロードして再生します。HUB から出るノイズと同期して電源電圧が変動する。2 次側出力に 2000uF (= 1000uF x 2) も負荷していれば、負帰還の Loop Gain は高くできないよなぁ。想定できる変動なのだろうな。修理記録のラベルを付けて、おもちゃ箱へ入れる。

  2020.06.18

  コメント(4)

• 

  ひなたぼっこカメ - 川の中から出てきたの？

  自転車で川岸を走っていたら、カメが道で止まっていた。ちょっとひかれそうかな？多分カメだよね。カメには迷惑かもしれないけれど、舗装されていない道端へ移動する。あれ、水が出てきた。川の中に居たのかなぁ。手を洗わないと。

  2020.06.15

  コメント(0)

• 

  ボヤ騒ぎ？ - 元社員寮を改修した老人ホーム

  消防車がサイレンを鳴らして近くを通るのを見る。朝から何事だろうか？サイレンの音は遠くへ消える前に止まっているように聞こえてきた。消防車が集まっていた場所は元社員寮を転用した老人ホームだった。社員寮転用型の老人ホームはよく見かける。若いころは社員寮に住まったこともある。老人にとって快適か？というと、何かと不便な気もする。衣服と食器の洗い物がやりずらかったっけ？ベランダも狭かったり、手すりが低かったりで危なかったような。写っている建物はアパートくらいな設備になっている。医療・衛生施設や、共用部清掃、各部屋・人の世話人の部屋も確保しずらい構造だった。そういえば自分が社員寮に住まっていた時も、ボヤ騒ぎが有って廊下に置いてあった消火器を手に取り駆けつけたことが有ったっけ？ 消火器を持って駆けつけたの、自分くらいだったような。うーん、寮に住んでいた時勤めていたのは、工場がある会社だったんだよなぁ。訓練では... (1) 消火用機材を持って駆けつける (2) ベルが鳴ったらすぐ逃げる (3) 館内放送・指示があるまで仕事を続ける どれだったっけ？

  2020.06.15

  コメント(0)

• 

  暫く衣類・布類のリサイクル中止 - 新型コロナウイルスの影響

  市内の掲示板に「衣類・布類のリサイクル中止」のお知らせが貼られていた。新型コロナウイルスの影響でリサイクル先の業務が停止が停止していると説明されている。リサイクルに出す前に洗濯しているのかなぁ。とか、色々と気になることはある。「しばらくは自宅で保管しておこう」。うん、かなり長く保管しているな。たまにウエスとか緩衝材に使って減っていく。

  2020.06.10

  コメント(0)

• 

  もう 1 枚壊れたメモリが増えた - CFD Elixir D2U800CQ-1GLZJ

  保管していたマザーボードを出してきて動作試験をしていた。可能で有れば稼働しているマシンの性能が少しでも上がればと思い、入れ替え予定だった。Ubuntu 20.04 amd64 を起動すると、なぜか kernel log に stack dump が出る。しばしば GUI ログインまで辿り着かずにハングアップする。memtest86+ でメモリをテストしたら、エラーが見つかった。1 ビットのエラーで症状が複数出る？ memtest86+ でテストを暫く続けていたら、さらにエラーが出てきた。64byte 毎で、bit30 か。行線切れ？立て続けに不良メモリが見つかる。また CFD Elixier だ。基板の色は紺色、ロットが違っても品質はイマイチなのか。CFD のページを見ると、Elixir ブランドの扱いは DDR3 で終了していた。何か有ったのかなぁ。過電圧も、高クロックも掛けずに普通に使っていたのにな。

  2020.06.09

  コメント(0)

• 

  謎の ASRock SATA3 Card をいまさら使う - LED 点かないなぁ... では改造

  6Gbps の SATA3 I/F を使う必要が出てきたので、SATA3 の PCIe 2.0 I/F カードを探す。出てきたのは ASRock SATA3 Card だった。Bridge chip に Marvell 88SE9123 を使っている。LED 端子が付いているので LED を付けてみる。LED が点かない。Linux で lspci を使い 88SE9123 が存在する PCI bus の場所の当たりを付ける。# lspci-- snip --02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 10)02:00.1 IDE interface: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 10)-- snip --AHCI の CAP.SAL ("HBA Capabilities"."Supports Activity LED" bit 25) を ahci_host_caps ノードから読み出してみる。root@paperbox:/sys/devices/pci0000:00/0000:00:02.0/0000:02:00.0/ata9/host8/scsi_host/host8# cat ahci_host_capse237ff21LED が点く仕様だ。どうしてなんだろう？基板のシルクも少し謎だった。"HDLED-_CHA", "HDLED+_CHA", "LED-_MB", "LED+_MB" と LED ピンヘッダ周りに打たれている。「変だなー」と思いつつ、ネットを検索する。ユーザーレビューなどを読んでみると、マザーボードから出ている HDD LED と並列にするらしいことが判った。思い出してきた。買った時に両端が receptacle のケーブルが添付されていたような。購入した時に撮った画像を探してみる。有った。撮影日 2010/4/5、「こんな古い物を」、買ってから 10 年以上が経過している。同時に撮影して置いたパッケージには、"ASRock SATA3.0 card for ASRock P55 series" と書かれたシールが貼られていた。特定 mother board 向けだったから、バルク品販売(ジャンク)になってしまったのか。「変だなー」と悩んでいたときに回路を追っていた。次の様になっていた。回路の原図(bsch v3)。あっ、ピン名が基板のシルクに打たれた名前と違うな... "CASE_LED_N"="HDLED-_CHA", "CASE_LED_P"="HDLED+_CHA", "MB_LED_N"="LED-_MB", "MB_LED_P"="LED+_MB" と読み替えて欲しい。SATA card 単体で LED を光らせるつもりだったので、基板に手を加えることにした。LED 未実装 LED4 の Anode 側 (LED4_P) が常に 3.3V だったので、ここから電源を 330Ω を通して引き、LED を点灯することにした。LED1, LED3, LED4 空きランドから、2.54mm ピッチピンヘッダに配線を延ばす。LED4 から延ばすだけで十分だと判ったのは後からだった。配線は裏側で止めて置いた(下の画像は止める前)。干渉する様な大型グラフィックカードは持っていないので、これで良しとする。HDD を接続して LED を点けてみる。おおー、点いた。330 Ωだと少し暗めかな。無理はしないでおこう。アクセスしていないときは消える。今時 SATA3 I/F なんて Mother board に標準で付いているし... そうなんだよね。新しいマザーボードに、CPU に、メモリに... 「買いたいスイッチ」は今のところ off のまま。

  2020.06.08

  コメント(0)

• 

  いわゆるアベノマスクが届く - お役所にしては珍しく名前らしい題が付いていない

  俗称でアベノマスクと言われる布マスクが届いた。肉眼で見る限り汚れなどの変状はない。配達物に自宅住所などの表記はなく、地域指定配布だと思われる。上の画像は郵便物的には裏面のはず。料金後納の印はマスクが入っていない方に入っている。郵便様式的に「マスク」は通信欄(通信面)に入るべき物なのだろうか。中に入っている冊子を取り出してみた。お役所物にしてはなんか変だ。漢字で長々と綴られ舌をかみそうな題名が付いていない。題名が無いと役所内での何かの審議、予算申請、通達、諸々に困ってしまうはず。政治家がよく使う「あれ」という題名で話が回ったのだろうか？強いて題を探すなら「布マスクの全戸配布」かな。青背景に白抜きで書かれた文書は、何となく政治家臭がしてくる。「省庁」の文章では無い様な。町内会の若い人が文書案を考えて、会長に回したら変な添削がされて、全戸配布のチラシに書かれたような。うーん、もみ洗いか。意外と大変だ。陰干しするのね、お日様に当てた方が消毒できると思う、日に当てると痛んじゃうのかな。あの大臣も自分でもみ洗い頑張っているのかなぁ。奥さん洗っているのかなぁ。お天道様に当たって、縮んじゃている？

  2020.06.05

  コメント(0)

• 

  DDR2 PC6400 1Gbyte メモリ 4 枚のうちどれが故障している？ - memtest86+ では見つからない memory fault

  SMR HDD のベンチマークを 自分で作った SSD/HDD テストツールで行っていた。比較のため CMR HDD のベンチマークを行っていたら、読み出したデータのチェックサムが合わないエラーに遭遇した。CheckStrictlyFileImage: Error: Checksum not match. blocknumber=563962486, a=-2048(0xfffffffffffff800).単純に 8byte 毎を 64bit 値で加算していくだけの素朴なアルゴリズムだ。2048 足りないので何処かの bit 11 が 1 から 0 に変わっていると考えるのが最もらしい状況だ。変えられそうな所を変えてみて様子を見る。項目変化ケーブル変更エラーは出るポート変更エラーは出るSATA I/F 変更エラーは出るPC 変更(OS も変わる)エラーは出なくなるメモリ入れ替えエラーは出なくなる発生 LBA不定ベンチマークを行っていた PC で使っているメモリにエラー(Fault)があると考えるのが最も可能性が高い。DDR2 PC6400 1Gbyte x 4 を総取っ替えして、エラーは解消している。どの DIMM が問題なのか memtest86+ でテストしてみた。エラーが出ない。下の画像で横に並んだメモリ 4 枚のうち、エラーがある DIMM だけ取り替える積もりだった。こうなると「4 枚ともエラーが有るかも」と言う扱いになる。一気に 4 枚全損か。ベンチマークソフトのアルゴリズムから推測できることは、12 ～ 24 時間 程度メモリに記憶させていると化ける可能性がある。なんだろう、リフレッシュが掛かるまでに揮発するのか、隣接ビットに対する write/read で乱れるのか。memtest86+ は記憶させたデータが生きているべき時間は精々 2 ～ 3 時間の短期間だ。エラーは再現できないかも。CFD ELIXIR は時間が経つと、エラーが出てくる印象だ。上の画像で縦に置いたメモリは、明らかにエラーが出たメモリだ。使用開始 1 年程経過してエラーが発生した。DDR2 memory なんだよなぁ。手持ちで使えるマザーボードもこれから故障などで目減りするだろう。ハードオフで漁るのも難度が高いし。

  2020.06.05

  コメント(0)

• 

  Blu-ray ドライブ BDR-207M BD-R/RE DL 読み書き難 - 殆ど BD-R DL / BD-RE DL を使っていないのに

  メイン PC で使っていた Blu-ray ドライブ BDR-207M が不調なので、状況を調査することにした。調査した結果 BD-R DL, BD-RE DL の読み書き(焼き)でエラーが発生し、難があることが分かった。BDR-207M は買った当初から難があった。トレイ開ボタンを押してもトレイが出てこない。ケースの化粧蓋を押し開ける構造だったので、それに引っかかっているのかと思っていた。ネットで調べると、普通に使っていてもトレイ開に難が有ったようだ。使っていて BD-R DL が上手く書き込めないことが気になっていた。いつの頃からだっけ？ 1Tbyte 規模のバックアップをする必要が出てきたので、BD-R DL を焼いてみる。3 枚ほど途中で書き込みが中断してしまった。おおよそ、2 層目書き込みに入って 2, 3 割程度の所だろうか。何かおかしい。 BD-R DL が本当に上手く書き込めるのか調べてみることにした。Linux(ubuntu 18.04) で動く GUI burning tool k3b と k3b が呼び出している command line tool の動作状況を観測してみる。結果は上の画像のように Dual Layer (DL) 系のメディアが辛うじて読める程度で、消去、書き込み(焼き)は全滅だった。1 層 R メディアは読めていて、焼けている実績がある。実質的に BD-ROM 機能付きの CD/DVD R/W ドライブになっていた。1 層の BD メディアは 100 枚も焼いていないはず。BD に焼くくらいなら、ハードディスクに保存した方が安上がりになってしまった。この成果は BD-207M を対象にテープラベル作り・張り練習の練習かな。なかなか真っ直ぐ貼れない。

  2020.06.02

  コメント(0)

• 

  このマウス動き始めに遊びがある - 前使用者がマウスをブックオフに売った訳

  ブックオフで買った中古マウス M-Y8UBを暫く使ってみて、前の使用者が手放した訳が見えてきた。動かし始めて 10 ～ 20mm ほど動いたところで、マウスポインタの移動が始まる。感覚的に言えば、「引っかかりがある」、「滑りが悪い」、「反応が悪い」といった感じになる。前の使用者は使用感にどの程度拘っていたのだろうか？ 商品箱の痛みが殆ど無かったので、買って直ぐに気づける程度の繊細さは有ったのだと思う。マウスポインタの移動が始まると追従性が良くなる。歯車の遊びのような反応だ。内部で(移動停止)→「低消費電力モード(追従性低)」→(移動検出)→「高消費電力モード(追従性高)」の様な遷移をしているのだろうか？ 電池を抱いた無線マウスならあり得る仕様だ。これは有線マウスなので消費電力は気にしなくてもいいはず。それとも、使わないときは LED を減光して、眩しくしないようにした？ケースは黒いし。PC 売り場に展示してあるマウスは動いていない。移動し始めの反応は使ってみて初めて判る感覚だ。マウス選びも奥が深いのか。しみじみ、ブックオフは難度が高いな。

  2020.05.31

  コメント(0)

• ソースが公開された GW-BASIC を build してみる - missing low level I/O functions

  ソースが公開された GW-BASIC (リンク先は記事)(GW-BASIC github repository) を build しようとしてみた。build tool は MASM ではなく、Turbo Assembler だ。一応 MASM 互換の範囲で修正を試みた。GW-BASIC を clone したリポジトリに色々と追加した修正を置いておく。全ソースをアセンブルして .OBJ ができるところまで進めた。リンケージする段階で low level I/O function 群が不足していることが分かった。.MAP ファイルに不足している procedure(MASM アセンブラで言うと PROC) が並んだ。ソース全体を grep しても symbol が見つからない。次に .MAP ファイルの一部を示す。Error: Undefined symbol PNTINI in module ADVGRP.ASMError: Undefined symbol MAPXYC in module ADVGRP.ASMError: Undefined symbol STOREC in module ADVGRP.ASMError: Undefined symbol TUPC in module ADVGRP.ASM-- snip --Error: Undefined symbol SCROLL in module SCNDRV.ASMError: Undefined symbol EDTMAP in module SCNDRV.ASMError: Undefined symbol PRTMAP in module SCNDRV.ASMTurbo linker 向けツールをアセンブラで書いたりもした。久しぶりに 8086 アセンブラで書く、おお、意外とまだ書けるなぁ。エディタに補完機能があると長いシンボルが苦にならない。足りない部分は GW-BASIC 移植先のパソコンメーカーが持っているのだろう。full build は遠い。

  2020.05.30

  コメント(0)

• 

  家に帰る途中雨に降られて、虹を見る - 日没頃に雲が切れたのか

  午前中ベランダで咲き始めたサボテンを見る。毎年この時期の楽しみだ。特に支えていないので、大きく咲くと下に垂れてしまうのが、少し残念。板敷きにしたので、花も葉っぱも痛みにくくなったと思う。午後に自転車で遠出をする。17 時頃、家から直線で 4km 離れた所で雨が降り始めた。大回りする予定を変更して、最短で家に向かう経路に変える。ちょっと遠いな。途中雨が強くなる。カゴに入れてあるバッグにレジ袋を掛けた。家について落ち着いた後、夕食の支度をしようと体を動かす。外に虹が出ているのが見えた。雲が切れたのか。Tシャツ一枚で平気だった気温はだいぶ下がっていた。ちょっと肌寒い。

  2020.05.28

  コメント(0)

• 

  Ubuntu 20.04 を SMP の Virtual Machine で動かす - apt-get remove intel-microcode か kernel parameter に dis_ucode_ldr を加える

  Ubuntu 20.04 を SMP の Virtual Machine (具体的には VirtualBox) で動かそうとすると、カーソルが点滅するだけの真っ黒な画面で止まってしまう。手っ取り早く解消するには、仮想マシンの CPU を 1 個にする UP (Uni Processor) 構成にすることだ。この状態で起動して、intel-microcode パッケージを削除する。dpkg -l コマンドで intel-microcode パッケージがインストールされていることを確かめて、apt-get remove intel-microcode でパッケージを削除する。$ dpkg -l | grep intelii intel-media-va-driver:amd64 20.1.1+dfsg1-1 amd64 VAAPI driver for the Intel GEN8+ Graphics familyii intel-microcode 3.20191115.1ubuntu3 amd64 Processor microcode firmware for Intel CPUsii libdrm-intel1:amd64 2.4.101-2 amd64 Userspace interface to intel-specific kernel DRM services -- runtimeii xserver-xorg-video-intel 2:2.99.917+git20200226-1 amd64 X.Org X server -- Intel i8xx, i9xx display driver$ sudo apt-get remove intel-microcode検索で見つけた Q and Aを参考にした。次の起動からは SMP 構成でも起動できるはずだ。micro code の update は host OS で済んでいるので仮想マシン内から micro code update をする必要はない。問題を解消する前後に状況を色々調べていた。その記録を書く。どうも、SMP 構成だと仮想マシン内で CPU micro code update をしようとしたところ(あるいはその後で)でハングしてしまうらしい。kernel log が出る様に kernel parameter から quiet splash を消して起動すると、次の様に "x86: Booting SMP configuration:" で止まっていることが分かる。SMP 構成の仮想マシン上で止まってしまうコンソールログの例(Serial Port に kernel log を出すようにした)[ 0.673941] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization[ 0.678855] Spectre V2 : Mitigation: Full generic retpoline[ 0.679467] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch[ 0.681919] Speculative Store Bypass: Vulnerable[ 0.682437] MDS: Vulnerable: Clear CPU buffers attempted, no microcode[ 0.683316] Freeing SMP alternatives memory: 40K[ 0.795826] smpboot: CPU0: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (family: 0x6, model: 0x3a, stepping: 0x9)[ 0.797545] Performance Events: unsupported p6 CPU model 58 no PMU driver, software events only.[ 0.797909] rcu: Hierarchical SRCU implementation.[ 0.797909] NMI watchdog: Perf NMI watchdog permanently disabled[ 0.798395] smp: Bringing up secondary CPUs ...[ 0.799204] x86: Booting SMP configuration:検索で見つけた Q and A はでできた kernel log をキーワードに探した。intel-microcode を削除せず、意地でも SMP で起動する方法も探してみた。特にインストールメディアから起動できるようにしたかった。kernel parameter に dis_ucode_ldr を加えれば良いことが分かった。kernel-parameters に説明がある。次は Ubuntu 20.04 インストールメディアを SMP 上で起動するために dis_ucode_ldr を使った kernel parameter の例だ。起動の様子を観察するため quiet splash は消してある。file=/cdrom/preseed/ubuntu.seed initrd=/casper/initrd dis_ucode_ldr ---kernel paramter に dis_ucode_ldr を加えて起動したときに得られた kernel log。Ubuntu 20.04 インストールメディアから起動したときに kernel parameter を修正する手順が書かれたページを参考に dis_code_ldr を kernel parameter に加えることができるだろう。Ubuntu 20.04 インストールメディアから起動して kernel parameter を変更するスクリーンショットを並べておこう。キーボードとアクセシビリティアイコンが表示されたところで、何かキーを押す([Shift] の様に具体的な入力が無いキーが良い)。言語選択をする。キーボードに合わせた選択をするか、デフォルトの英語に合わせて [Enter] を押す。実キーボードが VM 内に反映されると「英語」キーボードになっているかも。"Try Ubuntu" を選んで、[F6] を押す。[Esc] を押して、kernel paramter popup を閉じる。dis_ucode_ldr を追加する。編集が終わったら [Enter] を押して起動。guest machine から micro code を弄ろうとすると口封じでもされる？

  2020.05.27

  コメント(0)

• 

  USB3.0(Super Speed) 4 port HUB が 330 円 - 中難度のハード・オフジャンク

  ハード・オフに寄ったら、USB3.0(Super Speed) 4 port HUB が 330 円で出ていた。ジャンクボックスに転がっていたのを手に取って買う。ELECOM U3H-S410SWHだ。新品で 3,000 ～ 5,000 円 はする PC 周辺機器だ。330 円なのは何かあるのだろうな。お店で手に取るときに考えていたことは、AC アダプタか HUB 内のコンデンサがダメになっていて、何を繋いでも認識しない(一番あり得るかな)発煙歴がある(臭いはしない)水没したとか？(不可解な錆は付いていないし)色々と良くない報告があるのかなぁ(自分自身が ORICO A3H7 で痛い目に合っているのだ)まさか、お店の人が青い挿し口が Super Speed port であることを理解せずに、ただの USB HUB としてジャンクボックス行きにしたとか？あり得ないよなぁ。そういえば Up Stream 用のケーブルが欠品になっている。手持ちが有るので問題なし。1 port だけ使ってみて、特に異常が無かった。AC アダプタが壊れているとか、HUB 内のコンデンサが痛んでしまったなどの、深刻な故障はなさそうだ。4 port 全てに USB3.0 Super Speed 規格 device を繋げてみる。おお、接続認識ランプが 4 port 全て点灯した。ん？普通に動く Hub なの？いやいや、ハード・オフの難度を甘く見てはいけない。Linux で接続状況を確認してみる。# lsusb -t で device tree を見てみる。# lsusb -t/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M    |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M        |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M        |__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M        |__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M        |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480Mあれ、おかしい。Super Speed device が 3 port しかぶら下がっていない。一つだけ、High Speed port にぶら下がっている。dmesg で kernel log を見てみる。Transcend TS-RDF5が High Speed で認識されたのか。[41609.386256] usb 3-1.3: new high-speed USB device number 6 using xhci_hcd[41609.408016] usb 3-1.3: New USB device found, idVendor=8564, idProduct=4000[41609.408022] usb 3-1.3: New USB device strings: Mfr=3, Product=4, SerialNumber=5[41609.408026] usb 3-1.3: Product: Transcend[41609.408029] usb 3-1.3: Manufacturer: TS-RDF5 [41609.408032] usb 3-1.3: SerialNumber: 000000000039[41609.408940] usb-storage 3-1.3:1.0: USB Mass Storage device detected[41609.409068] scsi19 : usb-storage 3-1.3:1.0[41610.407412] scsi 19:0:0:0: Direct-Access TS-RDF5 SD Transcend TS37 PQ: 0 ANSI: 6[41610.407767] sd 19:0:0:0: Attached scsi generic sg8 type 0[41610.767806] sd 19:0:0:0: [sdh] 31291392 512-byte logical blocks: (16.0 GB/14.9 GiB)[41610.768820] sd 19:0:0:0: [sdh] Write Protect is off[41610.768825] sd 19:0:0:0: [sdh] Mode Sense: 23 00 00 00[41610.769756] sd 19:0:0:0: [sdh] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA[41610.774874] sdh: sdh1[41610.777853] sd 19:0:0:0: [sdh] Attached SCSI removable disk他の Super Speed USB device も色々と試して、dmesg を読んでみる。port 3 の Super Speed lane が不調だ。不調になっている port 3 は二股で A plug が付いている cable の補助電源ポートとして使うとか、積極的に使う用途はある。3/4 の機能で、新品価格比 1/10 以下ならば良しかな。ラベルシールに文字を入れる技も一つ覚えた。▼ 文字を引き延ばして、場所を示せる。

  2020.05.26

  コメント(0)

• 

  ふと外を見ると夕焼け空 - いやいや、今日は洗濯物や布団干しをサボったわけではないぞ

  そろそろ夕食の準備を始めないと、と立ち上がり外を見る。夕焼け空になっていた。久しぶりかな。いやいや、今日は朝雨だったぞ。洗濯物だって、布団干しだってサボったわけではないぞ。

  2020.05.23

  コメント(0)

• GRUB に root partition を volume label で指定する - 普通は UUID 指定で困らないはず

  GRUB で Linux を起動できない問題が発生した。原因は kernel parameter に指定する root volume の指定 root=uuid と file system volume に付いている uuid が一致しなくなったためだ。clonezilla で backup & restore の予行練習をしていたら発生した。ネットで現象を調べてみると、同様の現象が 発生する/発生しない の両方が見つかる。最新の clonezilla を使用することで解消した。未使用かつなぜか boot flag が付与されたパーティションが有り、 grub.cfg の残骸が残っていたのが主原因だと思う。これも、解消した。ubuntu の upgrade の時に /boot partition を / partition に統合してしまった時にこの状態になったのだろう。作業途中で root volume (root partition) の指定を uuid ではなく、volume label (あるいは file system lablel とか partition label と呼ばれているもの)にすれば、そもそもこういう問題に遭遇しないのでは？と思い GRUB に volume label 指定で root partition の指定をするように設定してみた。kernel parameter が root=LABEL=root-part の様になる指定だ。前提として partition に volume label の設定ができているものとする。次のようなコマンドで設定する。ext{2,3,4} file system に volume label を設定する(斜字体部分は環境に合わせて変える部分)# tune2fs -L root-part block-device-partition-nodeswap partition に volume label を設定する(参考、これは必須ではない)# swaplabel -L swap-part block-device-partition-nodefstab (リンク先は例)を volume label 指定にするfile system の volume label を確認する(リンク先は例)ここまで設定をしたところで、/etc/default/grub の設定に次を加える。既に存在する場合は修正する。修正が終わった/etc/default/grub の例GRUB_DISABLE_LINUX_UUID=trueGRUB_DEVICE="LABEL=root-part"/etc/grub.d/ に配置されたスクリプトを読むと、GRUB_DISABLE_LINUX_UUID と GRUB_DEVICE の設定は RAID partition など、特殊なパーティションから起動するために便宜をはかるために有るらしい。使わせて頂く。update-grub で /etc/default/grub を /boot/grub/grub.cfg (リンク先は反映結果の例)に反映する。# update-grubこれて root partition が volume label 指定になった。起動後に kernel parameter を確認してみる。$ cat /proc/cmdlineBOOT_IMAGE=/boot/vmlinuz-4.4.0-174-generic root=LABEL=root-part ro vga=791なんだな、こんな指定をしなくても普通に最新の clonezilla で clone したら起動できるし、update-grub で uuid 指定で root volume が設定される。今後は使わない設定になるはず。upgrade をしても何故か kernel version が古いままな現象を見た時に、未使用パーティションに潜んでしまった grub.cfg が有ることに気付くべきだった。

  2020.05.23

  コメント(0)

• 

  アルカリ電池液漏れ - マクセルの販売終了品

  久しぶりに使う器具があった。電池取り換えていないな... スイッチを入れる前に電池の状態を見てみる。液漏れしていた。使用期限切が 2017年5月、切れている。あれ？マクセルの電池って液漏れするんだっけ？次の画像の様な赤い「ボルテージ」と違う。液漏れ対策が無い品種だろうか？調べ見てるとマクセルのアルカリ乾電池現行品はボルテージだけになっていた。金青デザインの電池は廃品になったのか。他にあまり使っていなくて、アルカリ電池を入れた器具あったかなぁ...

  2020.05.21

  コメント(0)

• 

  そのうちに紫外線殺菌灯が公共施設で標準設備になるのかな - after 新型コロナウイルスの新基準?

  5/17(日) に南船橋ららぽーとまで行ってみる。専門店が入る建物は休館していた。暗くなった入口を良く見ると、紫外線殺菌灯が点いていた。新型コロナウイルスを不活性化するために紫外線が使えるのではないか、と言う話を聞く、検索してみるとハンディUV-LED殺菌灯(製品カタログ)という強力な紫外線照明灯があった。紫外線灯は既に厨房、床屋、医療施設、銭湯着替え室、銭湯化粧室、精肉、鮮魚を扱う施設などで使われている。殺菌するためだ。菌に効くし、ウイルスにも効く。部屋全体を照らす灯具もあれば、器具・道具類を保管する什器の中で点灯している形態もある。自分も紫外線灯を使っていた。雨の日や仕事で洗濯物を外に干せない時に、ユニットバス内で、紫外線灯を点け、乾燥機、扇風機を動かし、洗濯物を乾かしていた。紫外線灯を使う理由は、臭くならない様にするためだ。紫外線発光源は蛍光体が塗られていない水銀ランプだ。かつては EP-ROM 消去用に使っていた。一部だけで紫外線灯が使われているのは、直接紫外線を見たり、強力な放射光である場合、間接的に見るのも危険だからだ。目が焼き付いてしまう。洗濯物を乾かす時に紫外線が当たっていた扇風機は黄変が進んでしまった。この扇風機を屋外で使ったことは無い。良く見ると柱の一部が帯状に白くなっている。リモコンホルダーで陰になって、紫外線が当たらなかった場所だ。紫外線はウイルスより強固な分子構造のプラスチックも変化してしまう光なのだ。ショッピングモールで使ったら、商品や内装が黄変してしまい、使いにくい場合もあると思う。そのうち適度な照射量を決めて使用場所を広げ、内装も耐黄変化、あるいはステンレス、アルミ、チタン、マグネシウムなどの金属化が進むのだろうか？夜の妖しい店はブラックライト照明に？

  2020.05.18

  コメント(2)

• tar の書き出し先が /dev/null だと file を読み書きしない - gnu tar のソースに dev_null_output 変数がある

  Linux の上で tar cvf コマンドを使ってファイルを読み取るテストをしようとしていた。読み取るはずの容量に比べて素早く終わってしまった。なんか変だ。色々と試して、調べて分かったことを先に書く、次の様に tar cvf の出力先が /dev/null だと、ファイルを読み取らず、出力先に書き込まない。今まで知らなかっただけ？$ time tar cvf /dev/null directory_or_fileリダイレクトを使っても、同様に読み取り、書き出ししない。$ time tar cvf - directory_or_file > /dev/nullmd5dum に pipe で繋ぐと読み取りと書き出しをする。$ time tar cvf - directory_or_file | md5sum何だな、 /dev/blackhole とか blackhole command とか有るんだっけ？GNU tar のソースを読んでみる。src/common.h に bool dev_null_output (修正が加わって行が多少前後するかもしれない)が見つかった。分かりやすく怪しい変数だ。src/buffer.c:_flush_write() 関数に dev_null_output が纏わり付いている。書き出しをしない仕掛けかな。src/bcreate.c:file_dumpable_p() 関数に纏わり付く dev_null_output が file_dumpable_p() の return value に影響して、読み取りをしないような仕掛けになっている様に見える。static 関数なので create.c の中でソースは追える。GNU tar は出力先が /dev/null だと特別な扱いをしていることが分かった。ここからは、tar command 動作を確かめた流れを追う。整理した一連のログはこのリンク先に置いた。おおよそ 50Gibyte 保持しているディレクトリ(RaspberryPi3 向けに色々とストレージイメージを置いたディレクトリ)だと確かめる。$ du RaspberryPi3/52725612 RaspberryPi3/tar でファイル読み取ってみる。読み取りできることを確かめるので tar cvf を使用する。$ time tar cvf /dev/null RaspberryPi3RaspberryPi3/RaspberryPi3/root-configured.tar.gzRaspberryPi3/root-broken-20180101.tar.gzRaspberryPi3/root-orgin.tar.gzRaspberryPi3/2016-09-23-raspbian-jessie.imgRaspberryPi3/root-fpc3.0-withO3.tar.gzRaspberryPi3/zerofill-result.txtRaspberryPi3/2017-11-29-raspbian-stretch.zipRaspberryPi3/root-cofigured-base-2017-11-29.tar.gzreal0m0.087suser0m0.087ssys0m0.000s50Gibyte の読み取りを 87ms で終わるとか、あり得ない。/dev/null にリダイレクトする方法にコマンドを変更する。$ time tar cvf - RaspberryPi3 > /dev/nullRaspberryPi3/RaspberryPi3/root-configured.tar.gz-- snip --RaspberryPi3/root-cofigured-base-2017-11-29.tar.gzreal0m0.089suser0m0.084ssys0m0.004s早っ。んー、tar に気づかれず、ある程度気が利いた特殊なリダイレクトなり、pipe 連結先を考えてみる。md5sum かな。$ time tar cvf - RaspberryPi3 | md5sumRaspberryPi3/RaspberryPi3/root-configured.tar.gz-- snip --RaspberryPi3/root-cofigured-base-2017-11-29.tar.gzf963f8661034b53341c496587d5ab5c4 -real5m11.738suser1m29.177ssys0m46.174sこんどは 5 分 11 秒掛かった。ファイルを読み出し書き込みしている。

  2020.05.17

  コメント(0)

• オンライン申請した特別定額給付金が振り込まれていた - 口座を確認できる画像はカードを使用

  オンライン申請した特別定額給付金が今日振り込まれていた。暫く待つ必要があるかと思っていたら、早い対応だった。オンライン申請の内容は次の通りだった。マイナンバーカードに付与した電子証明書を使って電子署名を実施振り込み先に自分名義の銀行口座を使用口座を確認できる画像はキャッシュカードをスキャナで取り込んで使用、クレジットカード機能付きなので、名義はローマ字書き、支店番号と口座番号はかなり掠れ気味(一応読める)申請の時に「口座名義をカタカナ書きで確認できるもの」とあったので少し心配していた。お役所言葉の「等」が付いていたので、大丈夫かもという思いもあった。やっぱり、申請や説明の偽ページが増えるよなぁ。カードや口座番号と住所、氏名、年齢、電話番号がセットになる格好の機会だし。

  2020.05.15

  コメント(0)

全4821件 (4821件中 101-150件目)

< 1 2 3 4 5 6 7 8 ... 97 >