壊れた外付け USB ディスクの様子を FreeBSD で見る2017年03月02日 14時09分18秒

取り敢えず、前回破壊した外付け USB ディスクを FreeBSD に繋げると、こうなる。
da2 at umass-sim2 bus 2 scbus5 target 0 lun 0
da2: <I-O DATA HDPS-U > Fixed Direct Access SCSI-2 device
da2: Serial Number 000902A1541C
da2: 40.000MB/s transfers
da2: 305245MB (625142448 512 byte sectors)
da2: quirks=0x2<NO_6_BYTE>
GEOM_PART: integrity check failed (da2, MBR)
GEOM_PART: integrity check failed (ufsid/4cff0efe10087de1, MBR)
GEOM_PART: integrity check failed (diskid/DISK-000902A1541C, MBR)
ディスクの先頭領域が壊れているようだ。
% ls /dev/da2*
/dev/da2
ls でもパーティションは表示されていない。

FreeBSD には、この整合性の点検を無効にする方法がある。MBR 等を破壊してしまったディスクからの復旧に、役に立つ。root ユーザで。

$ sysctl kern.geom.part.check_integrity=0
% ls /dev/da2*
/dev/da2        /dev/da2s1      /dev/da2s2      /dev/da2s3      /dev/da2s4
これで、mount やら ntfs-3g などで、ディスクの中のファイルを見られる様になる。

なお、このディスクを繋いでも、起動画面が出ることも無い。

Windows が壊れた要因は良く分からない2017年03月01日 15時39分40秒

Windows が起動しなくなったが、実は再現環境が今でも分からない。Windows 7 が入っているのは、この Samsung の機種一機のみ。Windows Vista や Windows XP、それ以前の Windows が入っていた機種なら、HP や Toshiba などが複数台ずつあったが、間違ったボタンを押してもキーキーキーと不快音がなる程度で、起動しなくなった事は無い。

Windows 7 の問題なのか、Windows 7 から変わった LBA 等の起動機構に寄るものなのか、FreeBSD のブートローダが Windows 7 とは相容れないのか、はたまた Samsung 機種だからかなのかは分からない。

取り敢えず、この機械に、外付けのハードディスクを繋いで FreeBSD を起動するときには一段と気を付けなければいけないようだ。特に F5。

この機種に、FreeBSD のブートローダの入った USB ディスクで、F5 を押すと壊れるのは USB ディスクと内蔵ディスクの二台。MBR や LBA の情報が入っている、先頭 512 バイトが破壊される様だ。

BIOS で CD-ROM から起動するようにしたり、他の外付けの USB ディスクを繋ぎ直して、FreeBSD を起動することは出来る。ディスクも起動情報を直せばデータは無くならない。

Reboot and Select proper Boot device or Insert Boot Media in Selected Boot device and press a key2017年02月28日 14時37分12秒

Samsung RV515 に入っていた Windows 7 の機械を壊してしまった。電源を入れると「Reboot and Select proper Boot device or Insert Boot Media in Selected Boot device and press a key」と出てきて何も起動しない。

実は、この機械は一度同じように壊したことがあった。当時は日記に書く余裕が無かったが、確か 2013 年の冬の事。それ以来この機種では気つけていたのだが。

取り敢えず落胆中ではあるが、今回は再発防止を含めてのメモ。

まずは、再現方法。

  1. FreeBSD の boot ローダの入った USB デバイスを繋ぎ、BIOS で USB を優先する
  2. F1 などの起動パーティションを指定するところで、内蔵ディスクを指す F5 を押す
といたって簡単に破壊できる。

復旧にはデータを失わないように時間をかけるのだが、修復方法はいたって簡単。 MBR のあるディスクの先頭 512 バイトをバックアップから書き戻す。この部分のバックアップをしていなければ、各種 Windows でのもっと複雑な復旧作業が必要になるだろう。

FreeBSD の各種デバッグオプションを有効にし NDIS を観察2017年01月22日 12時52分06秒

NDIS が 11.0-RELEASE になって動かないが、あまり有効な手段を見付けられないので、取り敢えず FreeBSD の各種デバッグオプションを有効にして、カーネルを作ることにした。何らかのヒントが出てくれれば良いのだが。

カーネルの設定ファイルは他のものを読み込むことが出来る。

% cat /usr/src/sys/i386/conf/DEBUG 
include GENERIC

ident           GENERIC-DEBUG

#options        DEADLKRES               # Enable the deadlock resolver
options         INVARIANTS              # Enable calls of extra sanity checking
options         INVARIANT_SUPPORT       # Extra sanity checks of internal structures, required by INVARIANTS
options         WITNESS                 # Enable checks to detect deadlocks and cycles
options         WITNESS_SKIPSPIN        # Don't run witness on spinlocks for speed

options         DDB
options         KDB
include で GENERIC カーネルの設定を読み込み、DDB/KDB、INVARIANTS と WITNESS を有効にして、buildkernel KERNCONF=DEBUG。

再起動後に、ndis を試すと、ロックのエラーが表示された。

kernel: panic: mtx_lock() of spin mutex network driver @ /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1849
kernel: cpuid = 0
kernel: KDB: stack backtrace:
kernel: #0 0xc0c81d3f at kdb_backtrace+0x4f
kernel: #1 0xc0c3f1d5 at vpanic+0x115
kernel: #2 0xc0c3f0b9 at kassert_panic+0xd9
kernel: #3 0xc0c1e3c3 at __mtx_lock_flags+0x183
kernel: #4 0xc73b4d08 at ndis_start+0x38
kernel: #5 0xc73b1021 at ndis_starttask+0x21
kernel: #6 0xc6ceaea1 at _end+0x4f2afd1
kernel: #7 0xc0bffd6e at fork_exit+0x7e
kernel: #8 0xc119af50 at fork_trampoline+0x8

NDIS に変更が行われたのは 2015 年の夏2017年01月05日 12時54分41秒

NDIS が FreeBSD 11.0-RELEASE から使えなくなっている。current メーリングリストで、テスト募集中とあったのを見た覚えがあったので、見返してみた。メールは 2015 年の夏だった。どうやら一人だけ、テストをしてみようとした人はいたみたいだったが、動作するデバイスを持っていないようだった。

当時は当該機 も current を使っていなかったので、目に止めただけだった。これに返信しても、返事が貰えるかは定かではないが、とりあえず駄目元で返信を試みた。

11.0-RELEASE と 11-CURRENT の NDIS の状態2016年12月01日 12時09分13秒

ifconfig wlan0 に ssid を指定すると、問題が起きる事まで突き止めた。これは FreeBSD 11.0-RELEASE でのテスト。

FreeBSD 11.0-RELEASE では既に NDIS の一部が動かない様だが、何度か古いカーネルで試した結果からみても、最新のコードが一番真っ当な様だ。

春先に 11-CURRENT で wlan の作成が出来なくなった変更があった。11.0-RELEASE を下に調査を続ける前に、その変更が原因で壊れたのかを点検したい。SVN の履歴などを調べるとRev 300738が該当の変更だったようだ。そこで、Rev 300737 に戻して、試してみようと思う。尚、変更は ifconfig だったので、buildworld と buildkernel が必要になるので、時間が掛かりそうだ。

11.0-RELEASE で NDIS でパニックの再現2016年11月29日 18時50分38秒

ifconfig wlan0 list scan は動作するのは確認した。しかし、dhclient は動かない。この後、sysctl を使うとカーネルがパニックを起こす場合があるのを確認した。

ndis から wlan デバイスを作成しただけでは大丈夫なようだ。

$ kldload if_ndis
$ kldload /boot/modules/bcmwl5_sys.ko
$ sysctl -a | wc -l
5330
$ ifconfig wlan0 create wlandev ndis0 up
$ ifconfig wlan0 list scan
$ sysctl -a | wc -l
5338
$ dhclient wlan0
wlan0: no link .............. giving up
$ sysctl -a | wc -l
5338

ssid を指定して wlan を作成するとパニックを起こすようだ。

$ kldload if_ndis
$ kldload /boot/modules/bcmwl5_sys.ko
$ wlan create wlandev ndis0 ssid <id> wepmode on wepkey <key> weptxkey 1 up
$ sysctl -a | wc -l
kdb に落ちるので見ると、fill_kinfo_proc 内の strlcpy を指している。
db> where
Tracing pid 993 tid 100145 td 0xc7275000
strlcpy(...)
fill_kinfo_proc()
kern_Proc_out()
fill_kinfo_proc では二箇所で strlcpy が使われていた。

11.0-RELEASE で NDIS の実験を続ける2016年11月26日 06時14分50秒

11.0-RELEASE の方が ndis の状態が良いので、壊れた当初のリビジョンより、11.0-RELEASE で原因追求を続けることに。テストを続けていると、パニックを起こす状態になるのだが、あれこれと試しながらだったので、何がきっかけだかは完全には掴めていない。

取り敢えず、このコマンドが動作できるのは確認した。

$ kldload if_ndis
$ kldload /boot/modules/bcmwl5_sys.ko
$ ifconfig wlan0 create wlandev ndis0 up
$ ifconfig wlan0 list scan
list scan が動くので、通信は機能している様子。

次に、dhclient をそのまま試したら駄目だった。

$ dhclient wlan0
wlan0: no link .............. giving up

NDIS を 11.0-RELEASE に戻して更に原因追求2016年11月22日 13時43分58秒

NDIS の原因追求再試行第三段 286410 にて問題を再現にて、この辺りが問題が発生していたのは分かった。286419 では kldload でパニックを起こす。しかし、11.0-RELEASE で最近試したときのことを思い出す。その時は、通信こそ出来なかったもののパニックを起こしてはいなかったはず。そこで、11.0-RELEASE に戻す。

11.0-RELEASE では kldload でのパニックは収まっていた。dmesg から

ieee80211_new_state_locked: pending AUTH -> SCAN transition lost
を見付ける。まだ、何に関係あるのかは分からないが取り敢えず、記録。

NDIS のデバッグを有効にする sysctl がある。

$ sysctl debug.ndis=1
この後、
ndis_newstatus: ASSOC -> RUN
と表示されるようになった。

NDIS の原因追求再試行第三段 286410 にて問題を再現2016年11月17日 18時51分29秒

リビジョン 286409 が動作可能なのを確かめた。今回は、286410 が怪しかったので、このままリビジョンを一つのみ上げる。

リビジョン 286410 は zyd ドライバを壊してしまったので、そのままではコンパイル出来ない。リビジョン 286416 にてその修正が入っているので、これを利用するのが一番簡単そうだ。

案の定このリビジョンから、ndis ドライバを作り直して、kldload をすると落ちるようになった。