struct fw_eui64 eui = {0x00a0b021, 0x00003028}; fd = open("/dev/fwmem0", O_RDWR); ioctl(fd, FW_SDEUI64, &eui); pwrite(fd, buf, sizeof(buf), (off_t)0xFFFFF0000B00ull);としてみるも、consoleに
Unknown service addr 0xffff:0xf0000d00 tcode=1 src=0xffc0 data=1000と出て怒られる。 何で、アドレスが0x200大きくなるのか不明だが、逆にアドレスを減らして
pwrite(fd, buf, sizeof(buf), (off_t)0xFFFFF0000900ull);で実験すると、あ、なんかチャンネル変わった気がする。 というか、white noiseだけになった。
pwrite(fd, buf, sizeof(buf), (off_t)0xFFFFF0000A00ull);したらやばい感じ。 「
fwcontrol -R
」すると「(EAGAIN)」と1秒毎ぐらいに表示して全然DV取れなくなった。
sysctl debug.fwmem_debug=1
」してから、
もう一度offsetをダメもとで戻してpwrite(fd, buf, sizeof(buf), (off_t)0xFFFFF0000B00ull);してみると………おや?
fwmem_open: refcount=1 fwmem_write_block: 0 ffff:f0000b00 13 fwmem_close: refcount=0と表示された後、相変わらず
Unknown service addr 0xffff:0xf0000d00 tcode=1 src=0xffc0 data=d00とか怒られるのは変わらないんだが、チャンネルが変わっている。 やったぜ。
fwcontrol -t
」を取っておこう。crc_len: 4 generation:32 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 5 S400 0 1 0W - P 1 0 01 1 5 S400 0 1 15W C - - 0 0
/dev/fwmem0
をopenしてfwcontrol
で表示されるEUI64でioctl(fd, FW_SDEUI64, &eui)
して(off_t)0xFFFFF0000D00ull
にUnix userの記事にあったバイト列をpwrite
で送り込んだら…
果たしてチャンネルが変わった。
が、なんかchannelの指定をしても変化ないこともあるし、mplayerで見ると「Encrypted stream but you did not request authentication!
」とか怒られることもあるしで、結局2chにしか変えられないぞ。
うーむ。
まぁちょっと進展があったということで。
でも、どうせ固定されたchannelなら、cable TVの通販番組と思われる2chより4ch固定の方がましだった。:-<
なんか、channelが変えられるかどうかは「fwcontrol -t
」の出力と関係ありそうな気がする。
まぁいずれにしても2chで、画像がbt878経由よりかなり奇麗なことが確認できたのはちょっと収穫かな。
dconschat
のstrtoull()
の使い方ミスかと期待したけど、そんなことはなかった。
fwcontrol
でstatusが0に。
「fwcontrol -r
」しても変化なし。
電源off/onしたら復活したけどこれが噂の録画できる確率2/3の根拠か?
fwcontrol -R hoge.dv
」で「EAGAIN」とかいわれてダメなのか。
ということで、アンテナケーブルを差し替えると見ると…
やっぱり4chのようだ。
dconschat
で解決すれば楽なので実験。
まずは勝手にkldload
するかと「dconschat -t 0x00a0b02100003028
」としてみたけど「[dcons disconnected (get crom failed)]
」でダメだった。
ということでkldload
してみる。
なんかあるのに「No such file or directory
」とか言われてダメだ。
consoleには「link_elf: symbol gdb_arg undefined
」とか出ているし。
仕方ないので、kernel reconfigだな。dcons_crom0: <dcons configuration ROM> on firewire0 dcons_crom0: bus_addr 0x1f6000ちゃんと認識したようだ。 でも、dconsの記述は何も出ないのね。
dconschat -t 0x00a0b02100003028
」。
「[dcons disconnected (get crom failed)]
」。
変わらん。
user権限だとダメなのかな?
いや、でも/dev
を見る限り、operator groupにいれば大丈夫みたいなんだけどなぁ。
念のためrootで実験してみたけど変わりなし。
なんかdconschat
の引数が足りないのか?
-v
option付きだと…
うわ何かいろいろ次々表示されるぞ。
でもようわからん。
echo -n 0a00bcd0efghi000j~. | tr '0abcdefghij' '\0\377\240\260\41\3\1\200\20\1\15' | dconschat -t 0x00a0b02100003028なんてやってみたが、やっぱりダメだった。 そもそもUnix userで対象としているGV-1394TVと違うからなぁ。 firewireの使い方が間違っているのか、commandが違うのか、どっちが悪いのか分からないなぁ。 悔しいけど、MS-Windows利用者の協力を求めようかなぁ。
Jun 27 00:42:26 flu kernel: fwohci0: BUS reset Jun 27 00:42:26 flu kernel: fwohci0: node_id=0x8800ffc0, gen=2, non CYCLEMASTER mode Jun 27 00:42:26 flu kernel: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 Jun 27 00:42:27 flu kernel: firewire0: bus manager 0 (me) Jun 27 00:42:27 flu kernel: firewire0: New S400 device ID:00a0b02100003028とりあえず正常に認識したみたい。
fwcontrol
の出力2 devices (info_len=2) node EUI64 status 0 0x00a0b00a000053f8 0 1 0x00a0b02100003028 1でもnodeが1つ増えた。 このEUI64ってのがなんかの識別子なんだろうな。 最初の00a0b0がI-O DATAのVendor_IDという奴か? 「
fwcontrol -t
」の出力crc_len: 4 generation:2 node_count:2 sid_count:2 id link gap_cnt speed delay cIRM power port0 port1 port2 ini more 00 1 5 S400 0 1 15W P - - 0 0 01 1 63 S400 0 1 0W - C 1 0はどう見たらいいのかな。 一応1394 cardのport 1に刺したつもりだけど上記出力では0-originなんだろか、1-originなんだろうか? ある程度は覚悟しているけど
fwcontrol
のソースコードと格闘なんだろうな。
fwcontrol -R original.dv
」をしばらくしてControl-Cで止めてみる。
mplayer
で見たけどちゃんと見える。
これは何chなのかな?
KW-TV878R-PROの方にアンテナケーブルをつなぎ直してみたらどうも4chのようだ。
fwcontrol -R
」してみる。
さすがに砂嵐。
毎回アンテナケーブル刺し直すのは面倒なので、夜が明けたらもう一本買いに行くか。
man firewire
」のsupport listにあったので問題なし。
pci2: <serial bus, FireWire> at device 0.0 (no driver attached)
ちゃんと認識しているようだ。
「pciconf -lv
」で確認してもnone1@pci2:0:0: class=0x0c0010 card=0x30441106 chip=0x30441106 rev=0x46 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller' class = serial bus subclass = FireWireとうまく行っているみたい。
mencoder
が動き出す。
そういえば、19時からvideo予約してあった。
あ、そういえばTV cableだけつなぎ忘れてたぞ。
うーん。
最初の10分はwhite noiseだろうな。
しまった。
/boot/kernel/
で「ls *fire*
」すると…
あった。
そういえば、man pageにも「kldload firewire
」とか書いてあったっけ。
で、早速実行。Jun 26 19:16:15 flu kernel: fwohci0: <VIA VT6306> port 0xbc00-0xbc7f mem 0xff8ff800-0xff8fffff irq 21 at device 0.0 on pci2 Jun 26 19:16:15 flu kernel: fwohci0: OHCI version 1.0 (ROM=1) Jun 26 19:16:15 flu kernel: fwohci0: No. of Isochronous channel is 8. Jun 26 19:16:15 flu kernel: fwohci0: EUI64 00:a0:b0:0a:00:00:53:f8 Jun 26 19:16:15 flu kernel: fwohci0: Phy 1394a available S400, 3 ports. Jun 26 19:16:15 flu kernel: fwohci0: Link S400, max_rec 2048 bytes. Jun 26 19:16:15 flu kernel: firewire0: <IEEE1394(FireWire) bus> on fwohci0 Jun 26 19:16:15 flu kernel: fwohci0: Initiate bus reset Jun 26 19:16:15 flu kernel: fwohci0: BUS reset Jun 26 19:16:15 flu kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Jun 26 19:16:15 flu kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Jun 26 19:16:15 flu kernel: firewire0: bus manager 0 (me)うまくいったようだ。 次回からのためにkernel config fileにも直接書いておくか。 というか作り直してrebootするか。
kldload
した時より少なかったけどうまくいったようだ。
mplayer -idx
」しないと早送りも出来ないというおまけまで付いていたけど何が違ったんだろう。
crontab
の設定とか全くいじっていないのに。
で、サイズが大きいといっても3Mb/sを指定しているのに1Mb/sぐらいしか出ていないのは相変わらず謎なんだが。
fsck -f
」を2回実行。
入院前は、これで高い確率でresetがかかったけど、今回は大丈夫。
Jun 20 21:09:27 flu kernel: arp: 00:e0:18:05:ae:98 is using my IP address aaa.bbb.ccc.ddd!
しまった。
IP addressだけ戻すの忘れてた。^^;
fsck -f
」とかしてdiskは直ったけど、なんかダメぽ。
randomにresetがかかる。
これはやっぱり修理かなぁ。
今日のvideo録画は無しか…
せっかく色々機材を買ってきているのに使えないのは悲しい。
ifconfig alias
」で誤魔化すとかじゃなくて再起動してもflu.hn.org
になるようにする。
kernel: ichsmb0: irq 0x02 during -1
というのはちゃんと温度が取れていないのかもしれない。
とはいえ、実際に筐体を触ってだいぶ温度が下がっているのがわかったのでそれでよいか。
fseek()
とかしているわけじゃないだろうし。
5分ずつぐらい細切れにして録画して後でくっつけようかしらん?
/usr/local/etc/rc.d/apache.sh
を見たら/etc/rc.conf
の方で「apache_enable="YES"
」しろとのこと。
うーん。
portupgradeしまくった影響がこんな所に。
本ページの主張等は著者の所属組織に全く関係なく、個人としてのものです。