STM32F730 で openocd を中継し gdb から target remote :3333 で接続すると, 即座に disconnect される. Openocd の comment 的に "gdb_memory_map disable" したらどうと出てくるので, 本当にテキトーな場所 ("jtag scan chain" の if block のした) に "gdb_memory_map disable" を入れてみた.
問題なく接続できる様になるが, 今度は break point の設定をしても cpu を stop できないみたいである.
今度は "gdb_breakpoint_override hard" を入れた. それでも stop できなかった.
まぁ, とりあえず RCC の設定ができる様になったからいいか...
本当に必要になった時に調べるとするか
### 環境
Ubuntu18.04.3
openocd 0.10.0 (apt instll そのまま)
gdb-multiarch 8.1.0.20180409-git (apt install そのまま)
### 変更点
1. copy
cp /usr/share/openocd/scripts/target/stm32f7x.cfg /usr/share/openocd/scripts/target/stm32f730.cfg
2. stm32f730.cfg に以下の下 2行を追加
#jtag scan chain
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
if { [using_jtag] } {
# See STM Document RM0385
# Section 40.6.3 - corresponds to Cortex-M7 with FPU r0p0
set _CPUTAPID 0x5ba00477
} {
set _CPUTAPID 0x5ba02477
}
}
gdb_memory_map disable
gdb_breakpoint_override hard
3. openocd の実行
openocd -f interface/stlink-v2-1.cfg -f target/stm32f730.cfg
2019年10月21日月曜日
2019年9月7日土曜日
USB3.0 SuperSpeed の suspend を行なわない様にする
USB3.0 SuperSpeed (以下 SS) を使用していると, 表面上いままでの USB2.0 HS, FS となにも変わらず使用できますが, 消費電力削減の観点から SS が使える active 状態の U0 と SS もしくは device が suspend 状態の U1, U2, U3 があり, 通常 OS として SS の転送 rate が低い場合は suspend 状態に遷移する様にしているが, video など頻繁な転送を行なう場合は, suspend に入ってしまうと, active 状態の U0 に入るのに時間がかかり転送が drop してしまう.
そこで,
1. host 側の OS で suspend に移行しない様にする
2. target 側で suspend を reject する
事で, active 状態の U0 のままにする事ができる.
linux では
echo -1 > /sys/module/usbcore/parameters/autosuspend
とする事で上記 1を実現できる.
そこで,
1. host 側の OS で suspend に移行しない様にする
2. target 側で suspend を reject する
事で, active 状態の U0 のままにする事ができる.
 |
| USB 3.2 Spec page 190 より |
linux では
echo -1 > /sys/module/usbcore/parameters/autosuspend
とする事で上記 1を実現できる.
2019年8月12日月曜日
生命保険の契約変更の変遷とその他保険について
終身保険の払済をしたのは先の通りですが, あまりにもお粗末な保険契約について他の方の参考もしくは反面教師になればとここに記します.
学生の時に, 保険に入るローカルブームがあり, 終身 1000 万円, 一時払い 2億円 (!!!) の保険を入った. 当時月額 22000 円程度のものに入った. 何故入る必要があるか, 幾ら入る必要があるかなど全くなく契約した. 2 年後一時払い 2 億円はどう考えても必要ないので (それでも) 5,000万円の契約に変更した. もちろん独身で実家暮しなので全く必要ない. その後, この一時払いも無くした. 証書もどっかに行ったので詳細は忘れてしまっているが, この状態で暫く支払っていた. 契約から 20 年立ち保険料も 2,000 円ほど上り, 平成 26 年に入院給付金も解約した. そして今年平成 31 年 (令和元年) 終身部分も払済にし, 保険会社に支払う保険料は 0 円になった.
学生の時に, 保険に入るローカルブームがあり, 終身 1000 万円, 一時払い 2億円 (!!!) の保険を入った. 当時月額 22000 円程度のものに入った. 何故入る必要があるか, 幾ら入る必要があるかなど全くなく契約した. 2 年後一時払い 2 億円はどう考えても必要ないので (それでも) 5,000万円の契約に変更した. もちろん独身で実家暮しなので全く必要ない. その後, この一時払いも無くした. 証書もどっかに行ったので詳細は忘れてしまっているが, この状態で暫く支払っていた. 契約から 20 年立ち保険料も 2,000 円ほど上り, 平成 26 年に入院給付金も解約した. そして今年平成 31 年 (令和元年) 終身部分も払済にし, 保険会社に支払う保険料は 0 円になった.
 |
| 契約内容の変遷 |
この間, 大事故も病気もせず保険にお世話になる事はなかった. もちろん丈夫な体にしてもらった親に感謝であるが, マネーリテラシーがまったくないおバカな保険屋に都合の良い客になっていた. なまけものに最適なインデックスファンドの定期的買付け投資を始めてから保険と投資もしくは貯蓄をやっと切離して考えられる様になってきて, 頭だけでなく体で行動が起せる様になってきた.
いやー, それにしても細かく減額をしていったなぁと思う, 若い自分が前に行たら, 保険はいらん! こつこつインデックス投資しろと言いたい.
最近は保険に関する指南 (暴露) 本やブログ, youtube など参考にできる情報が多数あり, やっとちゃんと頭の中に入ってきた. なんともボーっと生きてきたと残念な感じである. しかし, 性格や考えはそう簡単に変わらないし, 変えようとも思っていないので, 死ぬまで続くであろうが, それでも今色々変えていけるのはよかったと思う. しかしまだ個人年金保険や地震保険の解約, また火災保険を火災共済への変更が残っているが, ぼちぼちやっていこうかと考えている. もちろん資産もそれほど無ければ多少の月額の保険料を払って家族が路頭に迷わないもしくは軽減できる様にする必要があるが, 現状それは問題ないのではないかと考えている.
現状考えている最低限必要な保険は以下と考えている.
- 火災保険 (地震保険なし)
- 個人賠償責任保険
場合において必要なのは
- 団体信用生命保険 (家を借金で購入した場合)
- 任意自動車保険 (車を所有している場合, 車両保険はなし)
- 掛捨生命保険 (家族が生きていく為の十分な資産を確保できていない場合)
とにかく貯蓄型の生命保険や個人年金保険は必要ない. 貯蓄と発生確率は低いが自分が払い切れない事態の為の保険を組み合せるのは, 目的と手段が正しく認識できていないと言わざるを得ない. 貯蓄したいのであれば, 債権もしくは株式に投資すれば良いし, 保険は掛け捨てでコスト重視の商品を購入すれば良い.
最近, えっ! そうなのと思ったのが地震保険で, この保険は建物の為の保険でなく, 地震による火災で家屋が消失した時に直近の生活が路頭に迷わない様にする為の物だと知った. その為, 火災保険で契約した家屋の保険料の半分が上限となっていて 100% 保証されるわけではない. 要するに地震での火災は保証しないという事だ. もちろんお金に色は着いていないので家屋の為に支出する事ができるが, それにしては保険金が高い.
とにかく, 次のターゲットは, 火災保険 (地震保険) を火災共済に変更する事かな.
現状考えている最低限必要な保険は以下と考えている.
- 火災保険 (地震保険なし)
- 個人賠償責任保険
場合において必要なのは
- 団体信用生命保険 (家を借金で購入した場合)
- 任意自動車保険 (車を所有している場合, 車両保険はなし)
- 掛捨生命保険 (家族が生きていく為の十分な資産を確保できていない場合)
とにかく貯蓄型の生命保険や個人年金保険は必要ない. 貯蓄と発生確率は低いが自分が払い切れない事態の為の保険を組み合せるのは, 目的と手段が正しく認識できていないと言わざるを得ない. 貯蓄したいのであれば, 債権もしくは株式に投資すれば良いし, 保険は掛け捨てでコスト重視の商品を購入すれば良い.
最近, えっ! そうなのと思ったのが地震保険で, この保険は建物の為の保険でなく, 地震による火災で家屋が消失した時に直近の生活が路頭に迷わない様にする為の物だと知った. その為, 火災保険で契約した家屋の保険料の半分が上限となっていて 100% 保証されるわけではない. 要するに地震での火災は保証しないという事だ. もちろんお金に色は着いていないので家屋の為に支出する事ができるが, それにしては保険金が高い.
とにかく, 次のターゲットは, 火災保険 (地震保険) を火災共済に変更する事かな.
生命保険控除を捨てて, 契約していた終身保険を払済みにした.
以前より契約していた終身保険を払い済みにした. 保険内容は死亡時 1000 万円の保険で, 契約当時は特約など色々付けていて徐々にダウンサイジングして最後の最後に終身保険のみのになっていた. 月約 8000 円程度の保険金でお宝保険と言われる部類の保険なので満期まで払うのも良いが, 以下の理由で払済にする事にした. この払済は, これから支払う分を停止して, 今まで支払った金額のみの運用とし, その分死亡時に受け取る保険金を減額するものである. 払済にする事でどれくらい保険金が減額されるかは, 支払った金額と契約時の利率などで計算されるので, 正確に知るには保険会社に確認が必要になる.
今回窓口に行く前にチョー概算で計算して, 自分自身納得いくかどうか考え, 払済にする理由 (大義名分) を挙げてみた
- 保険はインフレに弱い (保険受け取り時の 1000 万円の物の価値が現在より低くなる)
- 長期資金が流動性が低くなる.
- 解約返戻金が支払金額に比例せず指数的 (始めの頃は損をする)
- 死亡しても家族が路頭に迷わないくらいには資産を確保した.
- 死亡保険なので自分で使えるわけでない (余命半年宣言で支払, そんなん使える状態か!).
- 概算 600 万円程度になると算出
特にインフレに弱い事, 流動性がなくなる事が最大のリスクと考えたのが大きい. もちろんそれなりの資産を確保という前提にある.
早速, 窓口に行き払済を伝えると, 払済前の状態の契約明細を出していただき, 払済後の受取保険金額を出してもらった. そこで示されたのは, 約 780 万円という事だった. 約 78% off であるが, 自分的なテキトー概算よりは十分もらえそうなので, 即決で払済にした. 勿論対応していただいた方から, "お宝保険なのでこのまま払い続けた方がいいですよー", また "今回払済にする理由はなんでしょうか" とか一応お決まりの言葉があったが, あまり色々言わなかった. まぁ, インフレがどうとか流動性がどうとか相手は十分わかっている話なので, 単に息するために話をするだけなので, お茶を濁した...
これで月々 8000 円の相対的に手取収入アップとなる. 本来なら, ETF, 投資信託の積立の金額 up なのだが, いまは積立金額ダウンをしており, 早く来い来い大暴落状態で, 現金を増していこうと思う.
まぁどうでも良いが, まだ個人年金保険の契約もあり, 月 1 万円の支払をしている. 手数料として毎月 0.3% の 30 円を払っており, まだ良心的な手数料だとは思うが, これもやはり, インフレリスク, 流動性をなくしており解約したいところだが, 会社の福利厚生の一貫のものを契約しておりちょっと面倒なので, とりあえず退職までは持っておくか...
今回窓口に行く前にチョー概算で計算して, 自分自身納得いくかどうか考え, 払済にする理由 (大義名分) を挙げてみた
- 保険はインフレに弱い (保険受け取り時の 1000 万円の物の価値が現在より低くなる)
- 長期資金が流動性が低くなる.
- 解約返戻金が支払金額に比例せず指数的 (始めの頃は損をする)
- 死亡しても家族が路頭に迷わないくらいには資産を確保した.
- 死亡保険なので自分で使えるわけでない (余命半年宣言で支払, そんなん使える状態か!).
- 概算 600 万円程度になると算出
特にインフレに弱い事, 流動性がなくなる事が最大のリスクと考えたのが大きい. もちろんそれなりの資産を確保という前提にある.
早速, 窓口に行き払済を伝えると, 払済前の状態の契約明細を出していただき, 払済後の受取保険金額を出してもらった. そこで示されたのは, 約 780 万円という事だった. 約 78% off であるが, 自分的なテキトー概算よりは十分もらえそうなので, 即決で払済にした. 勿論対応していただいた方から, "お宝保険なのでこのまま払い続けた方がいいですよー", また "今回払済にする理由はなんでしょうか" とか一応お決まりの言葉があったが, あまり色々言わなかった. まぁ, インフレがどうとか流動性がどうとか相手は十分わかっている話なので, 単に息するために話をするだけなので, お茶を濁した...
これで月々 8000 円の相対的に手取収入アップとなる. 本来なら, ETF, 投資信託の積立の金額 up なのだが, いまは積立金額ダウンをしており, 早く来い来い大暴落状態で, 現金を増していこうと思う.
まぁどうでも良いが, まだ個人年金保険の契約もあり, 月 1 万円の支払をしている. 手数料として毎月 0.3% の 30 円を払っており, まだ良心的な手数料だとは思うが, これもやはり, インフレリスク, 流動性をなくしており解約したいところだが, 会社の福利厚生の一貫のものを契約しておりちょっと面倒なので, とりあえず退職までは持っておくか...
2019年8月5日月曜日
一般 NISA の米国株式を特定口座に移管した時の株価とドル円レートについて
先日 一般 NISA 2016,17 年の VTI を特定口座に移管 で書いた通り VTI を特定口座に移管したが, 移管時の USD の株価と USDJPY は, 移管後の口座内にある USD での株価, ならびに JPY の総額から USD の株価ならびに株数を割ったものから求めていたが, 2 回目以降はこれでは不明確になる. その為コールセンターに問合せて, 移管時の USD の株価ならびに USDJPY を知る方法があるかを問合せた.
回答は, 四半期に送られてくる "取引残高報告書" で確認せよとの事だった.
しかし, ここで分るのは
- 取引日
- JPY の株価
- JPY の総額
JPY のみで USD 関連は全くわからない.
そので言われたのは, 取引日から Yahoo finance などから USD の株価の終値を取得, その後 JPY の株価から USD の株価を計算してくださいだった.
直近の取引残高報告書は 9 月に来るはずなのでそれで確認しようと思う.
回答は, 四半期に送られてくる "取引残高報告書" で確認せよとの事だった.
しかし, ここで分るのは
- 取引日
- JPY の株価
- JPY の総額
JPY のみで USD 関連は全くわからない.
そので言われたのは, 取引日から Yahoo finance などから USD の株価の終値を取得, その後 JPY の株価から USD の株価を計算してくださいだった.
直近の取引残高報告書は 9 月に来るはずなのでそれで確認しようと思う.
2019年8月1日木曜日
12TB RAID5 fsck 通らず. 被害 10 filesで復活
またまた, 12T RAID5 がおかしくなり, SAMBA 系由で file が見えなくなった.
Ubuntu 上からも見えなくなった. というのも, この Ubuntu マシンは足元に置いていて, オットマン状態になっていて, ちょっとした拍子で PC を動かしてしまった. その時に eSATA が unlink 状態になったのだろうと想像される.
reboot 後, 普通に fsck が通ると思ったのだが, 全く通らない. とりあえず 1日待っても fsck が通らない. というか fsck 自体が cpu load avarage が 100% のままずーと進まない状態になっていた.
root@xxx:/home/yyy# fsck -y /dev/sdb
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sdb contains a file system with errors, check forced.
Pass 1: Checking iノードs, blocks, and sizes
Running additional passes to resolve blocks claimed by more than one iノード...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in iノード 12: 375912184
Multiply-claimed block(s) in iノード 56102605: 120293546
Multiply-claimed block(s) in iノード 256639065: 1029258958
Multiply-claimed block(s) in iノード 586416835: 898879174
Multiply-claimed block(s) in iノード 717885620: 375912184 1029258958 120293546 898879174
Illegal block number passed to ext2fs_test_block_bitmap #3422481702 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #4258085766 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #2964345158 for multiply claimed block map
Pass 1C: Scanning directories for iノードs with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 5 iノードs containing multiply-claimed blocks.)
File /disk1 (iノード #12, mod time Wed Mar 11 22:20:48 2015)
has 1 multiply-claimed block(s), shared with 1 file(s):
file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes
とりあえず file.img がおかしい事がわかったが, fsck が通せないので, とりあえず mount して ls すると以下の通り
超絶おかしな状態になっていた.
-rw-rw-r-- 1 ppp sssss 890 7月 5 07:08 file.20190716a.txt.1~
-????????? ? ? ? ? ? file.201907170.dat
drws--x--- 34433 343389890 1888527826 49152 8月 12 1964 file.201907170.img
-????????? ? ? ? ? ? file.201907170.tar.gz
-????????? ? ? ? ? ? file.201907170.txt
-????????? ? ? ? ? ? file.201907170.txt.1~
-????????? ? ? ? ? ? file.201907170.txt.2~
-????????? ? ? ? ? ? file.20190724a.dat
s--Srwx-wt 40825 4203306669 2869282342 0 3月 31 1979 file.20190724a.img
-????????? ? ? ? ? ? file.20190724a.tar.gz
-????????? ? ? ? ? ? file.20190724a.txt
-rw-rw-r-- 1 ppp sssss 558035 7月 26 07:07 file.201907260.dat
-rw-rw-r-- 1 ppp sssss 189880 7月 26 07:05 file.201907260.img
-????????? ? ? ? ? ? file.201907260.tar.gz
-????????? ? ? ? ? ? file.201907260.txt
-rw-rw-r-- 1 ppp sssss 1060 7月 26 07:12 file.201908xx0.txt
-????????? ? ? ? ? ? file.txt
permission, uid, gid などが ??? になってしまっている. またそうでなかったとしても regular file が directory file になっていたりする.
とにかく, ほとんど file はなくてもなんとかなりそうだが, file.txt は残しておきたいと思ったのだが, copy しようにも I/O error となる. おかしな状態のものは抹殺しようと rm したがこれまた I/O error となる. ls -il で inode を表示させても ? 状態でとにかく何もできない... file の情報だけあった inode は開放されているのではないかと思う.
そこで, とにかく file 情報を消す方法がないかと調べてみると debugfs でできそうな感じがし, とりあえず debugfs を動作させた.
debugfs -w /dev/sdb
多少挙動が違うが, 一般的な shell の様 cd, ls が使えた. ただ ls は less 想像のものが動作し, 微妙に使いずらい. また, console の history に残っていないので, どの様に表示されたかなどここに書く為の情報はなくなってしまっている. ただ, やった事はとりあえずすべての ? 状態の file を rm していった.
すべての ? 状態の file を消し, debugfs を抜け再度 fsck してもやはり,
has 1 multiply-claimed block(s), shared with 1 file(s):
file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes
file.201907170.img は "drws--x---" の file で, regular file が directory file になってしまっている. しかも suid 状態!!! とりあえず rmdir で削除や cd で中に入ろうとするができない. もともと regular file なので, それはあたりまえかと思う. とにかく 644 にしようと思うが, 通常の mount した状態からは chmod が不可能だった. やはり debugfs の出番だ.
debugfs では chmod らしきものは "modify_inode" で, inode を持っている file に対して属性を変更できる (今回はなぜか 666 に変更)
すべては表示しないが, Mode のみ変更し, あとは enter をひたすら連打した.
debugfs: modify_inode file.201907170.img
Mode [044710] 666
User ID [46786]
Group ID [42450]
Size [49152]
Creation time [-251420407]
Modification time [-170039582]
Access time [987520066]
debugfs 上で再度 ls をすると, ? 状態はすでになくなっているが, その他の file も正しい uid/gid に変更されすっかり問題がなくなってしまった.
最初から fsck で file.201907170.img がおかしいと出ていたので, ひょっとすると残しておきたかった file.txt も問題はなかったのかもしれない.
しかし, すでに debugfs で rm 済みなので, もう帰ってこない. といっても, emacs の backup file があったので, そこから直近のものだけを書き加えてそれっぽく復旧しておいた.
fsckでいくらたっても終らない状態になった時は,
fsck で erorr になっている対象のみ, mount -o ro で確認や debugfs で確認し, 変更もしくは削除の対応をした方が良い. それを何度か繰替えせば, どの file も消さずに復旧できたかもしれない. とはいえ eSATA で HDD を外部接続しているのでそれが問題と思うので, HDD を 2つ購入し PC に内蔵し, 1つは現在の RAID の代り, もうひとつは rsync で一日一回 backup を検討している.
本来はオットマン状態の PC を机の上にするべきであるが, それは改善しない...
Ubuntu 上からも見えなくなった. というのも, この Ubuntu マシンは足元に置いていて, オットマン状態になっていて, ちょっとした拍子で PC を動かしてしまった. その時に eSATA が unlink 状態になったのだろうと想像される.
reboot 後, 普通に fsck が通ると思ったのだが, 全く通らない. とりあえず 1日待っても fsck が通らない. というか fsck 自体が cpu load avarage が 100% のままずーと進まない状態になっていた.
root@xxx:/home/yyy# fsck -y /dev/sdb
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sdb contains a file system with errors, check forced.
Pass 1: Checking iノードs, blocks, and sizes
Running additional passes to resolve blocks claimed by more than one iノード...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in iノード 12: 375912184
Multiply-claimed block(s) in iノード 56102605: 120293546
Multiply-claimed block(s) in iノード 256639065: 1029258958
Multiply-claimed block(s) in iノード 586416835: 898879174
Multiply-claimed block(s) in iノード 717885620: 375912184 1029258958 120293546 898879174
Illegal block number passed to ext2fs_test_block_bitmap #3422481702 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #4258085766 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #2964345158 for multiply claimed block map
Pass 1C: Scanning directories for iノードs with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 5 iノードs containing multiply-claimed blocks.)
File /disk1 (iノード #12, mod time Wed Mar 11 22:20:48 2015)
has 1 multiply-claimed block(s), shared with 1 file(s):
file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes
とりあえず file.img がおかしい事がわかったが, fsck が通せないので, とりあえず mount して ls すると以下の通り
超絶おかしな状態になっていた.
-rw-rw-r-- 1 ppp sssss 890 7月 5 07:08 file.20190716a.txt.1~
-????????? ? ? ? ? ? file.201907170.dat
drws--x--- 34433 343389890 1888527826 49152 8月 12 1964 file.201907170.img
-????????? ? ? ? ? ? file.201907170.tar.gz
-????????? ? ? ? ? ? file.201907170.txt
-????????? ? ? ? ? ? file.201907170.txt.1~
-????????? ? ? ? ? ? file.201907170.txt.2~
-????????? ? ? ? ? ? file.20190724a.dat
s--Srwx-wt 40825 4203306669 2869282342 0 3月 31 1979 file.20190724a.img
-????????? ? ? ? ? ? file.20190724a.tar.gz
-????????? ? ? ? ? ? file.20190724a.txt
-rw-rw-r-- 1 ppp sssss 558035 7月 26 07:07 file.201907260.dat
-rw-rw-r-- 1 ppp sssss 189880 7月 26 07:05 file.201907260.img
-????????? ? ? ? ? ? file.201907260.tar.gz
-????????? ? ? ? ? ? file.201907260.txt
-rw-rw-r-- 1 ppp sssss 1060 7月 26 07:12 file.201908xx0.txt
-????????? ? ? ? ? ? file.txt
permission, uid, gid などが ??? になってしまっている. またそうでなかったとしても regular file が directory file になっていたりする.
とにかく, ほとんど file はなくてもなんとかなりそうだが, file.txt は残しておきたいと思ったのだが, copy しようにも I/O error となる. おかしな状態のものは抹殺しようと rm したがこれまた I/O error となる. ls -il で inode を表示させても ? 状態でとにかく何もできない... file の情報だけあった inode は開放されているのではないかと思う.
そこで, とにかく file 情報を消す方法がないかと調べてみると debugfs でできそうな感じがし, とりあえず debugfs を動作させた.
debugfs -w /dev/sdb
多少挙動が違うが, 一般的な shell の様 cd, ls が使えた. ただ ls は less 想像のものが動作し, 微妙に使いずらい. また, console の history に残っていないので, どの様に表示されたかなどここに書く為の情報はなくなってしまっている. ただ, やった事はとりあえずすべての ? 状態の file を rm していった.
すべての ? 状態の file を消し, debugfs を抜け再度 fsck してもやはり,
has 1 multiply-claimed block(s), shared with 1 file(s):
file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes
file.201907170.img は "drws--x---" の file で, regular file が directory file になってしまっている. しかも suid 状態!!! とりあえず rmdir で削除や cd で中に入ろうとするができない. もともと regular file なので, それはあたりまえかと思う. とにかく 644 にしようと思うが, 通常の mount した状態からは chmod が不可能だった. やはり debugfs の出番だ.
debugfs では chmod らしきものは "modify_inode" で, inode を持っている file に対して属性を変更できる (今回はなぜか 666 に変更)
すべては表示しないが, Mode のみ変更し, あとは enter をひたすら連打した.
debugfs: modify_inode file.201907170.img
Mode [044710] 666
User ID [46786]
Group ID [42450]
Size [49152]
Creation time [-251420407]
Modification time [-170039582]
Access time [987520066]
debugfs 上で再度 ls をすると, ? 状態はすでになくなっているが, その他の file も正しい uid/gid に変更されすっかり問題がなくなってしまった.
最初から fsck で file.201907170.img がおかしいと出ていたので, ひょっとすると残しておきたかった file.txt も問題はなかったのかもしれない.
しかし, すでに debugfs で rm 済みなので, もう帰ってこない. といっても, emacs の backup file があったので, そこから直近のものだけを書き加えてそれっぽく復旧しておいた.
fsckでいくらたっても終らない状態になった時は,
fsck で erorr になっている対象のみ, mount -o ro で確認や debugfs で確認し, 変更もしくは削除の対応をした方が良い. それを何度か繰替えせば, どの file も消さずに復旧できたかもしれない. とはいえ eSATA で HDD を外部接続しているのでそれが問題と思うので, HDD を 2つ購入し PC に内蔵し, 1つは現在の RAID の代り, もうひとつは rsync で一日一回 backup を検討している.
本来はオットマン状態の PC を机の上にするべきであるが, それは改善しない...
2019年7月27日土曜日
STM32F730 の USBHS を使用する場合の外部 clock 選定に注意
PC 側と USB target device 側の clock 同期の参考にする為に USBHS にて
1. uSOF の値の取得
2. uSOF 時の target device 側の clock のカウンタ値の取得
3. 他のなんらかの周期的な信号の入力時の 1, 2 の値の取得
4. 取得した値を USB にて PC に転送
するものを作成している (結果的に必要なさそうになっている).
とりあえずテキトーに基板を作成し, boot までさせたのだが, USBHS 実装に手間取っている. USBHS PHY の PLL が lock をしていない様に思えた. そこで調べてみると, STM32F730 にある USBHS (PHY内蔵) を使用する場合の PLL1 の入力周波数は, 12, 12.5, 16, 24, 25MHz となっており, 今回使用した 26MHz はリストにない. とは言え, core 用の PLL で 24MHz など作って入れれば良いかと思ったら, HSE (外部クロック) から直接の入力になるとの事. 見てなかった...
USBHS PHY 用の PLL1 の入力 path は??? え!!! (赤い部分)
今回, 26MHz 発振器を MCU と SI5351 に分配しているので, SI5351 の余っている出力の 1つを 24MHz 出力を追加してそれを, MCU の入力にしようと考えている. もし, ng そうであれば, 24MHz か 25MHz の発振器を購入しようと思うが, VCXO を使いというのがあるので, それほど市場在庫がない.
ただ.
1. とりあえず SI5351 で 26MHz -> 24MHz が出せる
2. 諸般の事情でこの回路の必要性がなくなった
ので 24 もしくは 25MHz の発振器を買ってまで最後までやる必要があるか??? というのがあります...
登録:
投稿 (Atom)